ietf-dkim
[Top] [All Lists]

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

2006-11-09 08:30:23

On Nov 9, 2006, at 4:33 AM, Charles Lindsey wrote:

On Wed, 08 Nov 2006 16:43:58 -0000, Steve Atkins <steve(_at_)blighty(_dot_)com> wrote:

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

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.

Well at least it is a start to force the phishers into using look- alikes.

No, it isn't. There is no way in which SSP makes this better.
Depending on how it's implemented by recipients there are ways
in which it makes it worse.

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.

Which is where we need sites on which "reputations" can be queried. I envisage these will operate rather like the present DNSBL blacklists. You choose such a site that you trust, and then ask its advice on the action you should take according to the signer, From address, etc. I would suppose that phishers own domains would rapidly acquire a rather poor reputation (and the advice should be to "delete all mail where the signature succeeds, and even where it doesn't").

If you need an external trust model to tell you whether you should
trust SSP, then you can simply use just the external model and
avoid the whole self-publication thing altogether.

Then whence SSP?

(And, more to the point, if we all agree that SSP is pointless
without a third party trust model then the SSP specification is
neither complete, nor ready to review, until that trust model
is also defined).

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>