Frank Ellermann writes:
Dick St.Peters wrote:
Lessee ... STD 10 (better known as RFC 821) said:
[...]
Among other things it has this:
[in 3.6 relaying]
Conceptually the elements of the forward-path are moved to the
reverse-path as the message is relayed from one server-SMTP to
another. The reverse-path is a reverse source route, (i.e., a
Yes, and 1123 did not change this.
When relaying from one IPCE to another so the forward path is a source
route through a gateway, the reverse path is the reverse source route
back through the gateway. Technically, it still is to this day if you
can find an IPCE that has not been integrated into or subsumed by the
internet.
[in 4.1.1 MAIL]
As each relay host adds itself to the beginning of the list,
it must use its name as known in the IPCE to which it is
relaying the mail rather than the IPCE from which the mail
came (if they are different). In some types of error
At this point, it's probably worth quoting what an IPCE is, from RFC
821 (STD 10):
An important feature of SMTP is its capability to relay mail across
transport service environments. A transport service provides an
interprocess communication environment (IPCE). An IPCE may cover one
network, several networks, or a subset of a network. It is important
to realize that transport systems (or IPCEs) are not one-to-one with
networks. A process can communicate directly with another process
through any mutually known IPCE. Mail is an application or use of
interprocess communication. Mail can be communicated between
processes in different IPCEs by relaying through a process connected
to two (or more) IPCEs. More specifically, mail can be relayed
between hosts on different transport systems by a host on both
transport systems.
These days when virtually all hosts are in a single IPCE, the
internet, it's often forgotten that email and other internet services
originated when there were multiple networks of multiple types
constituting multiple IPCEs.
(Personally I would claim that 821's definition of an IPCE needs to be
updated. That two PCs are both connected to the internet and can in
general communicate directly does not necessarily mean they can
transmit mail directly. For example, many ISPs block outgoing SMTP
from dynamic-IP hosts. However, we should hardly be surprised that a
definition from 821's day of destop terminals connected by serial
lines to central time-sharing computers on the internet do not always
map well to today's world of desktops, laptops, and even cell phones
on the internet.)
[in 3.1 MAIL]
The <reverse-path> can contain more than just a mailbox. The
<reverse-path> is a reverse source routing list of hosts and
source mailbox. The first host in the <reverse-path> should be
the host sending this command.
[in 3.6 RELAYING]
If when the message arrives at an SMTP the first element of the
forward-path is not the identifier of that SMTP the element is not
deleted from the forward-path and is used to determine the next
SMTP to send the message to. In any case, the SMTP adds its own
identifier to the reverse-path.
Given 821's vision of multiple IPCE's unable to send mail to each
other except by relaying it through internet gateways, these make
eminent good sense.
That 1123 somehow did away with reverse paths back through forwarding
hosts is pure myth.
[in 1123 5.2.6]
A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
explicit source route using the "@...:" address form. Thus,
the relay function defined in section 3.6 of RFC-821 should
not be used.
DISCUSSION:
The intent is to discourage all source routing and to
abolish explicit source routing for mail delivery within
the Internet environment. Source-routing is unnecessary;
[...]
DISCUSSION:
For example, suppose a host that does not implement the
relay function receives a message with the SMTP command:
"RCPT TO:<@ALPHA,@BETA:joe(_at_)GAMMA>", where ALPHA, BETA, and
GAMMA represent domain names. Rather than immediately
refusing the message with a 550 error reply as suggested
on page 20 of RFC-821, the host should try to forward the
message to GAMMA directly, using: "RCPT TO:<joe(_at_)GAMMA>".
Since this host does not support relaying, it is not
required to update the reverse path.
Frank, a hint: RCPT TO involves the *forward* path. Nobody is
claiming that 1123 didn't attempt to do away with source-routed
forward paths for "mail delivery within the Internet environment", to
add context you left out.
In 1982, 821 (STD 10) envisioned a world with many disparate mail
systems in separate IPCEs exchanging mail by gatewaying through
internet SMTP mail. It defined source routes and reverse source
routes as addressing mechanisms to support such gatewaying. While it
did not limit the use of such source routes to cases where inter-IPCE
gatewaying required them, its simultaneously-published companion, 822
(STD 11) did discourage using them for internet-only mail.
Viewing a world in which most mail would reqwuire gatewaying, 821
devoted most of its attention to gatewaying, including source routes.
Internet-only mail was viewed as a relatively trivial case not
requiring gatewaying, source routes, nor much mention.
By 1989, when 1123 was published, the world of networking had largely
changed to one in which most mail-active hosts either were connected
to the internet or were behind opaque gateways that hid internal mail
distribution. Source routing had become little used because it had
become unnecessary for most mail.
When it was used for internet-only mail, it was mostly cases where the
technology had outrun its users. People accustomed to sending to
addresses specified as source routes sometimes still used them. 1123
said mail hosts should ignore these source routes in forward paths and
should send directly to the destination host when possible, which is
what all well-run internet mail hosts were already doing. 1123 left
intact source routes and reverse source routes for their original
purpose, mail needing gatewaying.
Obviously, if users aren't supposed to use source routes and mail
hosts should ignore them as forward paths, then mail hosts shouldn't
construct them as reverse paths. In this sense 1123 did say don't
use reverse source routes more strongly than 821/822 discouraged
them. The added emphasis was in keeping with 1123 being an rfc
documenting what was already being done by well-run internet hosts.
--
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