Don't munge reply-to if one already exists -- feature reques

Bug #266858 reported by Auvor
2
Affects Status Importance Assigned to Milestone
GNU Mailman
New
Medium
Unassigned

Bug Description

As you all know, a few (loud) users still seem to think reply-to header
munging is a good idea, and thus I and many others feel forced to enable it
on certain lists. This causes problems every time people would like a reply
off-list, since people tend to reply to the list by mistake, obeying the
munged reply-to.

Turning off first_strip_reply_to looks like it would help at first glance,
but it still requires users to edit the headers manually to remove the
added list address, and many forget this.

A simple solution would be to simply allow leaving any existing
reply-to-headers alone, and only add one if none are already defined. This
way, the munging will act as a default, allowing the sender to override it
by adding an explicit one.

The change should be fairly simple, and something similar to the attached
diff should suffice. Naturally, the setting "leave_existing_reply_to_alone"
would also have to be added and documented. The diff is just to illustrate
the idea (although I can create a complete diff if you wish).

[http://sourceforge.net/tracker/index.php?func=detail&aid=1707731&group_id=103&atid=350103]

Revision history for this message
Auvor (auvor) wrote :
Revision history for this message
Auvor (auvor) wrote :

Originator: YES

Ooops. I didn't realize that the "Submit new" menu choice acted
differently based on where one was in the tracker when clicking it, and
expected to be able to mark the request as a feature request on the next
page or something. I'm very sorry about that. I'd normally try to clean up
after myself, but this time I expect I'd just worsen the mess :-|

As you've probably guessed, I've never used the SourceForge bugtracker
before ;-)

Revision history for this message
Mark Sapiro (msapiro) wrote :

Originator: NO

Per your comment I am moving this to Feature Requests. I'm sorry for the
confusion, but it's not my tracker either :-)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.