From: Alan Hodgson
Sent: Friday, September 24, 2004 1:07 PM
On Fri, Sep 24, 2004 at 12:52:07PM -0400, Meng Weng Wong wrote:
C) SUBMITTER if provided
D) if checking is done after the DATA command, the PRA
I say "three identities" because C and D are really the same
thing according to the SUBMITTER spec, yet SUBMITTER can be
treated as a first-class identity in its own right.
Does SUBMITTER have any value without being able to check PRA? Does
it have any real value even if we can check it? Ya, ya, phishing, but
does anyone really think you can protect users from phishing that
easily?
SUBMITTER + PRA really does not prevent phishing and never did. We have
discussed too many holes in it to consider it reliable. It totally loses
track of who originated the message, which is the single biggest clue we
have. The reputation of a forwarder tells you almost nothing about a
message compared to the reputation of the originating domain.
Would it be possible to focus more on crypto solutions to header
validation (ala DomainKeys?), and look to SES+crypto for end-to-end
MAIL-FROM validation instead of SUBMITTER or SRS or other mechanisms
that require changes on intermediate nodes? Based on what Seth has
been saying, this could be a really nice end-to-end setup.
Yes, this is entirely possible and much cleaner than SUBMITTER. Without
end-to-end validation of MAIL FROM:, you are stuck trying to whitelist your
forwarders and hope that the originating identity was validated by somebody.
Since your forwarder may have whitelisted other forwarders, you can never
really know this. With an end-to-end system, forwarders no longer are an
issue. Positively validating MAIL FROM: accomplishes three very important
goals:
1) You know what site sent the message and can then scrutinize their
reputation.
2) You can reject joe-jobs.
3) Forwarders don't have to change their practice.
If the mechanism for validating MAIL FROM: happens to be SES, you get a
fourth very desirable benefit:
4) You can reject forged null-sender messages.
Only after we have established that the MAIL FROM: identity is valid is it
worth looking at the higher overhead mechanisms required to detect 2822
forgery. DK and other PK crypto schemes are _much_ more expensive for the
recipient than SPF or SES, so first qualifying the message with one of those
two protocols makes a lot of sense. Though doing DK alone would be less
effort than SPF + SES + DK for _legitimate_ mail, most of what we see is
_not_ legitimate mail, so rejecting it with a lower overhead mechanism makes
a lot of sense. The total load on an MTA will be much less with SPF + SES
used before any PK crypto mechanisms, so that is why we should be going this
route.
No one should forget for a nanosecond that PRA is the heart of the MS patent
application. MARID folded for the correct reason: the proposed
implementation that included PRA could not be widely implemented. Why is
anyone even _considering_ anything that even remotely resembles PRA? If
SUBMITTER really was a MS idea, we should probably treat that as untouchable
as well, aside from the fact that we can accomplish the goal better by using
SES as an adjunct protocol. The major MTA providers won't implement
anything based on it, so we really have to go a different way. Pretending
that we can ignore the consequences of MS gaining a patent on PRA, SUBMITTER
and maybe even SPF classic would be an even worse mistake than trusting MS
in the first place. That was dumb, but pretending that we can ignore a
software patent, if granted, would be just plain stupid.
Consider a hybrid solution that looks like this: SPF (or SES) for first hop
messages, SES on forwards and then probably a PK crypto solution for 2822
authentication. The key is to use the lowest overhead mechanisms first to
reject as much as we can, then apply the higher overhead tools to what's
left to detect 2822 phishing. If we can do this without changing existing
mail practice, we have something that can be gradually adopted without undue
pain.
I think solutions that will work in the absence of a global
upgrade make more sense than otherwise. Solutions that will
provide some benefits (bounce protection) even if just the
sender implements them make even more sense.
That's an excellent point. PRA is encumbered to the point that the open
source MTA's won't use it. SUBMITTER is really a shortcut for SRS, and just
like SRS, it does not validate the all-important originating domain
identity. SES gets you originating MAIL FROM: validation without changing
SMTP and also gets you forged null-sender protection for free.
Or, if we're committed to SUBMITTER/PRA, I guess we'll figure
out how to deal with it.
We can probably deal with anything, except perhaps having PRA being the
lever for Microsoft to financially crush the open source movement. Nothing
would give them more pleasure.
--
Seth Goodman