--On Saturday, 20 September, 2003 11:02 -0600 Doug Royer <Doug@Royer.com> wrote:
Dean Anderson wrote:
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)
Your quote talks about conventions that may be used. It does not support your view that the MUA and MTA have to be separate pieces of code. And what your ISP does for your does not have to be what other ISPs do for their customers.
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. ....
Sigh. I had hoped to just avoid this discussion, but... There is no disagreement at all, certainly no intentional disagreement, between 821 and 2821 on this point other than on matters of terminology. That is exactly what 2.3.3 is intended to say: new terminology has come into use, and 2821 was, to the degree it was reasonable, aligned to that terminology. 821 talks about "SMTP Senders" and "SMTP Receivers" and not about MUAs and MTAs, mostly because those latter terms weren't common yet. And 2821 was mostly shifted to talk about "SMTP Client" and "SMTP Servers" in preference to "SMTP Senders" and "SMTP Receivers", again, to match contemporary usage -- although there are some situations in which the old terminology was retained because the client/server version wasn't clear enough. Frankly, I often regret making that change, since it seems to lead to discussions like this one.
There is now, nor has there ever been, any requirement that MUAs and MTAs be on separate machines or under separate administration (or even separate software modules). Some of the language in 2821 was written to make it clear that having a local, low-capability, MTA (SMTP client) send all of its mail to a higher capability server (acting as an SMTP Receiver to collect that mail and then as an SMTP Sender to push it out) rather than handling, e.g., general name resolution and queuing itself.
But the text was fairly carefully written to not prefer one of the following cases over the other:
(i) SMTP Sender on the originating machine (the one that houses the MUA, or an SMTP Sender that is part of the same code module as the MUA) does all processing, sending mail to target destinations as listed in RCPT commands, and queuing and retrying if needed. (ii) SMTP Sender on the originating machine sends all traffic, via SMTP, to a mail relay that takes care of processing, distribution to individual recipients, and queuing. In this case, the destination to which the SMTP Sender delivers the mail is a function of configuration, not of the addresses in the RCPT commands. (iii) SMTP Sender on the originating machine examines the RCPT commands and tries to send the mail out directly, using MX resolution, etc. If it cannot successfully establish a connection and deliver the mail on the first try, it forwards it to a pre-configured relay, as in (ii). (iv) The originating MUA, and associated code, hands the message off to an MTA for further processing using some non-SMTP means. That means could be RFC 2746 SUBMIT or virtually anything else (even some batch process running over a non-TCP network). 2821 is quite deliberately agnostic (as was 821) about how the message reaches the first-hop MTA (SMTP Sender).
If the text of 2821 is not clear on that subject, suggestions of specific improved text would be welcomed.
john