spf-discuss
[Top] [All Lists]

RE: Domain Keys vs Sender Permitted From vs SenderPolicy Framework

2004-06-04 01:19:08
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.

"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.)

Anyway, all this means that your MUA can tell you what addresses are
known to be valid, at least to some extent.

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.

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.)

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.

Does that resolve your concerns?

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com