ietf-smtp
[Top] [All Lists]

"addressing" comments on draft-crocker-email-arch-04.txt

2005-03-31 18:42:00

The email architecture draft uses several terms (and neglects at least
one term) in ways that may cause or perpetuate confusion and lead to
loss of interoperability.  The specific terms used are addr-spec,
address, and mailbox.  Path and angle-addr are related terms used in the
core email RFCs, but are not mentioned in the draft.  The terms are
related, mostly by a hierarchy, and have specific uses in the message
format and mail architecture.

The differences are perhaps best illustrated by concrete examples as
well as descriptions and references:

addr-spec   blilly(_at_)erols(_dot_)com

angle-addr  <@mx.mail.rcn.net:blilly(_at_)erols(_dot_)com>

mailbox     Bruce Lilly <@mx.mail.rcn.net:blilly(_at_)erols(_dot_)com>

address     Bruce Lilly: <blilly(_at_)erols(_dot_)com>, 
bruce(_dot_)lilly(_at_)gmail(_dot_)com;

An addr-spec (RFCs 822, 2822) is the basic addressing specification
consisting of a local-part and domain, delimited by the special
character '@'.  Every addr-spec is (syntactically) a mailbox and an
address.  No addr-spec is an angle-addr.  No angle-addrs are addr-specs.
Not all mailboxes are addr-specs.  Not all addresses are addr-specs.

An angle-addr (RFCs 822, 2822, called path in RFCs 821, 2821) is an
angle-bracketed construct which consists of an optional comma-separated
list of domains terminated by a colon (a route) followed by an addr-
spec.  N.B. although officially deprecated, a non-null route is still
sometimes required to work around temporary DNS problems.  An angle-addr
is used in SMTP MAIL FROM and RCPT TO commands.  During SMTP transfer
using an angle-addr with a non-null route forward path, the route may be
modified by having a host strip its domain from the front of the route.
At "final" delivery, SMTP copies the (possibly modified) path used for
delivery notifications and places the resulting angle-addr in a
Return-Path field.  All angle-addrs are (syntactically) mailboxes and
addresses.  No angle-addrs are addr-specs and vice versa.  Not all
mailboxes are angle-addrs.  Not all addresses are angle-addrs.
Angle-addrs with non-null routes are deprecated in header fields, but
parsers are required to be able to parse paths with routes.

The term "mailbox" has two uses (RFCs 822, 2822):

   o As an abstract term for an entity that receives email.

   o As a syntactic unit corresponding to that abstract term.

As a syntactic unit, a mailbox may consist of a naked addr-spec (all
addr-specs are syntactically mailboxes), or as an angle-addr with an
optional display name (all angle-addrs are syntactically mailboxes).
Mailboxes which are not also raw angle-addrs cannot be used in SMTP
commands (naked addr-specs and display names are prohibited; therefore
the valid mailbox example above, which is also a valid address, cannot
be used in SMTP command arguments).  A mailbox is a single entity; each
message author might (or might not) have a mailbox; authors' mailboxes
are specified in (comma-separated) list form in the From message header
field.  A message may have multiple authors, a sole author, or one or
more authors with no mailbox.  A message sender (the individual entity
which causes message transport to be initiated) is expected to
unconditionally have a (syntactically valid) mailbox, which is specified
in the message Sender header field.  The From field has a list of
mailboxes of any valid syntactic form.  The Sender field has only a
single mailbox, which may have any valid syntactic form.

An address is the richest form of specification.  An address may be a
mailbox (all mailboxes are addresses) or a display name followed by a
colon, a possibly empty comma-separated list of mailboxes, followed by a
semicolon (a named group).  While named groups are addresses, addresses
which are named groups are not themselves mailboxes.  Message header To,
Cc, and Reply-To fields may contain non-empty comma-separated lists of
addresses.  Message Bcc header fields may be empty or may contain
comma-separated lists of addresses.

The restrictions are important to bear in mind:

   o Message From and Sender fields cannot contain named groups
     (addresses which are not mailboxes), only mailboxes (and only a
     single mailbox in Sender).

   o SMTP command arguments cannot use named groups (addresses which are
     not mailboxes) or mailboxes with display names, or naked
     addr-specs; only angle-addrs.  The message header Return-Path field
     is derived from an SMTP command argument and is subject to the same
     restrictions.

Bandying these terms about carelessly, e.g. as if they were
interchangeable, leads to confusion.  If the restrictions are violated
as a result, loss of interoperability can occur.

Unfortunately, the draft does not maintain the distinctions between
these terms.

Specific suggestions for improvement:

Section 2.1.1: Maintain the distinction between Author and Sender.  By
   coincidence, the Sender may be an author, or by additional
   coincidence, the sole author.  In general, Author(s) and Sender are
   distinct.

Section 2.1.3: Ditto. The transport initiator (Sender) is not
   necessarily the (an) author.

