Frank Ellermann writes:
Before 1123 the principle of operation was to add forwarding hosts
to the reverse path. It wasn't possible to modify the RCPT TO
without also modifying the MAIL FROM (adding an @forwarder.example
to the reverse path)
Not in my expereience. I still have a lot of email from the mid-80s,
before 1123 was issued. A lot of it was forwarded, and except for
mail forwarded from non-SMTP mail systems, I can't locate a single
example that had a forwarding host prepended to the MAIL FROM.
STD 10 is absolutely clear about this, but I can't say what sendmail
actually did at this time (before 1989). My sendmail "experience"
was some years later and about some shaky UUCP routes.
Lessee ... STD 10 (better known as RFC 821) said:
The SMTP provides mechanisms for the transmission of mail; directly
from the sending user's host to the receiving user's host when the
two host are connected to the same transport service, or via one or
more relay SMTP-servers when the source and destination hosts are not
connected to the same transport service.
In other words the context for what follows is two cases: 1) mail
between the internet and some other network (such as BITNET) which is
relayed through an SMTP gateway, and internet-only mail which is
direct from source to destination. It goes on to say:
To be able to provide the relay capability the SMTP-server must be
supplied with the name of the ultimate destination host as well as
the destination mailbox name.
The argument to the MAIL command is a reverse-path, which specifies
who the mail is from. The argument to the RCPT command is a
forward-path, which specifies who the mail is to. The forward-path
is a source route, while the reverse-path is a return route (which
may be used to return a message to the sender when an error occurs
with a relayed message).
So yes, it was very clear. The reverse path is where error message
go, and for internet-only mail that's directly to the destination of
the error message, i.e. the source of the message that caused the
error.
Nowhere did it say, or even suggest, that the reverse path should be
back through any forwarding hosts unless they were gateways to/from
other transport services. Instead, it says mail (which includes error
messages) should go directly to the destination.
STD 11 (better known as RFC 822) was even more explicit:
Note: The use of source routing is discouraged. Unless the
sender has special need of path restriction, the choice
of transmission route should be left to the mail tran-
sport service.
Overall, STD 10 and 11 said source routing exists to get mail from one
mail system type to another but isn't necessary for internet mail, and
its use for internet mail is discouraged. In keeping with this, hosts
forwarding mail told destinations to send any error responses directly
to the source. They did this by NOT prepending themselves to the
reverse path.
This is what the STDs say to do, it's what I remember being done, and
it's what 1123 reiterated. That 1123 somehow did away with reverse
paths back through forwarding hosts is pure myth.
For those who have never read 1123, most of it isn't even about mail.
1123 is a collection of things expected of internet servers, and much
of it is about FTP, telnet, and what it calls "support services" like
DNS. It collected and discussed a bunch of things from other RFCs in
one document, without (I think) actually changing much of anything
except emphasis in a few cases.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735