[ietf-dkim] Collection of use cases for SSP requirements

[Steve Atkins]

On Nov 8, 2006, at 4:24 AM, Charles Lindsey wrote:

> On Wed, 08 Nov 2006 04:46:08 -0000, wayne <wayne at schlitt.net> wrote:
>
>> In  
>> <60A9EDD76DBBFE48ABE4FE35324BBB8201B51798 at dooku.ironportsystems.com>  
>> "Patrick Peterson" <ppeterson at ironport.com> writes:
>>
>>> - I sign all email AND have enough confidence in the reliability of
>>> signatures AND the risk of allowing spoofed email is high enough  
>>> that I
>>> choose to accept the risk and therefore state that receivers  
>>> should drop
>>> unsigned/invalid signature email.
>>
>> OK, as a receiver, can I blame the sender for any problems with
>> legitimate email being rejected due to DKIM failures?  If a receiver
>> can't transfer the blame to the sender, why should the receiver treat
>> this any different than just being suspicious?
>
> I think some site like a Bank, that is heavily phished, might go so  
> far as to declare
>    "I sign all mail. Please delete/reject/drop/whatever (perhaps  
> even silently)
>     all messages that fail to verify".
>
> That site would have to be pretty confident that the genuine mail  
> it sent out was 100% clean, but it might well decide that it was a  
> lesser risk to have some genuine messages dropped than to let  
> phishes go through.
>
> BTW, are there any plams to have keywords for some of the various  
> policies that might be declared, so that verifiers (or rather their  
> policy modules) could recognize them and adjust their policy  
> accordingly)?

I do have to point out that SSP will not affect phish emails noticeably,
after a very short transition period.

So if a bank were to do this it would mean 1) phishing mails won't
be affected and 2) legitimate mail from the bank is likely to be
affected.

So... what's the _real_ use case, again?

Cheers,
   Steve