DMARC change breaks reply_goes_to_list

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