Frank Ellermann writes:
Dick St.Peters wrote:
Wrong! Whatever you think of 1123 5.3.6(a), it simply documented what
was already nearly-universal practice.
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. (I
don't recall ever seeing one either, although I'm hardly about to
claim I remember every MAIL FROM I've ever seen.)
Of course, back then a lot of mail was forwarded from BITNET or NFSNET
or UUCP mail - meaning from places not directly reachable - and this
mail did have the forwarding gateway prepended to the MAIL FROM. This
was a technical necessity. However, hosts forwarding internet SMTP
mail to other internet SMTP hosts did not prepend themselves to the
MAIL FROM as reverse path gateways. Email admins (of which I was one)
weren't stupid and didn't want the reverse mail passing through their
systems when it didn't have to. 1123 simply documented the practice
of forwarding with a minimalist reverse path.
At the time, there was a lot of work being put into eliminating the
need for mail to hop from system to system, not just on the internet
but within other mail systems as well. By then UUCP mail largely
ignored any specified path and simply looked up the shortest path in
the topology map and used it. (UUCP mail was often in response to
USENET articles, and the latter often involved highly convoluted
paths.) I suspect many internet mail sites also ignored any paths
specfied in addresses and simply connected directly to the destination
site, although I can't say for sure because such paths never came up
in my experience. 1123 simply came along and stamped this
direct-to-destination stuff as good.
By 1123 time, even prepending gateways from other mail systems to the
reverse path was questionable, because many gateways were one-way.
For example, if you wanted to reply to mail from a BITNET source, you
often had to route it through a gateway that would accept and forward
mail from your site, which often was different from the gateway that
forwarded mail from the BITNET source.
RFC 1123 removed the source routes for various (mostly good) reasons.
That implicity also killed the reverse paths (minus the special case
empty reverse path for error reports). Without the reverse paths the
forwarders were not more responsible to know what they're doing - the
error reports would go "directly" to the alleged originator. With that
we eventually got forged return paths and open relays and spam spam
spam.
Yes, but blaming forwarding for spam is like blaming email for spam.
Without email, there'd be no spam, so let's fix the problem by getting
rid of email ... :)
Forwarding is not the problem. Abuse of email is the problem. That
preserving the forwarding feature makes SPF a difficult "fix" for
email problems is a defect of SPF, not a condemnation of forwarding.
It's often easier to solve problems by tossing out features many
people don't use. However, when many other people do use the
feature(s) you would sacrifice, such disregard for their needs is a
tremendous barrier to building any consensus. You may have noticed a
lot of resistance to SPF, and you might consider why that is.
--
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