Miscellaneous comments on draft-crocker-email-arch-04.txt

[Bruce Lilly <[e-mail]>]

The Abstract and Introduction refer to "the first standardized
architecture for email".  That would be FTP (MAIL and MLFL commands).
I believe that the quoted phrase above should be replaced by "RFC 821".

The introduction also states "Core aspects of the service, such as
address and message style, have remained remarkably constant."  In fact
there have been significant changes, not all beneficial.  Initially
messages were completely unstructured; RFC 561 added structure by
separating message content into header and body.  Both header and body
were end-to-end (see RFC 1958) user-to-user communication until RFC 788
started insertion of transport markings into the message content.
Subsequent extensions (e.g. RFC 2919) have added more "bumper
stickers".  It is incorrect to imply that these changes haven't
happened; at minimum these changes should be acknowledged, ideally
mention would be made of the fact that mixing transport markings with
end-to-end content has caused (and continues to cause) problems (e.g.
it hampers straightforward digital signing of content, it has led to
improper modification of some Originator fields (e.g. Reply-To) by some
implementations, has led to incorrect use of mailboxes in the From
field for non-delivery (esp. "vacation"-like) notifications).

Section 1.3 and subsequent sections use the term "bounce", which
implies non-delivery whereas the term is used to cover cases that
include positive delivery notifications as well as informational
notices about delayed transmission.  The latter in particular are
often misinterpreted as non-delivery notifications, in spite of the
fact that many such delay notices contain explicit text IN SCREAMING
ALL CAPS that there is no need to resend.  The architecture document
should not contribute to the confusion by conflating the three
different types of notifications as "bounces". 

Figure 2 implies that a recipient can only respond to an originator if
the message passed through a mediator.

Section 2.2.3 states "A Relay may add information to the envelope, such
as with trace information.  However it does not modify existing
envelope information or the message content semantics".  Routes in
paths (forward and reverse) generally are modified in transit. Routes
in paths are now somewhat uncommon, but are not obsolete and should not
be ignored in a description of the mail system architecture.

Section 2.3, describing ISPs, states "It is not their job to perform
email functions, but to provide an environment in which those functions
can be performed".  Reality is that many (most?) ISPs provide an
environment in which mail transport functions cannot be performed
without using ISP-supplied mail services (terms of service that prevent
users from running SMTP servers or blocking outbound port 25, etc.).

Section 4.6 refers to "relationship among two MSs".  The relationship
is between an MS and an rMUA (simply "MUA" in the draft as written).
Synchronization between "local" and "remote" MSs occurs when they are
connected to a common rMUA.

Section 5.5 should explicitly caution against mangling of Originator
fields (e.g. see draft-malamud-subject-line-04.txt).

References may be amended by errata (
http://www.rfc-editor.org/cgi-bin/errata.pl
); that certainly applies to RFC 2821 and should be mentioned
prominently (many developers are apparently unaware of RFC errata).
There are also errors in some referenced RFCs (ibid.) which aren't
corrected by errata, but that's another matter.