I wrote:
IMHO, a consistent change should affect all of section 3.9
(Mailing Lists and Aliases), beginning with its title, and
previous sections on relaying (3.4 and 3.6) would implicitly
or explicitly refer to this one. Should I post a tentative
text?
As I received no objections, here's my 2 cents.
3.9. Replacing the Envelope Return Address on Forwarding
An SMTP-capable host SHOULD support both the alias and the list
models of address expansion for single or multiple deliveries. When
a message is delivered or forwarded to each expanded address, the
return address in the envelope ("MAIL FROM:") is particularly
important for administrative purposes, as it is the destination of
any error messages. Because of its administrative relevance, this
address MAY be used to devise local acceptance policies based on the
entity exerting administrative control on the message
transportation, e.g. the domain part of the envelope address in
SPF. While recognizing the existence of such policies, this
paragraph only describes general issues intended for efficient and
reliable transport and delivery of mail messages.
A server SHOULD allow to change the envelope return address if
required by local forwarding policies. If the server changes the
envelope return address, it MUST also remove the Return-Path
informative header, if any exists. However, the message header
section (RFC2822 [9]) MUST be left unchanged; in particular, the
"From" field of the header section is unaffected.
Note: Since RFC1123 [2] banned source routing in the envelope
return path, error messages did not have to go through the
reverse path any more. Therefore, in order to exert any
administrative control on failed deliveries, it is necessary that
each forwarding server accurately plans how to change the
envelope return address.
An important mail facility is a mechanism for multi-destination
delivery of a single message, by transforming (or "expanding" or
"exploding") a pseudo-mailbox address into a list of destination
mailbox addresses. When a message is sent to such a pseudo-mailbox
(sometimes called an "exploder"), copies are forwarded or
redistributed to each mailbox in the expanded list. Servers SHOULD
simply utilize the addresses on the list; application of heuristics
or other matching rules to eliminate some addresses, such as that of
the originator, is strongly discouraged. We classify such a pseudo-
mailbox as an "alias and similar forwarding" or a "list", depending
upon the expansion rules.
3.9.1. Alias and similar forwarding
To expand an alias, the recipient mailer replaces the pseudo-mailbox
address in the envelope with each of the expanded addresses in
turn. The envelope return address SHOULD be changed according to
local forwarding policies, or left intact in case of lack thereof.
The message is then delivered or forwarded to each expanded address.
The server administrator should specify a privacy policy and
carefully determine the kind of forwarding that each alias expansion
implies, in order to configure the mailer accordingly. If an alias
is meant to conceal its expanded address(es), the envelope return
address has to be changed so that any error message will not reveal
the final mailbox name to the message originator. When forwarding
for address correction or updating (see section 3.4) a delivery
failure due to the fact that the updated address has been deleted in
turn should also reach a person or other entity who is in control of
removing the relevant alias configuration directive, besides the
current message originator who, by that time, might have already
received a 251 response (but see also section 7.7).
3.9.2. List
The envelope return address MUST be changed to be the address of a
person or other entity who administers the list.
A mailing list may be said to operate by "redistribution" rather
than by "forwarding". To expand a list, the recipient mailer
replaces the pseudo-mailbox address in the envelope with each of the
expanded addresses in turn. The envelope return address is changed
so that all error messages generated by the final deliveries will be
returned to a list administrator, not to the message originator, who
generally has no control over the contents of the list and will
typically find error messages annoying.