reply_goes_to_list problem in 2.1.29
Folks:
I just upgraded from a REALLY old version of Mailman to 2.1.29 and have noticed a serious problem with reply_goes_to_list.
I have reply_goes_to_list set to 1, so a reply-to header is added to send replies back to the list.
This worked fine in the previous version that I was using (2.1.17 maybe).
However, when I post a message to my test list, the reply-to header isn't being added.
I'm not seeing any errors in the logs.
I've also set the value to 3 and set the list address as the explicit address and the reply-to header still isn't added.
Any suggestions?
Thanks!
david
-- IBM i on Power Systems: For when you can't afford to be out of business!
I'm riding 615 miles (Yes, you read that right) in the American Diabetes Association's Tour de Cure to raise money for diabetes research, education, advocacy, and awareness. You can make a tax deductible donation to my ride by visiting https://gmane.diabetessucks.net.
You can see where my donations come from by visiting my interactive donation map ... https://gmane.diabetessucks.net/map (it's a geeky thing).
I may have diabetes, but diabetes doesn't have me!
On 10/20/18 11:17 AM, David Gibbs wrote:
I'm not seeing any errors in the logs.
Well, I did just see an error ... not specifically related to the reply-to issue ... but probably related to another issue I'm seeing related to DMARC munging.
I have dmarc_moderation_action set to "munge from", but the from address isn't getting munged for domains that have dmarc=reject (like a yahoo or sbcgobal address).
The error I'm seeing is: Unable to retrieve data from
https://publicsuffix.org/list/public_suffix_list.dat:
My Linux install is REALLY old ... so that might be related. Any suggestions on a workaround?
Thanks!
david
-- IBM i on Power Systems: For when you can't afford to be out of business!
I'm riding 615 miles (Yes, you read that right) in the American Diabetes Association's Tour de Cure to raise money for diabetes research, education, advocacy, and awareness. You can make a tax deductible donation to my ride by visiting https://gmane.diabetessucks.net.
You can see where my donations come from by visiting my interactive donation map ... https://gmane.diabetessucks.net/map (it's a geeky thing).
I may have diabetes, but diabetes doesn't have me!
On 10/20/18 9:24 AM, David Gibbs wrote:
On 10/20/18 11:17 AM, David Gibbs wrote:
I'm not seeing any errors in the logs.
Well, I did just see an error ... not specifically related to the reply-to issue ... but probably related to another issue I'm seeing related to DMARC munging.
I have dmarc_moderation_action set to "munge from", but the from address isn't getting munged for domains that have dmarc=reject (like a yahoo or sbcgobal address).
The error I'm seeing is: Unable to retrieve data from https://publicsuffix.org/list/public_suffix_list.dat:
My Linux install is REALLY old ... so that might be related. Any suggestions on a workaround?
You need to upgrade SSL on your server.
As far as the actual error is concerned, this shouldn't affect reply-to munging. Also, it should only affect organizational domain processing. What this means is, for example, for a domain like sub.yahoo.com, the organizational domain is yahoo.com. This means that if sub.yahoo.com doesn't publish a DMARC policy and mail is From: the sub.yahoo.com domain we should look at the DMARC policy of the organizational domain, yahoo.com.
The absence of the organizational domain data affects the lookup of organizational domain, but is only an issue if the organizational domain has more that two labels. I.e., this does not affect xxx.com, xxx.edu, xxx.net, etc. type domains but does affect domains like xxx.co.uk and many others.
Bottom line is I don't think this is affecting either your reply-to munging or your DMARC mitigations. Is there anything about DMARC in Mailman's vette log?
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 10/20/18 12:52 PM, Mark Sapiro wrote:
The error I'm seeing is: Unable to retrieve data from https://publicsuffix.org/list/public_suffix_list.dat:
You need to upgrade SSL on your server.
Yeah, I know ... it's on the list.
As far as the actual error is concerned, this shouldn't affect reply-to munging. Also, it should only affect organizational domain processing.
I suspect it is related, although I'm not sure how. See below.;
Bottom line is I don't think this is affecting either your reply-to munging or your DMARC mitigations. Is there anything about DMARC in Mailman's vette log?
There were log entries indicating that it had parsed the DMARC policy correctly (the address I was testing had p=quarantine).
As for the suffix file ...
I changed my mm_cfg.py file to reference a local file instead of a URL so it doesn't need SSL (I'll retrieve the file periodically) using a mechanism that works.
Once I had the file setup the reply-to munging works and so does the DMARC handling.
At least my test list is working. :)
david
-- IBM i on Power Systems: For when you can't afford to be out of business!
I'm riding 615 miles (Yes, you read that right) in the American Diabetes Association's Tour de Cure to raise money for diabetes research, education, advocacy, and awareness. You can make a tax deductible donation to my ride by visiting https://gmane.diabetessucks.net.
You can see where my donations come from by visiting my interactive donation map ... https://gmane.diabetessucks.net/map (it's a geeky thing).
I may have diabetes, but diabetes doesn't have me!
On 10/20/18 11:16 AM, David Gibbs wrote:
As for the suffix file ...
I changed my mm_cfg.py file to reference a local file instead of a URL so it doesn't need SSL (I'll retrieve the file periodically) using a mechanism that works.
Once I had the file setup the reply-to munging works and so does the DMARC handling.
I'm not sure why not being able to access the file would cause the issues you saw, but I'll do some testing.
As far as updating your local file is concerned, Mailman 2.1 only reads the file once (Mailman 3 is different and re-reads it periodically) on the first post following (re)start, so if the file actually changes, you need to restart Mailman to pick up the changes. However, changes to that list generally only affect domains that you probably don't see.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 10/20/18 2:07 PM, Mark Sapiro wrote:
As far as updating your local file is concerned, Mailman 2.1 only reads the file once (Mailman 3 is different and re-reads it periodically) on the first post following (re)start, so if the file actually changes, you need to restart Mailman to pick up the changes. However, changes to that list generally only affect domains that you probably don't see.
Good to know ... thanks for your help.
david
-- IBM i on Power Systems: For when you can't afford to be out of business!
I'm riding 615 miles (Yes, you read that right) in the American Diabetes Association's Tour de Cure to raise money for diabetes research, education, advocacy, and awareness. You can make a tax deductible donation to my ride by visiting https://gmane.diabetessucks.net.
You can see where my donations come from by visiting my interactive donation map ... https://gmane.diabetessucks.net/map (it's a geeky thing).
I may have diabetes, but diabetes doesn't have me!
On 10/20/18 12:07 PM, Mark Sapiro wrote:
On 10/20/18 11:16 AM, David Gibbs wrote:
Once I had the file setup the reply-to munging works and so does the DMARC handling.
I'm not sure why not being able to access the file would cause the issues you saw, but I'll do some testing.
OK. I've done testing and looked carefully through the code. I set
DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL = "http://msapiro.net/mailman/garbage"
in mm_cfg.py and then sent a test post From: mark_sapiro@zzz.yahoo.com and got this in the error log
Oct 20 21:04:31 2018 (19289) Unable to retrieve data from http://msapiro.net/mailman/garbage: HTTP Error 404: Not Found
and this in vette
Oct 20 21:04:31 2018 (19289) List1: DMARC lookup for mark_sapiro@zzz.yahoo.com (_dmarc.yahoo.com) found p=reject in _dmarc.yahoo.com. = v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;
and DMARC mitigations were applied. In particular, when you see a message like that in the vette log, it means that Mailman's IsDMARCProhibited() function has returned True meaning apply the DMARC mitigations.
I don't see that it is possible to see that message in the vette log without the mitigations being applied.
Further, if the From: domain itself publishes a DMARC policy, the code that reads the organizational domain data isn't even executed (that's why the domain is zzz.yahoo.com in my test).
Anyway, it's working for you now, and that's the important thing.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 10/20/18 9:17 AM, David Gibbs wrote:
I have reply_goes_to_list set to 1, so a reply-to header is added to send replies back to the list.
This worked fine in the previous version that I was using (2.1.17 maybe).
However, when I post a message to my test list, the reply-to header isn't being added.
It should be, but this may be related to the "Unable to retrieve data from https://publicsuffix.org/list/public_suffix_list.dat:" error, see next reply.
I've also set the value to 3 and set the list address as the explicit address and the reply-to header still isn't added.
The correct value for 'explicit address' is 2, not 3.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
David Gibbs -
Mark Sapiro