Alessandro Vesely wrote:
As I received no objections, here's my 2 cents.
Watching this list for less than four years I fear it does
not work that way, but testing it is certainly allowed. ;-)
| Because of its administrative relevance, this address MAY
| be used to devise local acceptance policies based on the
[...]
| While recognizing the existence of such policies, this
| paragraph only describes general issues intended for
| efficient and reliable transport and delivery of mail messages.
I'd remove that part, it is rather vague. Of course the
MAIL FROM like anything else in the envelope can be used
for the decision to reject or accept a mail. And as the
reverse path MUST be used to report non-delivery to the
originator it's arguably not only an option (MAY) to make
sure that it's no nonsense when accepting it.
| A server SHOULD allow to change the envelope return
| address if required by local forwarding policies.
Isn't that anyway the case for redistribution in the style
of a mailing list ? Nothing's wrong if a mailing list has
only one member.
| If the server changes the envelope return address, it
| MUST also remove the Return-Path informative header, if
| any exists.
Is that new ? So far I thought that removing erroneous
Return-Path header fields inserted before final delivery
are the job of the last hop adding the real Return-Path.
And IIRC that's unfortunately no MUST yet, the 2821-to-DS
folks are very anxious about new MUSTard. And as a third
thought, more MTAs trying to "fix" headers could mean more
potential trouble.
| Since RFC1123 [2] banned source routing in the envelope
| return path, error messages did not have to go through the
| reverse path any more.
+1, maybe s/banned/deprecated/
| 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.
Yes, something in this direction. It is also in order to take the
responsibility as *required* by 821, inadvertently removed by 1123.
| We classify such a pseudo-mailbox as an "alias and similar
| forwarding" or a "list", depending upon the expansion rules.
No "we" style in 2821 so far. I don't get this classification,
what's the idea here ? In essence you can have "redistribution"
(list), local aliases, or forwarding (non-local aliases).
The third case is generally not more desirable after RFC 1123
removed the indication of responsibility in the reverse path -
it can be still okay by mutual agreement, but that's special.
| 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.
Changing it would be odd for local aliases (your "delivered"
case). And leaving it as is without an agreement with the
admin for the "forwarded to" address is no question of local
policy, it breaks the simple and accurate RFC 821 concept of
responsibility for forwarding. That is IMO the RFC 1123 bug.
Another "+1" for the rest of your proposal.
Frank