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