DMARC message wrapping not working
I've got a mailman 2.1.26 install I've taken over. I've attempted to turn on DMARC message wrapping by setting DEFAULT_DMARC_MODERATION_ACTION in my mm_cfg.py file, but it doesn't seem to have had the desired effect. I'm still seeing messages from p=reject domains going out with their original headers, and subscribers being blocked as a result of the bounces.
These are the (non-comment) contents of my mm_cfg.py, with the mail domain anonymized:
from Defaults import * DEFAULT_URL_HOST = 'lists.example.com' VIRTUAL_HOSTS.clear() add_virtualhost('lists.example.com', 'lists.example.com') DEFAULT_URL_PATTERN = 'https://%s/mailman/' DEFAULT_DMARC_MODERATION_ACTION = 2
The docs say this sets a minimum bar for the per-list configurations, but when I go to look at those they're all still set to 0/Accept, and in the web UI the full range of options is still available.
There is a distinct possibility I've got my hands on the wrong config file. This install isn't using the version from the system package manager.. it's a manually compiled install that looks like it has an install prefix of /usr/local/mailman. This file is /usr/local/mailman/Mailman/mm_cfg.py. I don't see an obvious way to get mailman to spit out the full path it's actually checking for the file, but the output of mailman-config suggests it's probably looking in the right place.
% ./mailman-config -h Configuration and build information for Mailman Mailman version: 2.1.26 Build Date: Wed May 2 13:10:19 UTC 2018 prefix: /usr/local/mailman var_prefix: /usr/local/mailman mailman_user: mailman mailman_group: mailman mail_group: mail cgi_group: www-data configure_opts: "--with-mail-gid=mail --with-cgi-gid=www-data"
I see no mention of mm_cfg.py in the mailman logs.. so nothing clearly indicating it's failing to find the file (nor positive feedback that it has found the file).
But I'm not convinced that's the problem anyway, since mailman clearly is picking up the virtual host and list URL settings. Any suggestions for what else I should be looking at to get Mailman to pick up this config change?
Thanks!
On 5/19/19 1:13 PM, Matthew Pounsett wrote:
I've got a mailman 2.1.26 install I've taken over. I've attempted to turn on DMARC message wrapping by setting DEFAULT_DMARC_MODERATION_ACTION in my mm_cfg.py file, but it doesn't seem to have had the desired effect. I'm still seeing messages from p=reject domains going out with their original headers, and subscribers being blocked as a result of the bounces.
Setting that in mm_cfg.py only affects lists created after you make the change. For existing lists, you have to change the list's configuration.
The docs say this sets a minimum bar for the per-list configurations, but when I go to look at those they're all still set to 0/Accept, and in the web UI the full range of options is still available.
The doc says "Whatever is set as the default here precludes the list owner from setting a lower value." It doesn't say that if you set a value here, existing list settings will be increased automatically.
If you go to the web UI for a list and just click Submit Your Changes, you will get "Error: dmarc_moderation_action must be >= the configured default value." at the top of the page and the setting will be changed.
Or, I just created https://www.msapiro.net/scripts/set_dmarc.py (mirrored at https://fog.ccsf.edu/~msapiro/scripts/set_dmarc.py) which you can copy to Mailman's bin/ directory and run via Mialman's
bin/withlist -r set_dmarc -a
and it will increase dmarc_moderation_action to DEFAULT_DMARC_MODERATION_ACTION if necessary for all lists.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, 20 May 2019 at 11:35, Mark Sapiro mark@msapiro.net wrote:
On 5/19/19 1:13 PM, Matthew Pounsett wrote:
I've got a mailman 2.1.26 install I've taken over. I've attempted to turn on DMARC message wrapping by setting DEFAULT_DMARC_MODERATION_ACTION in my mm_cfg.py file, but it doesn't seem to have had the desired effect. I'm still seeing messages from p=reject domains going out with their original headers, and subscribers being blocked as a result of the bounces.
Setting that in mm_cfg.py only affects lists created after you make the change. For existing lists, you have to change the list's configuration.
Ah, I see. I think that would be worth calling out in the documentation. I think the way it's currently written strongly implies that it will bring all lists up to a minimum behaviour.
Or, I just created https://www.msapiro.net/scripts/set_dmarc.py (mirrored at https://fog.ccsf.edu/~msapiro/scripts/set_dmarc.py) which you can copy to Mailman's bin/ directory and run via Mialman's
Thanks. Knowing what the issue is, I can whip up something like that in a few minutes.
Thanks for the clue! Matt
On 5/21/19 6:41 AM, Matthew Pounsett wrote:
Ah, I see. I think that would be worth calling out in the documentation. I think the way it's currently written strongly implies that it will bring all lists up to a minimum behaviour.
I have updated that text. It now says:
# Default action for posts whose From: address domain has a DMARC policy of # reject or quarantine. See DEFAULT_FROM_IS_LIST below. Whatever is set as # the default here precludes the list owner from setting a lower value, however # an existing list won't be changed until the first time "Submit Your Changes" # is pressed on the list's Privacy options... -> Sender filters page.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, 21 May 2019 at 20:21, Mark Sapiro mark@msapiro.net wrote:
On 5/21/19 6:41 AM, Matthew Pounsett wrote:
Ah, I see. I think that would be worth calling out in the documentation. I think the way it's currently written strongly implies that it will
bring
all lists up to a minimum behaviour.
I have updated that text. It now says:
# Default action for posts whose From: address domain has a DMARC policy of # reject or quarantine. See DEFAULT_FROM_IS_LIST below. Whatever is set as # the default here precludes the list owner from setting a lower value, however # an existing list won't be changed until the first time "Submit Your Changes" # is pressed on the list's Privacy options... -> Sender filters page.
Thanks! I think that will make it perfectly clear.
participants (2)
-
Mark Sapiro
-
Matthew Pounsett