On Sat April 9 2005 12:08, Tony Finch wrote:
On Fri, 8 Apr 2005, Bruce Lilly wrote:
On Fri April 8 2005 11:48, Tony Finch wrote:
On Tue, 5 Apr 2005, Bruce Lilly wrote:
Routes in paths are now somewhat uncommon, but are not obsolete and
should not be ignored in a description of the mail system architecture.
They've been strongly deprecated since RFC 1123 (dated 1989) which states
that this is for architectural reasons. Therefore I think it's legitimate
for a modern description of the architecture to omit source-routed paths
on the grounds that they are an anomalous historical relic.
See section 5.2.6 of 1123.
Yes, that's what I'm referring to. It says that explicit source routes
SHOULD NOT be used by SMTP clients and that they are unnecessary and will
be abolished.
It also says:
A receiver-SMTP MUST accept the explicit source route syntax in
the envelope, but it MAY implement the relay function as
defined in section 3.6 of RFC-821. If it does not implement
the relay function, it SHOULD attempt to deliver the message
directly to the host to the right of the right-most "@" sign.
N.B. "MUST" indicates a mandatory requirement (yes, I'm being redundant,
for emphasis), whereas "SHOULD NOT" is a mere recommendation.
If, in accordance with that requirement, a route is received, the
envelope route WILL [*] be modified by a relay whether or not it ignores
the route. That is why I noted that the draft statement that the
envelope is not modified is incorrect.
Also, routes are still sometimes necessary to work around temporary DNS
and related problems (I've had to use them several times in the past few
years).
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.
I expect that is even more true 15 years later.
As I mentioned, I have found the facility both necessary and successful
recently.
* where "WILL" means that the specified operation takes place in all
RFC-conforming implementations, without exception.