Dave Crocker wrote:
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
The RFC 2822 definition is a verbatim copy from RFC 822 6.2,
<http://tools.ietf.org/html/rfc822#section-6.2>
For RFC 821 a mailbox is a "character string (address) which identifies
a user to whom mail is to be sent", and *additionally* "the 'container'
in which mail is stored" (RFC 821 glossary). For RFC 821 it was still
important to distinguish "mailing" and "sending" (= instant messaging).
2821bis replaces 'container' by 'location', and says 'user or location'
instead of 'user and location', because that's it what it needs for its
purposes.
and, therefore, also believe that 2821bis' use of the term "pseudo-
mailbox" needs to be removed.
Maybe the [2]822[upd] mailbox would avoid the introduction of pseudo-
mailbox. For the [2]821[bis] definition a list or alias (or program
etc.) is no 'user or location'. For the purposes of 2821bis a mail
to a list or alias is still "in transit", not a final delivery to a
receiver.
[simple 2821bis lists vs. "complex" lists]
In particular, both have a delivery of the original message and a
posting of a new one.
New messages after delivery are not the business of [2]821[bis].
| A mailing list can perform a very wide range of modifications to
| a message and its envelope.
That's no proper mailing list. A mailing list redistributes the
mail AS IS (signatures still working etc.) from its own address
to the list members, adding useful List-* header fields. Likewise
an alias forwards the mail AS IS to one or more addresses updating
only the reverse path like all other relays.
Updating the reverse path is not more possible (or rather it's
pointless), therefore alias forwarding to third parties is not
more allowed, it would eliminate the responsibility for delivery
or error reports at the forwarder. RFC 821 explains very clearly
what this responsibility actually means and offers 551 for admins
not willing to take it. IMO 2821bis should finally admit this
RFC 1123 5.3.6() design flaw, documenting bugs is a good thing.
Things mailing lists MUST NOT do: Modify the body, add or replace
Reply-To, replace Sender. The 2821bis 3.9 MUST is in essence fine,
it only goes to far wrt List-* header fields.
Folks need to know that most entities claiming to be mailing lists
are not proper mailing lists. They are some kind of "mediator",
where good, bad, or ugly are not yet specified in an RFC.
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.
That's the idea, and it's no "emulation", it's the real thing.
As "email transit" is the topic of [2]821[bis] it also fits.
More elaborate lists need to be viewed as full MUAs, which accept
a delivery and post a new message.
That's off topic for [2]821[bis], it's discussed in email-arch.
Frank