On Thu, 18 Sep 2003, Doug Royer wrote:
No, its not valid for a mail client to make direct connections.
Can you site any RFC that says that?
RFC 2821 (proposed standard) sheds some light on that: (This isn't a
replacement to STD0010, but reveals the disagreement on the roles of MTAs
and MUAs)
2.3.3 Mail Agents and Message Stores
Additional mail system terminology became common after RFC 821 was
published and, where convenient, is used in this specification. In
particular, SMTP servers and clients provide a mail transport service
and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
Agents" (MUAs or UAs) are normally thought of as the sources and
targets of mail. At the source, an MUA might collect mail to be
transmitted from a user and hand it off to an MTA; the final
("delivery") MTA would be thought of as handing the mail off to an
MUA (or at least transferring responsibility to it, e.g., by
depositing the message in a "message store"). However, while these
terms are used with at least the appearance of great precision in
other environments, the implied boundaries between MUAs and MTAs
often do not accurately match common, and conforming, practices with
Internet mail. Hence, the reader should be cautious about inferring
the strong relationships and responsibilities that might be implied
if these terms were used elsewhere.
Note the last sentence, which tends to refute the notion that there are
implied boundaries between MTAs and MUAs. This reflects your idea. But of
course, this is a proposed standard, and not a full standard. And there
are good reasons to reject this.
Most people, and the market for mail software, tend to support the notion
that there is a distinction and a boundary between MUA and MTA.
RFC 821 (STD0010) Section 2:
The argument to the MAIL command is a reverse-path, which specifies
who the mail is from. The argument to the RCPT command is a
forward-path, which specifies who the mail is to. The forward-path
is a source route, while the reverse-path is a return route (which
may be used to return a message to the sender when an error occurs
with a relayed message).
MTAs route mail. MUAs do not.
There are many ISPs that block this. Are they doing something wrong?
Orthogonal and unrelated.
Certainly not. If it is valid for the MUA to connect directly, then it is
invalid to block this, assuming such mail privileges were given. Such
ISPs give MUA privileges, not MTA privileges. So this distinction is
useful technically and contractually.
Mail clients are supposed to connect to their configured mail relays,
which has the responsibility to route mail.
Says who?
At the very least, the market of system administrators who purchase mail
software; most mail clients that are configured to use a specific relay.
Most mail clients do not connect directly. And the market that wants to
unbundle MUA services from MTA services.
Breaking existing applications like MUA's (and your ISP's relays)
is wrong.
Those have not been broken. Mine work just fine.
IF some were misconfigured previously, then it is the administrators who
misconfigured them who are at fault, not Verisign.
--Dean