D. J. Bernstein wrote:
Bruce Lilly writes:
Something like MFT, for instance, requires changes to senders' and
recipients' UAs
One of the basic goals here is for followups to exclude the sender's
address upon request from the sender.
Then the non-standard Mail-Followup-To field fails to meet that goal,
since it doesn't specify a list of addresses (or a single address)
to exclude from anything.
Now you might have said that a goal is for the original message
author to be able to indicate a preference for where responses
*should* go.
The sender wants his MUA to make this request _automatically_ for any
message that he sends to various mailing lists. Old message injectors
don't have this feature, so they have to be changed.
Existing UAs do have this feature. It's called setting the content
of the standard Reply-To field, which has precisely the desired
semantics as specified in RFC 2822:
When the "Reply-To:" field is present, it
indicates the mailbox(es) to which the author of the message suggests
that replies be sent.
This has nothing to do with the choice of protocol. Every protocol needs
this MUA support. Criticizing Mail-Followup-To on this basis is silly.
The difference is that Reply-To has long been defined with the
desired semantics, and is already supported by UAs. Mail-Followup-To
isn't even defined properly.
As for the recipient's MUA: Yes, Mail-Followup-To needs some changes,
but every one of your proposals requires vastly more changes. Again,
criticizing Mail-Followup-To on this basis is silly.
You are wrong. Because Reply-To is and has long been a standard
field, nothing needs to change in UAs. Or MTAs or MSAa.
and to any MSAs and MTAs that rewrite address fields.
At this point you're inventing problems that don't exist. The software
that creates Mail-Followup-To is responsible for using fully-qualified
domain names.
It is often the case that transport modifies domain names in addresses
for various reasons -- to hide internal host names, to accommodate
domain name changes when a company or organization is acquired by
or merges with another organization or company, etc.
Subsequent transports aren't expected to, and shouldn't,
rewrite Mail-Followup-To.
The ostrich approach is rarely successful (even for ostriches).