(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
rules"?
Seems like a reasonable addition to me.
Folks,
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
depository."
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...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net