DMARC change breaks reply_goes_to_list

Bug #1313010 reported by Robert Mathews on 2014-04-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Medium
Mark Sapiro

Bug Description

(Using 2.1.18rc2 plus revision 1466 patch.)

Setting reply_goes_to_list to either "This list" or "Explicit address" no longer adds the correct Reply-To header *unless* the from/reply-to were munged for DMARC reasons. The expected Reply-To header is missing completely.

I may be wrong about why, but it seems that:

Line 190 of CookHeaders.py calls change_header() to add the desired Reply-To header. In previous versions, change_header() would unconditionally just set the header directly unless "mlist.from_is_list == 2". Here's the 2.1.17 code; you can see that it would have just run "msg[name] = value" in most cases:

def change_header(name, value, mlist, msg, msgdata, delete=True, repl=True):
    if mm_cfg.ALLOW_FROM_IS_LIST and mlist.from_is_list == 2:
        msgdata.setdefault('add_header', {})[name] = value
    elif repl or not msg.has_key(name):
        if delete:
            del msg[name]
        msg[name] = value

Now, though, changeheader() is more complicated and ends up using "msgdata.setdefault('add_header'..." instead, because of this:

       ) or name.lower() in ('from', 'reply-to'):
        msgdata.setdefault('add_header', {})[name] = value

The add_header data later gets examined in WrapMessage.py's "process()". The first test at line 43 of WrapMessage.py is true:

    if not (msgdata.get('from_is_list') == 2 or
            (mlist.from_is_list == 2 and msgdata.get('from_is_list') == 0)):

But the next test at line 45 is false unless the address has been DMARC-munged:

        # Now see if we're munging.
        if msgdata.get('from_is_list') == 1 or (mlist.from_is_list == 1 and
                msgdata.get('from_is_list') == 0):

So we hit the "return" at line 57 and fail to add the header... unless DMARC munging has taken place, in which case the test at line 45 is true and the header gets added.

Related branches

Mark Sapiro (msapiro) wrote :

Thanks for your report and detailed analysis. I don't know how I missed it, but you are right. The test at line 45 shouldn't be there. We should just test for the headers in add_header and use them unconditionally.

Now to 'unrelease' 2.1.18rc3 for the second time. Are you going to find any more while I'm uploading the next tarball :(

Changed in mailman:
assignee: nobody → Mark Sapiro (msapiro)
importance: Undecided → Medium
milestone: none → 2.1.18rc3
status: New → In Progress
Mark Sapiro (msapiro) on 2014-04-26
Changed in mailman:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers