From: Stuart D. Gathman [mailto:stuart(_at_)bmsi(_dot_)com]
Sent: Thursday, September 15, 2005 10:12 AM
On Thu, 15 Sep 2005, Dick St.Peters wrote:
[1] Aside to Frank: I believe this "end-to-end" notion is implicit in
existing RFCs, something like construction of reverse paths by moving
elements from forward path to reverse path => reverse (and forward)
source routes being collapsed to direct connection => one-hop
MAILFROMs => end-to-end MAILFROMs ... => SRS reintroducing indirect
reverse paths. That last step is the origin of my comment that I feel
my using SRS violates RFCs. I use it because only the letter of the
RFCs is violated, not the spirit - meaning DSNs still make it back to
the original MAILFROM.
I agree with your analysis. However, you are not really even
breaking the letter of your exposition of the RFCs.
Since the parties you forward mail to have (explicitly or implicitly)
authorized you to forward them mail, you have become a gateway
for their mail domain.
As convenient as it is, I really can't buy the argument that forwarders are
really gateways. Unfortunately, various standards and proposed standards
say what gateways and forwarders are, and they are clearly different. If
they had meant them to be the same, they would have simply said "forwarders
are considered as gateways" and been done with it. That would have made the
standards simpler, but they didn't do that. They gave specific sections
devoted to alias forwarding that had different rules than for gatewaying.
I'll start at RFC1123, since RFC821 is missing so much of what the internet
has today that it is hard to apply sensibly. Here's what RFC1123 says about
alias forwarding:
5.3.6 Mailing Lists and Aliases
An SMTP-capable host SHOULD support both the alias and the list
form of address expansion for multiple delivery. When a
message is delivered or forwarded to each address of an
expanded list form, the return address in the envelope
("MAIL FROM:") MUST be changed to be the address of a person
who administers the list, but the message header MUST be left
unchanged; in particular, the "From" field of the message is
unaffected.
DISCUSSION:
An important mail facility is a mechanism for multi-
destination delivery of a single message, by transforming
or "expanding" a pseudo-mailbox address into a list of
destination mailbox addresses. When a message is sent to
such a pseudo-mailbox (sometimes called an "exploder"),
copies are forwarded or redistributed to each mailbox in
the expanded list. We classify such a pseudo-mailbox as
an "alias" or a "list", depending upon the expansion
rules:
(a) Alias
To expand an alias, the recipient mailer simply
replaces the pseudo-mailbox address in the envelope
with each of the expanded addresses in turn; the rest
of the envelope and the message body are left
unchanged. The message is then delivered or
forwarded to each expanded address.
Here's what RFC1123 says about gateways:
5.3.7 Mail Gatewaying
Gatewaying mail between different mail environments, i.e.,
different mail formats and protocols, is complex and does not
easily yield to standardization. See for example [SMTP:5a],
[SMTP:5b]. However, some general requirements may be given for
a gateway between the Internet and another mail environment.
(A) Header fields MAY be rewritten when necessary as messages
are gatewayed across mail environment boundaries.
<discussion snipped>
(B) When forwarding a message into or out of the Internet
environment, a gateway MUST prepend a Received: line, but
it MUST NOT alter in any way a Received: line that is
already in the header.
<discussion snipped>
(C) From the Internet side, the gateway SHOULD accept all
valid address formats in SMTP commands and in RFC-822
headers, and all valid RFC-822 messages. Although a
gateway must accept an RFC-822 explicit source route
("@...:" format) in either the RFC-822 header or in the
envelope, it MAY or may not act on the source route; see
Sections 5.2.6 and 5.2.19.
<discussion snipped>
(D) The gateway MUST ensure that all header fields of a
message that it forwards into the Internet meet the
requirements for Internet mail. In particular, all
addresses in "From:", "To:", "Cc:", etc., fields must be
transformed (if necessary) to satisfy RFC-822 syntax, and
they must be effective and useful for sending replies.
(E) The translation algorithm used to convert mail from the
Internet protocols to another environment's protocol
SHOULD try to ensure that error messages from the foreign
mail environment are delivered to the return path from the
SMTP envelope, not to the sender listed in the "From:"
field of the RFC-822 message.
<discussion snipped>
(F) Similarly, when forwarding a message from another
environment into the Internet, the gateway SHOULD set the
envelope return path in accordance with an error message
return address, if any, supplied by the foreign
environment.
This is pretty clear. Gatewaying involves relaying between the internet
using SMTP and private networks, generally using a foreign protocol. Alias
forwarding mail from one internet host to another is clearly not within this
description. RFC2821/2822 maintain this dichotomy between gatewaying and
alias forwarding. Though alias forwarding does do some of the functions
inherent in a gateway, it is obviously not a gateway and the sections
specifically devoted to alias forwarding apply to forwarders.
As far as SRS goes, I point to the sentence in 1123 where it specifies for
alias forwarders:
To expand an alias, the recipient mailer simply
replaces the pseudo-mailbox address in the envelope
with each of the expanded addresses in turn; the rest
of the envelope and the message body are left
unchanged.
Unchanged, IMO, means that forwarders can't change the return-path. I agree
with Dick that SRS does violate the letter of the standard, but perhaps not
the spirit. While the standard intended a DSN to reach the recipient in a
single hop (by deprecating source routes), SRS brings back a partial source
route and forces one relay for a DSN. We've had numerous discussions on
this list as to resurrecting source routes, as all MTA's are REQUIRED to
parse and ignore the deprecated format, so if they are compliant, they at
least will do the right thing when presented with a source route list. That
list would allow an SPF recipient to use the most recent address for the SPF
check and generally result in a pass. Unfortunately, that idea was roundly
rejected. If it is impractical to get forwarders to add their address to a
source route list on forwarded messages, I don't see that SRS is any more
practical from the adoption standpoint. At least with source routes,
existing MTA's will still send the DSN to the original sender without a
relay hop. But we lost that battle, so it's not going to happen. Neither,
I argue, is SRS on a wide enough scale.
--
Seth Goodman
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com