[Mailman-Developers] Re: Reverting question

Barry A. Warsaw barry@digicool.com
Tue, 14 Nov 2000 11:40:45 -0500 (EST)

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> In general I'm against coercing Reply-To. Strongly.

Me too.

    CVR> But there are times when it's the right/necessary thing to
    CVR> do, so you want that option. In general yous houldn't use it,
    CVR> but sometimes you need it. One classic case is a mailing list
    CVR> under NDA discussing a beta software release, where all
    CVR> e-mail has to be logged and evaluated, and the *wrong* thing
    CVR> to do is reply privately to a person, because the beta team
    CVR> needs a copy. In that case, reply-to gets coerced to the
    CVR> list, and that reply-to needs to be dominant (i.e., an
    CVR> existing reply-to from a user *can't* take precedent).

That's the key thing that I don't like about Reply-To munging: it
makes it much more difficult to do private replies.  Maybe it's just
the lists I manage, but my users are just as heated about /not/ doing
reply-to munging as apparently other users on other lists are about
doing it.

The primary complaint is that people accidently send private responses
to the whole list.  This happens because they've trained themselves to
know the difference between replies and followups, and have MUAs that
separate those functions.  The only grumblings occur when people don't
trim their CC headers (like I've done here) and folks start getting
duplicates.  That can be handled in other ways (e.g. the list /could/
suppress deliveries to list members that it sees explicitly in the
recipients list, although as we've discussed before, that has some
potential for abuse).

I've slept on this one and I'm prepared to change things for 2.0 final
so that if Reply-To munging is turned on, it'll override any existing
Reply-To field in the original message.  The deciding factor for me
was realizing how difficult it was to send private replies with
munging turned on, so it might as well be equally difficult for every

I'm concerned about making this change so late in the game, but I'm
willing to do it, /if/ I get enough positive feedback asap.  I'm
attaching a diff against the current CVS tree.  Please try it and let
me know.  If I get enough positive responses with few or no negative
responses, I'll add this ("enough" being defined completely
subjectively :).


-------------------- snip snip --------------------
Index: Mailman/Defaults.py.in
RCS file: /cvsroot/mailman/mailman/Mailman/Defaults.py.in,v
retrieving revision 1.124
diff -u -r1.124 Defaults.py.in
--- Mailman/Defaults.py.in	2000/11/09 02:00:30	1.124
+++ Mailman/Defaults.py.in	2000/11/14 16:38:16
@@ -310,7 +310,15 @@
 from: list@listme.com
 from: .*@uplinkpro.com
-# Replies to posts inherently directed to list or original sender?
+# Mailman can be configured to "munge" Reply-To: headers for any passing
+# messages.  One the one hand, there are a lot of good reasons not to munge
+# Reply-To: but on the other, people really seem to want this feature.  See
+# the help for reply_goes_to_list in the web UI for links discussing the
+# issue.
+# 0 - Reply-To: not munged
+# 1 - Reply-To: set back to the list
+# 2 - Reply-To: set to an explicit value (reply_to_address)
Index: Mailman/MailList.py
RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v
retrieving revision 1.188
diff -u -r1.188 MailList.py
--- Mailman/MailList.py	2000/11/14 04:44:01	1.188
+++ Mailman/MailList.py	2000/11/14 16:38:18
@@ -424,13 +424,21 @@
 is <em>strongly</em> recommended for most mailing lists.''',
              # Details for reply_goes_to_list
-             """There are many reasons not to introduce headers like
-<tt>Reply-To:</tt> into other people's messages.  One is that some posters
-depend on their own <tt>Reply-To:</tt> settings to convey their valid return
-address.  See 
+             """This option controls what Mailman does to the
+<tt>Reply-To:</tt> header in messages flowing through this mailing list.  When
+set to <em>Poster</em>, no <tt>Reply-To:</tt> header is added by Mailman,
+although if one is present in the original message, it is not stripped.
+Setting this value to either <em>This list</em> or <em>Explicit address</em>
+causes Mailman to insert a specific <tt>Reply-To:</tt> header in all messages,
+overriding in the original message if necessary.
+<p>There are many reasons not to introduce or override the <tt>Reply-To:</tt>
+header.  One is that some posters depend on their own <tt>Reply-To:</tt>
+settings to convey their valid return address.  Another is that modifying
+<tt>Reply-To:</tt> makes it much more difficult to send private replies.  See
 <a href="http://www.unicom.com/pw/reply-to-harmful.html">`Reply-To' Munging
-Considered Harmful</a> for a general discussion of this issue.  See
-<a href="http://www.metasystema.org/essays/reply-to-useful.mhtml">Reply-To
+Considered Harmful</a> for a general discussion of this issue.  See <a
 Munging Considered Useful</a> for a dissenting opinion.
 <p>Some mailing lists have restricted posting privileges, with a parallel list
Index: Mailman/Handlers/CookHeaders.py
RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/CookHeaders.py,v
retrieving revision 1.17
diff -u -r1.17 CookHeaders.py
--- Mailman/Handlers/CookHeaders.py	2000/10/27 18:55:21	1.17
+++ Mailman/Handlers/CookHeaders.py	2000/11/14 16:38:19
@@ -76,11 +76,8 @@
         msg['Precedence'] = 'bulk'
     # Reply-To: munging.  Do not do this if the message is "fast tracked",
-    # meaning it is internally crafted and delivered to a specific user,
-    # or if there is already a reply-to set.  If the user has set
-    # one we assume they have a good reason for it, and we don't
-    # second guess them.
-    if not fasttrack and not msg.get('reply-to'):
+    # meaning it is internally crafted and delivered to a specific user.
+    if not fasttrack:
         # Set Reply-To: header to point back to this list
         if mlist.reply_goes_to_list == 1:
             msg['Reply-To'] = mlist.GetListEmail()