On Tue, 14 Jun 2022, Mark Sapiro wrote:
On 6/14/22 15:07, Mark Hills wrote:
In diagnosing a DMARC "FAIL" reported in Gmail I notice that some settings are having absolutely no effect:
from_is_list dmarc_moderation_action dmarc_quarantine_moderation_action dmarc_none_moderation_action
So in my testing today, at no point have I been able to get Mailman to "Munge From" or "Wrap Message" in any way.
Do you have a definition of
GLOBAL_PIPELINEin mm_cfg.py or a setting forpipelinein the list's config.pck.If so, do these include the
WrapMessagehandler?
Not the exact problem, but thanks for setting me on the right path.
There _was_ the following in mm_cfg.py for some time:
GLOBAL_PIPELINE.insert(GLOBAL_PIPELINE.index('Approve'), 'SizeLimit')
I removed this completely and repeated the test; no change.
It took me a while but I eventually worked out I needed to refresh the pipeline of the individual lists, with something like:
echo "del mlist.pipeline" | config_list -i /dev/stdin mylist
This command succeeded the first time; successive attempts failed with:
AttributeError: MailList instance has no attribute 'pipeline'
which seems to suggest where was a list-specific pipeline, but no more.
So I think what's happened here is our lists ended up with a pipeline definition fixed into each list. It's possibly someting from a series of upgrades; there's never been a reason to want to maintain a separate pipeline for each list (only to ensure the "SizeLimit" above applied to all lists on the system.)
We have a script periodically using config_list to set "known good" values on every list. To prevent the problem above happening again, I've added the following:
if hasattr(mlist, 'pipeline'): del mlist.pipeline
Other nearby settings work, so I am able to change the config; it's the correct list etc. I've also tried re-starting. Logs in /usr/local/mailman/log aren't showing any errors or hints.
As some feedback, an FAQ [*] mentions ALLOW_FROM_IS_LIST; setting this has no impact, not suprising as the source code doesn't seem to mention this string anyway. Reading more carefully, I can see this doesn't apply to the current version; perhaps someone with Wiki access might consider the manner it's written, whilst technically correct, is a little backward/confusing, or removing old information.
I changed the line
1) If you have Mailman 2.1.16 or later, setto
1) If you have Mailman 2.1.16 or 2.1.17, setDoes that help?
I think that's a good change that will save time/confusion for others. Thanks.
-- Mark