Most of your responses seem to be in general agreement, which is good.
Some follow-up comments:
Originator/Recipient: Why not use the term "Author" instead of
legacy term. orig/recip are from the X.400 days and have a pretty high
installed base of usage. I do not see our community having a dominant
practise of using author -- although it does seem to have a high enough
occurrence to cite the term also -- and this document is not trying to
establissh new practise.
Hmm. My problem is that "originator" seems ambiguous between "author(s)"
(i.e. 822.From) and "submitter" (822.Sender).
It should be noted that the submission protocol does not lie on
the boundary between the MSA and MUA, because when it is being used
the user's software has to do some MSA work like setting up the
message envelope and handling the BCC: header field. An example of
an implementation boundary which lies on the architectural boundary is
the `sendmail -t` API in Unix.
I definitely am used to thinking of protocols as residing at boundaries,
pretty much by definition, and I hope we are VERY careful about
maintaining the distinction between the abstract architecture, versus
I agree. However in the ugly tables you say that the envelope is created
by the MSA, but from a the protocols point of view (and from the point of
view of most software these days) the MUA must create the envelope in
order to be able to talk to the MSA. Hence my chatter about `sendmail -t`
being the canonical MSA interface, rather than RFC 2476.
This relates to
whether the MSA can be said to "set" a HELO identity (I would say
not). Additional confusion is caused by the submission protocol, in
which a HELO identity is "set" by the MUA part of the MSA.
Whatever entity is doing the client side of smtp (or submit) is the
entity that sets the helo identity.
Again, inconsistency in the tables. The tables say "submitter" but should
say "operator" or "administrator" (which is a role we don't have at the
The only question this leaves is about choices for delivery protocols.
I think the answer is reduced to <local> or SMTP.
LMTP is intended for this role.
Sieve should be mentioned as a means for controlling the MDA.
The diagram shows sieve as feeding into the MDA.
Hmm. Sieve's a scripting language. What architectural entity interprets
Is it worth distinguishing online mode and local message store access?
although the operational difference is important, how does that affect
Whether an Internet protocol is being used or not.
The details of communication with the message store and where it resides
etc. in this section are rather complicated, because a lot of the
functions can be implemented in either or both of two places (on the
server and/or the client), with or without network protocols in between.
Sieve should be mentioned as a means for controlling the movement of
messages in offline mode under control of the rMUA.
In the IMAP world, the MDA interprets a Sieve script to determine which
mailboxes to deliver the message into, and the MUA talks IMAP to the
message store to access the email.
In the POP world, the MDA delivers into a single mailbox per user, and the
MUA periodically copies it to a local store. In the course of storing the
email locally the MUA can interpret a Sieve script to determine which
local mailbox to store each message in.
I find it useful to distinguish between the "message envelope" (i.e.
the sequence of SMTP commands before DATA) and the "message data"
(which consists of everything after DATA, i.e. the "message header"
and the "message body"). Before this document I haven't heard of
anyone including trace fields in the envelope.
heh. heh. I think I'm not the only one that has been doing it for many
years. But, yes, I know it is not the view of lots of folks. It's
probably worth having some discussion about this.
The reality of the trace fields is that they are strictly the result of
the handling service. They have nothing to do with the user-to-user
message. That's the basis for drawing the line, in my view. The fact
that some handling information is passed in smtp commands and others are
passed in rfc2822 headers is secondary, in my view.
I think it's essential to have a word to describe the SMTP commands that
occur before DATA (i.e. MAIL FROM and RCPT TO). See above in the
discussion about MSA for an example. I'm not sure what you mean by
"user-to-user message" and how it can be used to draw a line through the
message header. The Subject: is probably included. Are the addressing
fields included? What about instructions to the MSA (BCC:)? What about
Date:? Message-ID:? X-Mailer:? When a message is Resent- are the trace
fields from the original message now part of the "user-to-user message" or
There should also be a section on MTA firewalling, to distinguish it
I'm inclined to agree, but let's explore this a bit. What is the
architectural role of a firewall? I understand it's operational import,
of course, but how does this relate to an/the architecture?
We need a word to talk about the parts of the MHS that might mangle
messages. You mentioned fleshing out the operational side of the
architecture, so that we can talk about outgoing relays and incoming MXs
etc. and in this context the border firewall MTA is becoming practically
Aren't these really at the MTA level? Putting them at the MUA level
implies a "final delivery" event before the message reaches the
Gateways are strange beasts, indeed. My experience forces me to view
them as hybrid MTA/MDA/MUA devices. The basic point is that a gateway
messes mightily with the content. So it is not merely a variant of an
MTA. On the other hand, your point about the possibility of deferring
the formal delivery event to a point after the gateway is well taken.
From the content mangling point of view they are close to firewall MTAs.
They are clearly inside the MHS boundary so are not MUAs.
MUA Mailing Lists:
Mailing lists are one example of a class of "user-level multi-hop
process" functions that are part of group activity, including such fun
stuff as organizational flow mechanisms like purchase approval". I
think the architectural reference needs to encompass this range of
functions, rather than being tailored to mailing lists.
That sounds like a useful way of clarifying things.
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SOLE LUNDY FASTNET: NORTH BACKING WEST OR SOUTHWEST 5 OR 6, INCREASING 7
PERHAPS GALE 8 LATER. RAIN LATER. GOOD BECOMING MODERATE OCCASIONALLY POOR.