Daniel Feenberg wrote:
It's a subtle bug, all reasons given in RfC 1123 for
dropping the source routes are convincing.
[...]
Can you be more specific about where the reasons are given?
<http://tools.ietf.org/html/1123#section-5.2.6>
| 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;
| the simple target address "user(_at_)domain" should always
| suffice. This is the result of an explicit architectural
| decision to use universal naming rather than source
| routing for mail. Thus, SMTP provides end-to-end
| connectivity, and the DNS provides globally-unique,
| location-independent names. MX records handle the major
| case where source routing might otherwise be needed.
With end-to-end connectivity (that excludes 251-forwarding)
source routes are unnecessary, the MX is always good enough.
| Some have suggested that source routing may be needed
| occasionally for manually routing mail around failures;
| however, the reality and importance of this need is
| controversial. The use of explicit SMTP mail relaying for
| this purpose is discouraged, and in fact it may not be
| successful, as many host systems do not support it. Some
| have used the "%-hack" (see Section 5.2.16) for this purpose.
Besides they offered worse ideas for forward-routing issues.
Of course the "%-hack" is now deprecated (2821). Missing the
point of _reverse_ paths for the 5.3.6(a) case.
<http://tools.ietf.org/html/1123#section-5.2.19>
| In an understatement, RFC-822 says "The use of explicit
| source routing is discouraged". Many hosts implemented
| RFC-822 source routes incorrectly, so the syntax cannot be
| used unambiguously in practice. Many users feel the
| syntax is ugly. Explicit source routes are not needed in
| the mail envelope for delivery; see Section 5.2.6. For
| all these reasons, explicit source routes using the RFC-
| 822 notations are not to be used in Internet mail headers.
| As stated in Section 5.2.16, it is necessary to allow an
| explicit source route to be buried in the local-part of an
| address, e.g., using the "%-hack", in order to allow mail
| to be gatewayed into another environment in which explicit
| source routing is necessary. The vigilant will observe
| that there is no way for a User Agent to detect and
| prevent the use of such implicit source routing when the
| destination is within the Internet. We can only
| discourage source routing of any kind within the Internet,
| as unnecessary and undesirable.
In other words source routes plus %-hack plus bang paths were
messy and often didn't work as expected. The MX concept is
better. For no-nonsense Return-Paths, they had more pressing
needs than forged Return-Paths in 1989. My bat-book printed
1994 has 792 pages, and editing sendmail.cf was a royal PITA.
In 1123 section 5.3.7 you might "see" why 5.3.6(a) was a bad
idea to start with, unfortunately too little too late.
I can find MUST and SHOULD - no rationale.
Their rationale often starts with lines "DISCUSSION:" in 1123.
Bye, Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg