Quoting Steve Litt (sl...@troubleshooters.com): > In my wildest imagination, I never dreamed that Mailman wouldn't give > the admin control over the text assembly of the munged from.
Then, possibly you can suggest how. Why don't you test your solution on a test GNU Mailman installation, and advise Dyne.org's administrators about specifics you have in mind? Also, it would be a good idea for you to skim details of GNU Mailman's relevant documentation. To help you in that, here is the advice that I give on the subject to Mailman listadmins, identifying a specific admin WebUI configuration I recommend. In this case, it's my recommendation to _OSI's_ listadmins (which FWIW they implemented), because that was the easiest copy for me to find, but I gave near-identical advice to Devuan Project: Date: Sat, 1 Dec 2018 18:47:16 -0800 From: Rick Moen <r...@linuxmafia.com> To: license-review-ow...@lists.opensource.org Subject: (forw) Re: [License-review] Approval: Server Side Public License, Version 2 (SSPL v2) I wish to strongly recommend, based on my own listadmin experience, the best available DMARC mitigation. DMARC is proving to be an utter nightmare for mailing lists, in as much as they are mail forwarders, and DMARC was IMO botched in its ability to accomodate the way they work. From memory, and so I'm probably dropping a bunch of detail: Because MLMs such as Mailman (appropriately) change the internal SMTP headers upon retransmitting the poster's mail to subscribers (notably the To: header), it no longer validates against the sender's domain if it is a DMARC-using one with a strict policy. Yahoo and Gmail are examples of sending domains with strict DMARC policies. There is an (IMO unhappy but least-bad-available) kludge setting in Mailman's admin WebUI to make the MLM compensate for DMARC brain-damage: You go to Privacy Options, Sender Filters, item 'Action to take when anyone posts to the list from a domain with a DMARC Reject/Quarantine Policy' aka dmarc_moderation_action. Change the radio button from Accept (default) to Munge from. To quote the help text: from_is_list (general): Replace the From: header address with the list's posting address to mitigate issues stemming from the original From: domain's DMARC or similar policies. Several protocols now in wide use attempt to ensure that use of the domain in the author's address (ie, in the From: header field) is authorized by that domain. These protocols may be incompatible with common list features such as footers, causing participating email services to bounce list traffic merely because of the address in the From: field. This has resulted in members being unsubscribed despite being perfectly able to receive mail. The following actions are applied to all list messages when selected here. To apply these actions only to messages where the domain in the From: header is determined to use such a protocol, see the dmarc_moderation_action settings under Privacy options... -> Sender filters. Settings: [...] Munge From This action replaces the poster's address in the From: header with the list's posting address and adds the poster's address to the addresses in the original Reply-To: header. So, for example, _if_ my sending domain linuxmafia.com had a strong DMARC policy (which it doesn't, because I hate DMARC with a passion), then the 'Munge from' setting would cause my post to license-review to get this 'From: ' header upon retransmission to subscribers: From: Rick Moen via license-review <license-rev...@lists.opensource.org> instead of the normal From: Rick Moen <r...@linuxmafia.com> The reason this helps sidestep DMARC validation is that it's now no longer considered needing validation against linuxmafia.com's (hypothetical) DMARC policy, but rather lists.opensource.org's. I personally detest this solution because, when I send out my sending address on a mailing list, it is deliberately there so that people can, if necessary, contact me offlist. The kludge complicates this, albeit, if I remember correctly, it tries to compensate for the brain-damage by inserting a Reply-To as well. It should be noted that the Munge from kludge thus alters -only- the postings of subscribers from DMARC-damaged^H^H^H^W^W^W^Wusing domains, so only _some_ postings will get disfigured in this manner. Sadly, I recommend opting for this kludge, because otherwise deliverability suffers. I am specifically _not not not_ recommending the similar-looking setting 'Replace the From: header address with the list's posting address to mitigate issues stemming from the original From: domain's DMARC or similar policies' aka from_is_list on General Options. My understanding is that opting for _that_ version of the kludge unconditionally applies it to all postings whether they are from badly DMARC-impaired domains (ones with published p=reject or p=quarantine DMARC policies) or not. My recommendations: On Privacy options, Sender filters: dmarc_moderation_action: Munge from dmarc_quarantine_moderation_action): Yes dmarc_none_moderation_action: no On General options: change nothing. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
