The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Thursday, February 03, 2000

Reply-To Munging: Is it the Right Thing?

There's a major controversy on a mailing list I'm subscribed to. The list in question (about classic computers) had to change hosts and the software used to manage the list changed.

The upshot is that under the old software, the Reply-To: field was set to be the list itself. That meant that if you wanted to send a private reply, you had to change the address the message was being sent to. As a consequence, a few private messages were sent to the list by mistake.

The new software does not set the Reply-To: field. So to reply to the list, you have to ether change the address the message was being sent to, or do a group reply, which sends a copy to the list as well as to the original sender.

A subtle change, but one that has thrown the list in a tizzy. Some people (like me) like the old behavior. Some like the new behavior (and are telling the ones that like the old behavior to deal or upgrade—odd considering that most accessing the list are using computers deemed too old to use by the rest of society).

The new change was justified by the essay “Reply-To” Munging Considered Harmful by Chip Rosenthal (I think Chip is sore because he accidentally sent private mail to a public list by mistake). But then Simon Hill, in his Reply-To Considered Useful notes that RFC-822 allows munging of the Reply-To: field:


     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). So. There it is.

But that still hasn't settled the list. Sigh.


More than you ever wanted to know about Reply-To munging

More info on the email snafu: Rich Lafferty replied with:

Note: The “Reply-To” field is added by the originator and serves to direct replies, whereas the “Return-Path” field is used to identify a path back to the originator. [This is from section 4.3.1 of RFC-822. But see section 4.4.3 for a different interpretation. -Sean]

Although I'm starting to wonder if this isn't symptomatic of a majordomo bug, or at least a design flaw. It would make sense to me to configure Majordomo such that the Reply-To points to the list *unless* the originator added its own Reply-To, in which case it would leave that there. That way, you'd have discussion on the list except when the original poster intended otherwise, which strikes me as something that the original poster might very well want. This would satisfy the objection of lost information (which strikes me as the only thing that isn't a question of preference or user-agent configuration – when majordomo strips a reply-to, it's *gone*) and the objection of encouraging public discussion (in that unless otherwise specified by the originator, the reply is directed to the list).

Pete Turnbull replied with:

Except that mailing lists are not what RFC 822 defined “Reply-to:” for. Its primary purpose is quite different; it's to force a reply to a valid address when the sender's “From:” is not valid.

Quote: “The 'Reply-To' field is added by the originator”

The RFC 822 method would be to set the “From:” field to [mailing list address], and set the “Sender:” field to the name of the person who originated the message (which is exactly the opposite to what majordomo is doing, I notice, but that's perfectly legitimate).

So, where does this get us? Well, I send a message to a mailing list:

From: <sean@conman.org>
To: <flamefest@lists.tld>

The mailing list software gets it, and when it sends it out:

From: <flamefest@lists.tld>
Sender: <sean@conman.org>
To: <joesixpack@somesite.tld>

But, if for some reason I want replies (to me) to go elsewhere, I send:

From: <sean@conman.org>
To: <flamefest@lists.tld>
Reply-To: <sean@randomsite.tld>

And what the mailing list software sends out:

From: <flamefest@lists.tld>
Sender: <sean@conman.org>
To: <joesixpack@somesite.tld>
Reply-To: <sean@randomsite.tld>

But we'll see …

Obligatory Picture

An abstract representation of where you're coming from]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.