From: Stuart D. Gathman
Sent: Thursday, June 03, 2004 12:41 PM
On Thu, 3 Jun 2004, 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?
If, instead of doing SRS, forwarders were to prepend or replace the
(currently deprecated) reverse source path in MAIL FROM, leaving
the original
MAIL FROM alone, then SPF could always take place on the last reverse
source path host, or MAIL FROM if there is no reverse source path.
I couldn't agree more. Why add a new ESMTP parameter when we have a
perfectly usable mechanism in the RFC's that MTA's MUST accept and ignore
the source routing information?
This preserves the original sender without requiring any additions
to ESMTP (other than undeprecating and noting the new use for reverse
source path). This also lets DSNs go directly to the original
sender without rattling down the chain of forwarders.
If the originating sender uses SES in the return path, there is no way to
attack him with bogus bounces and therefore no need to do the partial
shortcut scheme in SRS.
Forwarders and SPF checkers can start doing this now without violating any
RFCs. I will test this with my sendmail/Python milter setup between
clients currently using SPF/SRS. Even if no one else follow suit,
it's a much cleaner way than SRS to handle forwarding for my own clients.
I glad you see it this way, too. The only change required in SPF is to pick
the leftmost comma separated entry in MAIL FROM: and do the SPF check on
that. No RFROM/FRED/DAVE ESMTP extension to advertise and deal with the
lack of it, no deciding when to add an RFROM/FRED/DAVE to outgoing messages
and a single, simple rule for what address to do SPF checks on for incoming
messages. If there's a downside to this, I don't see it.
--
Seth Goodman