ietf-dkim
[Top] [All Lists]

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

2006-11-08 09:55:22

On Nov 8, 2006, at 8:10 AM, Scott Kitterman wrote:

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:

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?

You point out the underlying issue nicely.

Phishing doesn't have to use the real domain. There are *countless*
ways of phishing that don't require it. Even now, a lot of phish mails
don't bother using the real domain, even though there's no real
disincentive to do so in most cases. If there were even a minor
disincentive then they could move away from that today with
minimal inconvenience.

Many of them use their own domains, for which they could trivially
publish SSP data.

So SSP will have minor, and temporary, effect on phishing using
the real domain. It will have minor negative effect on legitimate email.
Depending on what recipient ISPs do with the information ("SSP
validated sender!!!") it may actually make phishing more effective.

(I expect banks will take a look at SSP, decide it's entirely inappropriate
and work together for some sort of centralized authentication
eventually, so ISPs can really say "this email came from a real
bank" - functionality that SSP, or any pure self-signing approach, can
never offer.)

So phishing is clearly not a real use case. "I send no mail" is
a mildly interesting use case, but clearly doesn't require the
complexity being put together. So what is the real poster
child for SSP deployment?

Cheers,
  Steve
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

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