Section 2.2.3, last paragraph, two places: "Bounce" (implies non-
   delivery, though delivery notifications may be positive as well as
   negative) messages are sent to a path (angle-addr), not an address.

Section 3: conflates three of the terms, and inconsistently mixes in
   angle brackets as well!  It ignores angle-addrs and the routes which
   they may contain.

Section 3.1: conflates two terms in the heading and three in the first
   paragraph after the RFC 2822 quote.  That paragraph fails to note
   that a mailbox may be an angle-addr (not even mentioned) with an
   optional display name.  It also states that the RHS (a domain) is
   equivalent to an Administrative Unit, which is incorrect (a single
   Administrative Unit might manage several domain names, or a single
   domain name might be shared among several Administrative Units).  The
   following paragraph uses "address" where "mailbox" or "addr-spec"
   would be appropriate, and mixes in angle brackets.

Section 3.1.1, second paragraph: "addresses" should be "mailboxes"

Section 3.1.2, heading and first paragraph: "address" (and addresses)
   should be "mailbox" (mailboxes)

Section 3.2: "mailbox address" should be "addr-spec or angle-addr"

Section 3.3, first sentence: "mailbox addresses" should be addr-specs
   and angle-addrs"

Section 4.2: References to From and Sender fields should refer to
   "mailboxes" and "mailbox" respectively.  The description of the
   Reply-To field is an oversimplification; as noted in RFCs 822 and
   2822, the Reply-To field has multiple uses, including specification
   of alternate mailboxes (as addresses) for the author(s), for
   delegation of responses to others, and for directing responses (e.g.)
   to a mailing list mailbox (as an address).  As noted by several
   persons in a number of messages on the ietf-822 mailing list, the
   mailbox(es) for responses are not a simple mechanical matter; they
   depend as much on the intent of the respondent as on the suggestion
   of the originator(s).  Several MUAs have separate response functions
   to direct responses to the author(s), regardless of the Reply-To
   field.  The section states that the Sender field is set by "Source"
   (as distinct? from Originator), whereas RFC 2822 section 3.6.2
   clearly states that Sender is an Originator field.  Discussion
   paragraph should replace "address" (several places) with "mailbox";
   but there are additional problems.  It claims that the "bounce"
   "address" (see above) is set by the Sender field, which is incorrect
   -- that might happen in a particular implementation, but the Sender
   mailbox and the SMTP return path (for delivery notifications) may in
   general be unrelated.

To, Cc, Bcc: use of "address" is correct!

Section 4.3: Discussion of SMTP MAIL FROM and RCPT TO (several places)
   should use "angle-addr" or "path" in lieu of "address", and the
   "mailing list address" should be "mailing list mailbox".

Section 4.4: Ditto; also note that routes in paths might be modified.

Section 4.5: first paragraph should use "mailbox" instead of "address".
   Reference to SMTP MAIL FROM and the Return-Path field should use
   "path" or "angle-addr" insted of "address".

Section 5: Same comments as 4.3/4.4; also "mailbox address" -> "path" or
   "angle-addr".

Section 5.1: references to SMTP "envelope", MAIL FROM, RCPT TO should
   use "path" or "angle-addr".  Reference to delivery (under Received)
   should use "mailbox" instead of "address".

Section 5.2: The From, Resent-From, and Resent-Sender fields contain
   mailboxes, not addresses.  Regarding the display name, it is
   structured (an RFC [2]822 phrase), not "free-form".  And as for
   modification: GACK! PTUI!  Delivery notifications are specified with
   a path (angle-addr) and are independent of the Resent-Sender mailbox.
   SMTP MAIL FROM and RCPT TO are paths (angle-addrs).

Section 5.3: Mailing lists, authors, and the sender have mailboxes, not
   addresses.  The Reply-To field (RFC 2822 section 3.6.2) is an
   Originator field, full stop.  It MUST NOT be modified by any entity.
   "Reply to author", on MUAs that have a specific function for that
   (Kmail, e.g.)  use the mailbox(es) in the From field, since that
   field holds the mailbox(es) for the author(s).  As noted above,
   Sender is an Originator field.  SMTP MAIL FROM and RCPT TO use paths
   (angle-addrs), not addresses.  List expanders SHOULD set the reverse
   path (MAIL FROM) to point to the list administrator, and SHOULD NOT
   leave MAIL FROM unaltered.

Section 5.4: Sending is based on paths (angle-addrs) in the SMTP
   envelope, not addresses.  From and Sender fields use mailboxes;
   Sender is an Originator field.  MAIL FROM path (angle-addr) might
   have to be transformed into something comparable on the "foreign"
   side of the gateway, but SHOULD NOT be changed to point to a gateway
   operator mailbox except as a last resort (otherwise delivery
   notifications will never reach the correct mailbox).

Whew. There might well be other sections that need to be edited to
maintain the distinctions.  Obviously there are many changes; I would
recommend another draft revision review here before wider IETF review.


<Prev in Thread] Current Thread [Next in Thread>