If you happen to have responsibility for some software that processes mail, please take the time to check the following:
- That your software always errs on the side of preserving the Reply-To header, when passing on email. E.g. email list software in particular should not overwrite existing Reply-To headers, even if a list is configured to set a default Reply-To.
- That your software can process Reply-To headers that have multiple email addresses.
- That your software provides adequate, interactive cues to its user when they reply to an email, so as to discern what the user wants, in the context of what the sender prefers (so far as that is known).
- If your software supports various weird, non-standard headers, like Mail-Followup-To, Mail-Copies-To, Mail-Replies-To, etc. deprecate and remove this support. No amount of extra headers can obviate the need for the cues in the previous point – all they do is make the situation worse overall.
- If your software must support these headers, do not let such support cause the standard and well-supported Reply-To header to be automatically ignored.
If you’re a user of software that honours Mail-Followup-To and/or has buggy Reply-To behaviour, please file bugs and/or send them patches.
So why are Mail-Followup-To et al harmful? The answer is that they increase the number of ways that the wishes of the sender, the respondent and the state of the email may interact. What was already a tricky and murky area is made even murkier when you try add new ways to indicate the desired reply-path. E.g. witness Thunderbird’s help on MFT, or Mutt’s help on Mailing lists. I defy anyone to be able to keep all the rules of their MUA behaves in the presence of the various combinations of Reply-To, From, To, Cc, Mail-Followup-To and Mail-Reply-to in their head. For the few who can, I defy them to keep track of how their MUAs support interacts with the support in other MUAs.
Further, Mail-Followup-To has never been standardised. The header is described in DJB’s Mail-Followup-To and the dead IETF DRUMS draft. Both specs effectively say that the absence of MFT when a client does a “followup” reply should continue to go to the union of the From address (From == From or Reply-To), To and the Cc. However, these descriptions carry little authority. Unfortunately Mutt, one popular MUA, behaves differently when in list-reply mode and does not fallback to (From|Reply-To)+To+Cc in the absence of MFT – at least when I last investigated. This means Mutt basically does not inter-operate with other MUAs, when it comes to the standards-track means of indicating Reply preferences.
Before we had the problem of trying to get a few cases of bugs in broken Reply-To handling fixed (e.g. lists that blindly over-write Reply-To) + the UI design issues of figuring out where a user intends replies to go, without annoying them. Now we’ve added the problems of fractured interoperability with new same-but-different headers + the problems of bugs and deviations in the implementations of said new same-but-different headers.
Mail-Followup-To == more mess == even more brokenness.
See also: Archived DRUMS discussion on Mail-Followup-To.