Quoting Steve Litt (slitt@???):

> 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 <rick@???>
To: license-review-owner@???
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-review@???>

instead of the normal

From: Rick Moen <rick@???>

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.