DMARC change breaks reply_goes_to_list
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GNU Mailman |
Fix Released
|
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.
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.
) or name.lower() in ('from', 'reply-to'):
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.
But the next test at line 45 is false unless the address has been DMARC-munged:
# Now see if we're munging.
if msgdata.
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
Changed in mailman: | |
status: | In Progress → Fix Released |
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 :(