I suggest replacing the tables (which are a typographical disaster)
with a formalized paragraph structure, for example:
Description: Names and addresses for author(s) of the message content
are listed in the From header.
Description: If a message recipient sends a message that would
otherwise use the RFC2822.From field information in the original
message, they are to use the contents of the RFC2822.Reply-To
field instead. In other words, this field is a direct override of
the From field, for responses from recipients.
The idea of roles is a good addition to the document.
I'm not sure about the "Provider" concept. This is partly because I
don't like the term (it's too generic), partly because I'm not sure
it's useful - it isn't used elsewhere in the document, though the term
Originator/Recipient: Why not use the term "Author" instead of
"Originator"? It should be noted that a message may have multiple
authors and recipients. There's also some confusion of terminology
later in the document, because "originator" and "recipient" are used
to refer to Relays rather than Users in section 3.1.1.
Relay: Is it worth breaking down this category further, e.g. into
outgoing relays (e.g. "smarthosts") and incoming relays (MX hosts)?
Smarthosts in particular are significant because of their evolution
into submission servers in modern setups. These distinctions are
useful for talking about different kinds of access control
configurations (avoiding open relays and firewalling incoming email).
See the Operational Configuration section.
Is it worth adding examples?
This domain name might refer to an entire organization (e.g.
cam.ac.uk), or to a collection of machines integrated into a
homogeneous service (e.g. hermes.cam.ac.uk), or to a single
It is common for sites to have local conventions for sub-structure to
the left-hand side of an addr-spec. This permits sub-addressing,
such as for distinguishing different discussion groups by the same
participant (e.g. fanf9+emailarch(_at_)hermes(_dot_)cam(_dot_)ac(_dot_)uk).
It might be worth explicitly mentioning that messages with the same
message ID can be assumed to be the same, e.g. for the purposes of
reducing the amount of space required by a message store.
I'm not sure what the following sentence refers to: "Although Internet
mail standards provide for a single identifier, more than one is
Identity Reference Convention:
Why MailFrom but Rcpt-To?
Email System Architecture:
The overview diagram is very unclear, especially the arrows around the
outside relating to the envelope, DSN, MDN, and Sieve. The oMUA and
MSA may also use local conventions, as may the MSA and first MTA (e.g.
in the common case where the MSA is part of an MTA).
Should there be a concept of privilege? I.e. MUAs are not privileged,
but everything else is. This is relevant to MSA fix-ups and alias
The commentary about bounce addresses in the RFC822.Sender
description really belongs in the MSA section.
The comment about the BCC field is incorrect according to my
experience: I think it's more usual for the message to be submitted
once, and the MSA deletes the BCC header and transfers its address
list to the RCPT TO list when constructing the envelope.
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.
The MSA section should talk about the header fix-up work it should do,
including adding missing fields (Date:, Message-ID:) and correcting
the Sender: field (in the case that the MSA is more trusted than the
oMUA and the MSA has authenticated the Submitter).
Is the outgoing interface of the MSA required to be SMTP or can it be
a local hook into the first MTA? For example, in the case of `sendmail
-t` should the whole of sendmail be considered to be the MSA or is it
a Siamese twin of MSA and MTA (I prefer the latter)? 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.
One of the difficulties in the tables is that the HELO and Received:
point in different directions, by which I mean that the Received:
field refers to the message's previous hop whereas the HELO argument is
related to its next hop. The HELO argument ends up in the next
Received: field, but isn't directly recorded which makes it a bit of
an odd fellow compared to the other "settings".
I also don't like referring to Received: as an identity because it is
really a composite field containing a number of identities - at least
the previous MTA's HELO, IP address etc. and this MTA's host name etc.
It's too complicated to fit into the model comfortably.
The Return-Path field is set by the MDA not the MTA.
The paragraph about serendpity seems to belong better in the Service
Nothing in this table should be there!
POP and IMAP are not delivery protocols, they are retrieval protocols,
for moving or copying messages from one message store instance to
another (about which more later) or for interactive message store
access (see old names for IMAP!). Note that IMAP doesn't have to be
interactive: it supports a number of usage models as described in RFC
1733 and the next section.
Sieve should be mentioned as a means for controlling the MDA.
I suggest invoking the "architecture is not implementation" clause
here in order to simplify matters. Treat the message store as a single
entity regardless of whether online, offline, or disconnected mode is
being used. The mode of usage determines whether the message store is
a single entity or two entities. This will help greatly with the
diagram in section 4.
Is it worth distinguishing online mode and local message store access?
Sieve should be mentioned as a means for controlling the movement of
messages in offline mode under control of the rMUA.
Layers of Identities:
"message header" not "headers". The same error is made in a section
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.
Two Levels of Store-And-Forward:
Care is needed with the term "re-submission". It seems to imply that
RFC 2476 fix-ups occur, which is not the case in alias handling. I
still think alias handling is privileged, and architecturally an MDA
function rather than an MUA function: it happens before the
Return-Path: field is added to the message; some MSAs restrict the
user's ability to set the bounce address, but this restriction doesn't
apply to alias-forwarded email because the MSA isn't in the loop.
There should also be a section on MTA firewalling, to distinguish it
MUA Basic Forwarding:
Should it be called encapsulation forwarding? The MIME type
message/rfc822 should be mentioned.
This should not be referred to as redirecting because redirect is the
sieve command for alias forwarding.
The Actor for the To,CC,BCC fields should be the Originator. The Actor
for the Rcpt-To should be the Intermediate Submitter.
The terminology in the table isn't consistent with the terminology in
the preamble. Recipient-1 or Intermediate Originator/Submitter?
Would it be worth adding the following clause to the end of the
sentence to make the presence of this section clearer? "though it
may contain a quote from the original message."
Aren't these really at the MTA level? Putting them at the MUA level
implies a "final delivery" event before the message reaches the
MUA Alias Handling:
I've already said I think this is an MDA function.
The actors are all wrong. to/cc/bcc should be "originator", rcpt-to
should be "intermediate recipient", mailfrom should be "submitter",
received should be "forwarder".
MUA Mailing Lists:
The actor for the Sender should be the intermediate submitter not the
original submitter. For to/cc it is the originator. For rcpt-to it is
the intermediate submitter.
Whew. I think that's all.
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
EAST FITZROY: SOUTHWEST 4 OR 5, OCCASIONALLY 6 LATER. RAIN OR SHOWERS.
MODERATE OR GOOD.