An Earnest Plea to People Still Having This Debate
A long time ago, Chip Rosenthal wrote a fine document entitled
‘Reply-To’ Munging Considered
Harmful. It details the
problems caused by
Reply-To munging. Chip’s essay basically points
- Munging only helps people with broken mail clients.
- Munging can catch people by surprise, since in every other email they’ve gotten with multiple recipients, when they hit “reply” it goes only to the sender.
- Munging totally breaks things for people who want replies to go to a different address than the one they sent the mail from.
In 2000 (or maybe earlier), Simon Hill wrote a response called Reply-To Munging Considered Useful, which is frequently offered as a rebuttal to Chip’s document in online debates. Simon’s response boils down to the following:
- Munging encourages list discussion.
- RFC 822 seems to indicate it’s okay.
- Munging makes things easier on broken mail clients.
People still using these two documents to debate the issue are wasting everybody’s time. The issue was definitively settled in 2001, and Chip won.
The IETF settles things
The IETF (Internet Engineering Task Force) writes the standards documents for the Internet. Such a document, called an RFC (Request For Comments), attempts to unambiguously lay out in English the way things are supposed to take place. They are deliberated intensely, sometimes for years, and every paragraph is scrutinized by scores of experts. Still, problems do crop up with RFCs over time, be they from ambiguities, new technologies, or flat out mistakes. If problems are big enough or numerous enough, the IETF will issue a new RFC to correct the deficiencies of an older one. This new document is said to obsolete the old one.
Both Chip’s and Simon’s documents refer to RFC 822, “Standard For The
Format Of ARPA Internet Text Messages”, issued way back in 1982, before
most of us even knew what a computer network was. Indeed, RFC 822
doesn’t say anything about whether or not mailing lists can or should
Reply-To header field. Chip interpreted it one way, and Simon
In April of 2001, the IETF issued af new document, RFC
2822, which obsoletes RFC 822. In
this new RFC, the author addresses the
Reply-To header field in a few
places, but the most relevant to this discussion is the following in
section 3.6.2 “Originator fields”:
When the “Reply-To:” field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent.
Your list software is not “the author of the message”, so it must not
set or in any way meddle with the
Reply-To header field. That field
exists for the author and the author alone. If your list munges it, you
are violating the standard.
These standards are not written flippantly, they are carefully crafted
in such a way as to ensure everything on the Internet works as smoothly
as possible. Do the Internet a service and leave
How to specify where to post list messages
RFC 2369 specifies, in section
List-Post header field:
The List-Post field describes the method for posting to the list. This is typically the address of the list, but MAY be a moderator, or potentially some other form of submission. For the special case of a list that does not allow posting (e.g., an announcements list), the List-Post field may contain the special value “NO”.
Modern mail list software sets this header field, or provides some mechanism for the administrator to set it.
Mail clients are beginning to act on it too. The KMail program Simon
references uses the presence of this header field to make the “reply”
action send to the list and the list only, and provides a “reply to
author” action that will always send to the message’s author whether
it’s a list or not. “Reply to author” honors the
This is exactly the convenient behavior Simon claims to want in his
“considered useful” essay, and it can all be done using standard behavior.
Getting two copies of the same email
Some people complain that they’ll get two copies of the same email. Since they’re on the list, their first copy is the one sent to them by the list. When the responder hit “reply all”, it also put their email address in the recipient list, so they get a second copy directly.
Fortunately, there’s already a technical solution to this. Since all
mail clients put a unique
Message-ID header field on their email, a
mail reader has only to compare the
Message-ID of a message to
previously-recieved messages. If it’s the same, then the second message
is a duplicate and can be safely ignored.
If your mail reader doesn’t do this, that’s too bad, but it’s not an excuse to violate Internet standards and surprise people with inconsistent behavior, just to prevent you from having to delete a few emails. Anyone who gets any spam at all knows how to delete email.
It’s What People Want
I can’t tell you how many
Reply-To munging lists I’ve been on where
someone (or multiple people) send private messages to the list by
accident. “But I hit reply, not reply to all!” I’ve even been bitten
by this, right after a message to the list chiding people for sending
private messages to the list!
People want their mail client to be consistent. When they hit “reply” they want it to go to the person who wrote the message. When they hit “reply to all”, they want it to also go to everyone who received it. Most people understand this by now, since it’s how their mail reader has worked for every email they’ve ever gotten. Your list shouldn’t be any different.
Sure, mistakes are going to happen, maybe on your list, maybe with an email with multiple recipients. It’s not your job as a list owner to make sure people can’t make mistakes with their software. If the job belongs to anybody other the user, it’d be the author of the mail client. Your job is to make sure your mail list follows Internet standards, and as a result works consistently for the user.
Some people want to munge
Reply-To header fields. They believe it
makes reply-to-list easier, and it encourages more list traffic. It
really does neither, and not only is it a poor idea but it’s forbidden
by Internet standards.
The IETF has spoken, and if you violate their standard and munge your
Reply-To header fields you’re just creating problems for everybody.