#153 reply_goes_to_list allow poster+list option

karl berry

Right now, the reply_goes_to_list option allows (a)
poster, (b), list, and (c) explicit. How about (d)
poster AND list? That is, insert/override a reply-to:
header containing both the list name, and the original
reply-to (if present, else From: address). For extra
credit, omit the original poster if they are a list member.

This would be very useful for a number of lists I
maintain, where 90% of the traffic is among the list
members (hence having a simple reply go to the list),
yet a few messages come in from the outside world
(hence including the original poster's address).

I'm using mailman 2.1.4 on GNU/Linux.



  • Brad Knowles

    Brad Knowles - 2004-11-25

    Logged In: YES

    I don't think this is possible. "Reply-to:" goes back to one address, not
    two. The action of having multiple "Reply-to:" headers is also undefined,
    and some clients may work the way you want, while others may work in
    ways you do not.

    Pretty much everything to do with "Reply-to:" is really a client problem,
    and needs to be solved there. See <http://www.python.org/cgi-bin/
    faqw-mm.py?req=show&file=faq03.048.htp> for details.

  • karl berry

    karl berry - 2004-11-25

    Logged In: YES

    I'm trying to help my users avoid a fairly common mistake,
    not engage in arguments about standards. Fine,
    Reply-to: list, poster
    may not work for the population of some lists. So those
    lists won't enable it.

    Meanwhile, it will help some people and lists, and there's
    no other way to accomplish the behavior (that I know of).
    It's trivial to add and a tiny change in the user interface.

    I am not asking for per-user control of this, which is what
    the FAQ entry you cited mostly discusses. Obviously some
    compromise has already been made with the "reply-to
    considered harmful" stance. (For which I am very thankful,
    because it is very useful.)

  • Brad Knowles

    Brad Knowles - 2004-11-25

    Logged In: YES

    The problem is that this idea is likely to cause a number of programs to
    break, probably pretty badly.

    I think this is a very bad idea. We don't want to be doing things to
    encourage people to break the standards, especially since most people
    who would use this option would not understand the true scope of the

    Using two "Reply-to:" headers doesn't resolve this issue, either.

    If you want to munge the "Reply-to:" header to point back to the list,
    then Mailman gives you the ability to do that. It's a bad idea, for the
    reasons laid out in the FAQ, but you do have that capability.

  • karl berry

    karl berry - 2004-11-25

    Logged In: YES

    Whatever. There's obviously no point in debating it, since
    you think it is so terribly horrible and I don't see the
    problem with helping users, regardless of what "standards"
    would like to impose on us. So I'll try to mark this
    closed, and we can get on with our lives.

  • karl berry

    karl berry - 2004-11-25
    • status: open --> closed
  • URA Hiroshi

    URA Hiroshi - 2004-12-14

    Logged In: YES

    Hi shub.

    pleases read RFC2822 again. By RFC2822 3.6.2, it is defined
    as the "Relay-To:" header having one or more mail addresses.

    from RFC2822 3.4 & 3.6.2
    | address-list = (address *("," address)) / obs-addr-list
    | reply-to = "Reply-To:" address-list CRLF

    However, it cannot have multiple "Reply-To:" headers as you say.

    from RFC2822 3.5.
    | Field Min number Max number Notes
    | reply-to 0 1

    Thus, So, I believe that my patch is right.

    Am I misunderstanding?

  • Brad Knowles

    Brad Knowles - 2004-12-15

    Logged In: YES

    Actually, the problem has very little to do with the RFCs, but everything
    to do with how the RFCs are typically interpreted. I've been doing
    Internet mail for over twelve years now, and I've read RFCs 821, 822,
    1123, and various other related ones many, many times over, and quoted
    many of them from memory.

    While 2822 supercedes 822, and the BNF is algorithmically more clear in
    terms of what is allowed in the "Reply-to:" header, RFC 822 section A.2.4
    actually gives an example that is more clear to us humans:

    | A.2.4. Committee activity, with one author
    | George is a member of a committee. He wishes to have any
    | replies to his message go to all committee members.
    | From: George Jones <Jones@Host.Net>
    | Sender: Jones@Host
    | Reply-To: The Committee: Jones@Host.Net,
    | Smith@Other.Org,
    | Doe@Somewhere-Else;
    | Note that if George had not included himself in the
    | enumeration of The Committee, he would not have gotten an
    | implicit reply; the presence of the "Reply-to" field SUPER-
    | SEDES the sending of a reply to the person named in the "From"
    | field.

    Having read both of these RFCs many times over, I don't recall ever
    seeing either of these sections in particular, and I think that's the real
    problem -- client authors are likely to make similar mistakes, and
    putting multiple recipients in the "Reply-to:" header is likely to cause
    way more problems than it can possibly solve, especially with clients
    that are being LAN e-mail gateways and do not themselves natively
    understand Internet e-mail protocols.

    I still think this is a really, really bad idea. I would violently oppose the
    inclusion of this feature in future versions of Mailman.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks