[ mailman-Feature Requests-923122 ] reply_goes_to_list allow poster+list option

SourceForge.net noreply at sourceforge.net
Wed Dec 15 02:11:17 CET 2004

Feature Requests item #923122, was opened at 2004-03-25 14:01
Message generated for change (Comment added) made by shub
You can respond by visiting: 

Category: None
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: karl berry (kberry)
Assigned to: Nobody/Anonymous (nobody)
Summary: reply_goes_to_list allow poster+list option

Initial Comment:
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.

karl at freefriends.org


Comment By: Brad Knowles (shub)
Date: 2004-12-15 01:11

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 at Host.Net>
|            Sender:   Jones at Host
|            Reply-To: The Committee: Jones at Host.Net,
|                                     Smith at Other.Org,
|                                     Doe at 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.


Comment By: URA Hiroshi (ura)
Date: 2004-12-14 16:28

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?


Comment By: karl berry (kberry)
Date: 2004-11-25 18:40

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.


Comment By: Brad Knowles (shub)
Date: 2004-11-25 18:32

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.


Comment By: karl berry (kberry)
Date: 2004-11-25 18:20

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.)


Comment By: Brad Knowles (shub)
Date: 2004-11-25 15:26

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.


Comment By: URA Hiroshi (ura)
Date: 2004-05-10 10:44

Logged In: YES 

I uploaded the patch by different method. see following URL:


You can respond by visiting: 

More information about the Mailman-coders mailing list