ietf-dkim
[Top] [All Lists]

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

2006-11-08 09:47:20
On Wed, 8 Nov 2006 07:55:15 -0800 Steve Atkins <steve(_at_)blighty(_dot_)com> 
wrote:

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
affected.

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

Please explain.  If a sender publishes a policy that says I sign all mail 
and a receiver rejects, deletes, etc. all mail that isn't signed by that 
sender, what is the phisher's transition path to work around it?

I agree that this does not help with look-alike domains, but for phishing 
that uses a sender's domain, I'm noy sure what you are getting at?

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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