Tony Finch wrote:
Many lists use VERP, which modifies the return path depending
on the recipient of the message, so that the bounce handler
can reliably auto-unsubscribe broken recipients.
That sounds like a very good idea.
Errors-to is another name for return-path.
On Sympa-lists it's apparently a surrogate for "Sender:". The
"Return-Path:" is a different header reflecting the "Mail From"
as seen by the MDA. RfC 3834 chapter 4 is my "Mail From" bible
- and unlike STD 10 you cannot claim that RfC 3834 is obsolete.
The forwarder would add its FQDN to the reverse path, and it
takes the resposibility for the delivery.
You misunderstand the SMTP meaning of "responsibility". It
has nothing to do with who receives error messages
IBTD. In groups with a gateway it was very bad netiquette to
bother users (From: mailbox) with technical problems, if the
responsible party was the gateway. But we could agree that
the concept of "responsibility" in "mail-arch" is not the same
as in STD 10.
it means that the responsible host must not silently lose
the message in case of failure. See RFC 1123 section 5.3.3.
That doesn't explain 251 vs. 551. And the author of RfC 1123
probably knew that "forwarding to 3rd parties" is the recipe
for the future disaster we have today, he mentioned this in
section 5.3.6 b (redistribution):
| The return address in the envelope 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.
Unfortunately he didn't draw the line between 5.3.6 a and b,
restricting case a (alias) to "local users" would have done it.
BTW, you find what I said about gateways in 5.3.7 (E), and the
opposite in 5.3.7 (F). There are other surprising details in
RfC 1123, e.g. that we don't need source routes because we have
the %-hack, and besides "!" is allowed in the local part. And
of course we don't need source routes because we have MX. The
latter is convincing, but it does not cover the special case of
mail forwarded to the MX of a 3rd party. And it does not cover
the evil case of a forged "Mail From".
Bye, Frank