Ned Freed says:
I sez:
This is exactly the problem with the current model. SMTP *is* an
end-to-end system.
Says who? SMTP explicitly allows for source routing in addresses. This is not
something tacked on as an afterthought -- it is a well documented and
heavily used aspect of the protocol. The host requirements RFCs have
confirmed the status of routing in SMTP.
Says me, says Host Requirements, says the IETF. In host requirements
we depricated source routing just for this purpose. I know, I was
there when we did it. Understand that this is not a routing argument,
but an argument about whether SMTP is end-to-end. The two are
necessarily related. Here are some of the relevant passages, to
refresh your memory:
5.2.1 The SMTP Model: RFC-821 Section 2
[...]
The text of RFC-821 suggests that mail is to be delivered
to an individual user at a host. With the advent of the
domain system and of mail routing using mail-exchange (MX)
resource records, implementors should now think of
delivering mail to a user at a domain, which may or may
not be a particular host. This DOES NOT change the fact
that SMTP is a host-to-host mail exchange protocol.
5.2.6 Mail Relay: RFC-821 Section 3.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;
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.
5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7
Internet host software SHOULD NOT create an RFC-822 header
containing an address with an explicit source route, but MUST
accept such headers for compatibility with earlier systems.
DISCUSSION:
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.
This means that right now, if a site accepts
delivery for a message, it has the means under normal circumstances to
deliver it - in essense offering that gaurantee.
Not true. The PP mailing list had a huge debate on this issue some time back --
I suggest you check the archives for that list if you're really interested.
Sir, I've been in more arguments about this issue than I care to. The
PP people have had their arguments, I'm sure. But this is an
important point, because I believe it is one of the features that has
kept our mail system as clean as it is. So if you want to rehash it
with me, let's.
[yet another example of how to screw up a mail system; expunged]
I think we agree that it is important to keep 8 bit mail from 7 bit
MUAs. We can do that by using lookaheads and by agreeing that this is
an SMTP standard. Keeping SMTP end to end is the simplest way to keep
the hair of unnecessary complexity off of our systems.
This is not to say that conversions won't be necessary; just that your
average agent shouldn't need them. You may need to do conversions if
you explode mail for mailing lists or for user forwarding. This is
not an SMTP matter, however. It would occur essentially where final
delivery would otherwise occur. How that happens should be
recommended, but it is essentially an implementation detail once an
acceptable conversion format is agreed to.
More and more we are seeing ``mailing list processors'' handle mailing
lists. There's even an IETF working group of which I bet few if any
of you are probably aware. The function of such a list processor may
well be to handle this situation.
This leaves the case of forwarding mail to another site, and it can be
handled with a conversion utility, which presumably will be available
in the long term, when 8 bit smtp is to be implemented.