[ietf-dkim] Collection of use cases for SSP requirements
steve at blighty.com
Wed Nov 8 07:55:15 PST 2006
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:
>> <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
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
So... what's the _real_ use case, again?
More information about the ietf-dkim