Description of Gateways and list expanders as users is not
enlightening; it is confusing. They do not interact with
(human or automaton) users except circumstantially; they
are part of the transport process and act like any other
store-and-forward transport component other than the
expander- or gateway-specific operations.
Section 2.1 refers to the MHS as monolithic; it is not --
it is composed of autonomous agents (MTAs, MSAs, MDAs,
gateways, list expanders) and a user may receive a delivery
notification of some sort from any of those agents.
Section 2.1.1 conflates author with sender; they are
distinct concepts except where they happen to refer to the
same entity by coincidence. The author is responsible for
creating content; the sender is responsible for initiating
transport. RFC 2822 has some clear text delineating the
In Section 2.1.2, "responds" and "responses" would be
preferable to "replies" and "reply"; the latter terms
imply a query, which is applicable to MDNs, but not to
Section 2.3 illustrates the confusion caused by conflating
author and sender. Also, referring to a mailing list as
a Mediator may apply to a moderated mailing list, but a
simple list expander is simply another store-and-forward
MTA with the side-effect of expanding a list alias into
(typically multiple) recipients. Stating that a (list
expander) Mediator originates messages is confusing; it
does not originate messages -- the author does -- the
list expander merely distributes messages. By analogy,
the claim that list expanders originate messages is like
a claim that Barnes&Noble writes textbooks.
Section 2.2. states that "it is legal to have only one
[relay]"; in fact it is legal to have none, with the
oMUA connecting to the recipient's MDA as indicated by
an MX record. [or, as noted below, making local delivery]
Section 2.2.2 says that notices are sent to an "address"
specified by the "Source" (described as for an MSA); in
fact Message Disposition Notices are sent to a list of
mailboxes (not an address) specified by the originator.
Delivery status notifications are sent to the return path,
which might be unrelated to the author or (2822) Sender
field (the return bath is elsewhere in the draft called
a "Notices handling 'address'").
Section 2.2.4 refers to gateways as user processes; they
are part of the normal store-and-forward transport
Section 2.3. contains the typo "this distinctions".
Section 3 text contains "mailbox address <addr-spec>"
which conflates 4 different things:
1. an address is a named group or a mailbox
2. a mailbox is an addr-spec, or an addr-spec enclosed
in angle brackets (known as an angle-addr) with an
optional display name
3. angle-addr, described above
4. addr-spec, which itself includes no brackets
See RFC 2822 for details.
Section 3.1 claims that domain names are equivalent to
the "Administrative Domains" defined in the document;
that is not necessarily so. A single administrative
entity may be responsible for multiple DNS domains, or
a single DNS domain may have portions (subdomains)
administered by multiple entities. The "cookie"
analogy is weak and unenlightening; it is confusing
because the history of cookie use in HTTP is that
cookies have been read and interpreted by entities
other than those setting the cookie.
Additional markers referring to RFCs 1034 and 1035
would be appropriate in section 3.2.
The last paragraph of section 4.4 should probably start
with "An identifier", given the reference to multiple
identifiers (examples of which are Received field "id"
components [though RFCs 821 and 1123 botched that]).
The figure in section 4 is botched by a page break.
Gateways, list expanders, and aliasing really belong
in section 4; they fit between the oMUA and rMUA in
the transport stream.
Section 4.1 refers to "a tree" of message components;
technically the structure may be a graph (due to CID
references (RFC 2557) etc.) rather than a tree (graphs
are more general than trees). The reference to RFC
2298 in section 4.1 is obsolete; all references should
be checked (the RFC Editor provides the file "rfc-ref.txt"
which can be used to obtain correct references as it
indicates which RFCs have been obsoleted by others).
Section 4.2 states than the oMUA always connects to an
MSA, which is incorrect. It may connect to any of several
types of MTA, or to the recipient's MDA. For that matter,
it might directly make local delivery for local
recipients. The section states that "[a] Mediator is
[a] special class of MUA" which is simply untrue in the
case of a list expander; there is no UA or UI or user
involved. The discussion of the Reply-To field is an
oversimplification; the destination of responses has as
much to do with the desires of the respondent as it does
with the suggestion made by the author (which is what
the Reply-To field contains). The discussion of the
Sender field states that in absence of that field, the
message From field takes its place, and equates 2821
MAIL FROM command arguments to the 2822 header field
Sender. That is wrong on two counts:
1. The Sender field is independent of the SMTP command
arguments, except by coincidence of implementation
(and the draft correctly notes that architecture
should be described independently of any implementation
2. The Sender field is never used for automatic responses,
nor automatically presented as a response destination
by an rMUA (unlike the From field and the SMTP return
Description of To and Cc fields as recipient addresses
(in this case the fields do in fact specify address lists)
but that is no more true of email than it is of names
listed on the pages of paper mail, concealed inside the
envelope; typically there is some correspondence between
the "recipients" (and author(s)) listed in the header and
those actually used by transport, but architecturally
there is no such requirement nor relationship.
The description of MSAs in section 4.3 should change
"operates" to "may operate" (RFC 2476 permits operation
on port 25). The discussion of Received fields added
by MSAs should change "may" to MUST (an MSA is an [E]SMTP
receiver, and RFC 2821 sect. 4.4 REQUIRES insertion of
Draft section 4.4 states that MTAs do not make changes
to "addresses" in the "envelope", such changes do happen
in the SMTP envelope, recording/removing path (old
implementations), resolving aliases, expanding lists,
and/or as part of gateway operations. As noted above,
SMTP MTAS MUST (not "may") insert trace fields.
Section 5, speaking of Mediators (and having categorized
list expanders as Mediators), refers to "other MUAs".
List expanders are not MUAs!
Aliasing as described in section 5.1 is claimed to be
"strictly a Recipient user function". It is sometimes
an administrative function, mere users not being
permitted to fiddle with aliases. The draft continues,
claiming that aliasing "resubmits the message, replacing
the 'envelope' 'address'"; aliasing may involve translation
to a local mailbox, in which case there is no resubmission,
no SMTP envelope, and may be no rewriting of "envelope"
information stuffed into the message header.
Resending (section 5.2) omits mention of the RFC 2822
Resent-Date field, which is REQUIRED if any other Resent-
field is used! Nor does it mention Resent-Message-ID,
which is another example of an additional identifier.
Section 5.3 mentions something called a "ReDirector" which
is undefined and mentioned nowhere else in the draft. The
same section incorrectly describes the Reply-To field as
"Originator or Mediator"; it is defined (in RFC 2822) as
an Originator field. No transport entity (list expanders
or otherwise) should alter that field; significant problems
have been caused by violation of that transparency rule.
Conversely, "RFC2821.MailFrom" should always be set to
the mailbox of the list administrator by a list expander.
In section 7.2, the customary term is "Informative"
references. It is unclear why the references are formatted
differently in this section from 7.1 (peculiar line and