From: Mark Shewmaker
Sent: Friday, June 04, 2004 3:19 AM
On Thu, 2004-06-03 at 12:51, Seth Goodman wrote:
My understanding of the merged proposal is that the first hop
would not use
RFROM, thus forcing the SPF check to be done on MAIL FROM:.
When there is
an RFROM parameter, we use that and ignore MAIL FROM:. That is a good
reason for making it a requirement that the originating hop MUST NOT use
RFROM, thus forcing MAIL FROM: to be validated by SPF at least
once during
message transit.
That is actually part of my motivation for considering a
requirement that
the MAIL FROM: address appear in either From: or Sender:. If
MAIL FROM: is
validated by SPF at the first hop, and we then require this address to
appear in From: or Sender:, we present to the user an address
that has been
validated. This is extremely valuable. So what if it was
outside of the
original scope SPF?
With the new SPF, the validated address is the PRA, which is basically
the topmost of:
Resent-Sender:
Resent-From:
Sender:
From:
This is true whether there's a SUBMITTER in the envelope or not. It's
also true along every hop from the first hop after submission to the
very last hop.
If that's how it works, it's good to finally know. That forces it to check
the actual sender on the first hop, unless the originator forges the message
as if they are a forwarder. Then the forgery will pass through the whole
system without a hitch. That is the problem that Ryan, Shevek and I
separately brought up and you realized in your "Everyone, stop the presses"
post. This is a big hole and we need to plug it.
"SPF: Good to the last hop." :-)
(Obviously it's not true if the first hop lied about things, and you
receive an email forwarded to you by a lier, but I'm assuming you only
accept forwards from people you trust, either that or you or your MUA
can see at what point in the chain you can no longer trust the email's
history.)
Yes, we have to trust our forwarders. Realistically, most users don't have
any way of evaluating how well they do SPF checking. What's worse is that a
properly constructed forgery will pass an SPF-CID check at the next hop no
matter how careful the forwarder (or our own MTA) is. The forwarder doesn't
have to be a liar, just the originator. This is a problem even if there is
no forwarder, because the originator is posing as a forwarder.
Anyway, all this means that your MUA can tell you what addresses are
known to be valid, at least to some extent.
Except for the case above and the case where the forwarder does less than
perfect SPF checks. Basically, we can't have much confidence in the
originating addresses unless there are no forwarders.
So we *can*, wearing our MUA hats, present to the user the latest
address that exists in the body headers that has been validated--it's
just that the address might look a bit ugly to an end user if it's been
SES or SRS wrapped.
The destination gateway MTA MUST unwrap an SES or SRS address to put in the
Return-Path: header. Those addresses should never be exposed to end users.
This is not a difficult requirement, as the destination gateway MTA is the
only one that writes the Return-Path: header.
An MUA could recognize an SES- or SRS-wrapped address, unwrap it, and
list the one-further-down address as being implicitly validated, if it
matches the unwrapped address. (I don't *think* there's a security
problem with that that's really an issue in the real world.)
There is a potential one (replay attacks), so SRS and SES addresses need to
be unwrapped by the MTA back to their native form. This also makes the
MUA's job easier, so it's a good thing all around.
And if the user is willing to say what domains or users he or she
trusts, that is, whitelisting their trusted forwarders in the MUA as
well, we can go even further backwards in the headers to that extent and
show more validated headers, possibly all the way back to the From: line
even for forwarded emails.
Explicitly trusting your forwarders is a good idea, except how can the
average user know if they are trustworthy?
Does that resolve your concerns?
Not quite, but knowing more about PRA extraction definitely helps.
--
Seth Goodman