[Top] [All Lists]

Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))

2007-12-13 20:06:47

(Please note that I'm directing this to the ietf-smtp list, in order to target
folks who have more history on the topic. /d)

Ned Freed wrote:

--On 10. desember 2007 15:22 -0800 Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:

2. The mailing lists described in 2821 are very simple redistribution
lists, as opposed to the "fairly sophisticated forums for group communication" [2919] described in these documents. For simple aliasing and redistribution lists, I think the "MUST be left unchanged" is appropriate.

The key point is that this is redistribution prior to final delivery. Sophisticated list processors in effect submit a new message to the transport infrastructure and do not fall under this prohibition.

Would it be a reasonable thing to add a note saying that "there exist things that call themselves lists but are doing processing other than what is described here; such lists should be described as delivery
followed by a submission, and alterations are therefore outside the

Seems like a reasonable addition to me.


Oh boy.  When I started to write this note, it had a very focused intent.  As
I started writing it, I uncovered some issues I think too serious to ignore:

1.  RFC2821bis needs a glossary.  At the least, I do not see a definition of
'mailing list' or 'alias' in 2821bis, nor 'redistribution' or 'forward'. So
2821bis uses essential terms without defining them.

2.  RFC2821bis has a different, and I believe significantly incompatible,
definition of mailbox from that in rfc2822:

    RFC2821bis:  "As used in this specification, an "address" is a character
    string that identifies a user to whom mail will be sent or a location into
    which mail will be deposited.  The term "mailbox" refers to that

    RFC2822:  "A mailbox receives mail.  It is a conceptual entity which does
    not necessarily pertain to file storage.

I am sure it will entirely shock folks to hear that I strongly prefer the 2822
definition and, therefore, also believe that 2821bis' use of the term
"pseudo-mailbox" needs to be removed.

I do not believe that resolving these issues alters 2821 as a protocol, so
there will be no need to worry about recycling at Proposed. But these changes would greatly increase the document's clarity (or at least precision) and compatibility between 2821 and 2822.

I'll wait to see how folks react to the above (on this ietf-smtp list, please)

As for the more narrow topic at hand:

While I think the proposed text gets across the distinction folks are seeking,
I'm concerned that it leads to a belief that one or the other type of activity
is not a list.  My own view is that they are both lists, but the former is a
list that restricts itself sufficiently to qualify as emulating an MTA.  In
particular, both have a delivery of the original message and a posting of a
new one.

For the particular wording changed being discussed here -- I lost track;
section 3.9.2, right? -- I'm inclined to something along the lines of:

A mailing list can perform a very wide range of modifications to a message and its envelope. When a list constrains its processing to the very limited set of modifications and actions described here, it is attempting to emulate an MTA. Such lists can be treated as a continuation in email transit. More elaborate lists need to be viewed as full MUAs, which accept a delivery and post a new message.

ok.  start shooting...


  Dave Crocker
  Brandenburg InternetWorking