[Top] [All Lists]

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

2006-11-08 09:01:08

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

On Wed, 08 Nov 2006 04:46:08 -0000, wayne <wayne(_at_)schlitt(_dot_)net> wrote:

In <60A9EDD76DBBFE48ABE4FE35324BBB8201B51798(_at_)dooku(_dot_)ironportsystems(_dot_)com> "Patrick Peterson" <ppeterson(_at_)ironport(_dot_)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

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

NOTE WELL: This list operates according to

<Prev in Thread] Current Thread [Next in Thread>