Re: [Fwd: [Asrg] Verisign: All Your ...

--On Saturday, 20 September, 2003 11:02 -0600 Doug Royer 
<Doug(_at_)Royer(_dot_)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