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.
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.
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.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.