Reply-To is a special header that is normally not present.
It has a valid use case (what it is designed for). It's used when someone composes a message on behalf of someone else (like a secretary on behalf of the boss). It says that another person is the real author; please reply directly to that person.
When it's added by a mailing list robot, it wrecks the traditional operation of the mailing list.
For one thing, it becomes hard to reply privately. You hit "reply", and the message is composed to the mailing list.
A mailing list non-subscriber is not able to get a reply to a question posted to a mailing list. So the Reply-to trick is only compatible with subscriber-only mailing lists, which are a pain in the butt.
Reply-To is a wrongheaded solution to a mailing list problem: and that problem is people using "reply" instead of "reply all", generating private discussions that do not go to the list, but unintentionally.
Today, a feature is showing up in mail clients (at least open source ones): "reply to list". This addresses the problem in a better way. The mail client recognizes, from the headers, that the message being replied to is a mailing list item, and presents this clear way of replying. Furthermore, the mail client extracts the correct list address from the headers.
Unfortunately, "reply to list" implementations are still not kind to non-subscribers. The feature assumes the subscribe-only style of mailing list. (What is needed is a list header by which the re-mailing robot can tag the message as being from a non-subscriber, so the mail client can know to keep that person in the loop.)
Also, the direct, back-channel replies sent among participants do not carry the list headers, so "reply to list" does not work for those: it's back to "reply" or "reply all".
The basis for modern email, RFC-822, has this to say about Reply-To:
4.4.3. REPLY-TO / RESENT-REPLY-TO
This field provides a general mechanism for indicating any
mailbox(es) to which responses are to be sent. Three typical
uses for this feature can be distinguished. In the first
case, the author(s) may not have regular machine-based mail-
boxes and therefore wish(es) to indicate an alternate machine
address. In the second case, an author may wish additional
persons to be made aware of, or responsible for, replies. *A
somewhat different use may be of some help to "text message
teleconferencing" groups equipped with automatic distribution
services: include the address of that service in the "Reply-
To" field of all messages submitted to the teleconference;
then participants can "reply" to conference submissions to
guarantee the correct distribution of any submission of their
own.*
(emphasis added to the last sentence) So, Reply-To munging isn't out of the realm of possibility. Also, the BNF for Reply-To does allow multiple email addresses to be specified. RFC-2822 and RFC-5322 both say the same thing about Reply-To:
3.6.2 Originator Fields
... When the "Reply-To:" field is present, it
indicates the address(es) to which the author of the message suggests
that replies be sent.
It could be argued that Reply-To munging is not allowed by this, but I could still see munging as adding an address to a mailing list email seems a reasonable thing to me.
Also, the "Sender" header is meant for the example you gave (composing and sending an email on behalf of someone else), not Reply-To.
"'Reply-To' Munging Considered Harmful" is twelve years old, and I don't think the list of mail clients containing "reply to list" includes any of my favorites - much less making it the default, as it should be, since at least on the mailing list I manage, it's an extremely niche case to want to reply to someone privately.
And if you do so, you run the risk of the recipient not noticing the To header and thus getting confused about whether the message was private or not - especially in the many modern clients that use a linear rather than hierarchal view of threads, where you'd end up with a "conversation" randomly interspersing private and public parts. Much better to just compose a separate email.
> Unfortunately, "reply to list" implementations are still not kind to non-subscribers. The feature assumes the subscribe-only style of mailing list. (What is needed is a list header by which the re-mailing robot can tag the message as being from a non-subscriber, so the mail client can know to keep that person in the loop.)
Allowing non-subscriber threads using "reply to all" is a fundamentally limiting feature, though.
- The most important point: if you're not CCed by someone else, you have to start a new thread; if you are browsing archives, you can't just 'forge' a reply to a message you didn't receive, or at least I haven't used a client that lets you do this. And you should be browsing archives, because the alternative is asking questions without knowing if 10 people have asked the same thing recently. If you are CCed, you only get replies strictly hierarchally located under yours; you can't really join the discussion as a whole.
A better system would allow you to join a thread at any point and start to receive followups sent anywhere in that thread (but only that thread).
- In lieu of such a header currently, or in case of clients which don't support it, if someone does reply to the list, you will silently be cut out of the loop.
- There's no way to stop receiving reply-alls. Not the end of the world, since even Gmail lets you mute conversations, but it's more clunky than necessary.
In my ideal system, all mail would be forwarded through the robot so you're cut out of the loop iff you want to be.
- Not as "fundamental", but there's no guarantee the list in question even has a usable archive browsing interface. (I don't pay enough attention to which interface I'm using to name names, but there seems to be a common archiving UI which does not wrap messages - of course they should be sent wrapped, but in practice I've often seen one-line-per-paragraph messages.)
For the record, my ideal system is somewhat approximated by Discourse, which is a forum, but gives you the option to receive all messages as email and reply via email. However, there are various implementation defects which make me not really want to promote it.
Reply-To is a special header that is normally not present.
It has a valid use case (what it is designed for). It's used when someone composes a message on behalf of someone else (like a secretary on behalf of the boss). It says that another person is the real author; please reply directly to that person.
When it's added by a mailing list robot, it wrecks the traditional operation of the mailing list.
For one thing, it becomes hard to reply privately. You hit "reply", and the message is composed to the mailing list.
A mailing list non-subscriber is not able to get a reply to a question posted to a mailing list. So the Reply-to trick is only compatible with subscriber-only mailing lists, which are a pain in the butt.
Reply-To is a wrongheaded solution to a mailing list problem: and that problem is people using "reply" instead of "reply all", generating private discussions that do not go to the list, but unintentionally.
Today, a feature is showing up in mail clients (at least open source ones): "reply to list". This addresses the problem in a better way. The mail client recognizes, from the headers, that the message being replied to is a mailing list item, and presents this clear way of replying. Furthermore, the mail client extracts the correct list address from the headers.
Unfortunately, "reply to list" implementations are still not kind to non-subscribers. The feature assumes the subscribe-only style of mailing list. (What is needed is a list header by which the re-mailing robot can tag the message as being from a non-subscriber, so the mail client can know to keep that person in the loop.)
Also, the direct, back-channel replies sent among participants do not carry the list headers, so "reply to list" does not work for those: it's back to "reply" or "reply all".