As of today, the esteemed Dng listadmins have made a small tweak
to Mailman's operation, and have asked me to explain the change.
_No_ action is required on your end.

tl;dr: Mailman will now munge the From: address if and only if the
sender's domain publishes a problematic DMARC policy, to substitute the
mailing list's address for the sender's. On those mails, Mailman
also appends a Reply-To: header pointing to the sender's real address.
No other mails will be touched.


Forgery of SMTP mail is a serious problem, leading to a series of
proposals for extensions to the SMTP standard, to permit domains and
users to enable receiving mail systems to detect and reject forgeries:
SPF, DKIM (formerly DomainKeys), and DMARC. DMARC, from Yahoo, is the
most recent of these SMTP extensions (incorporating DKIM and SPF as
sub-components). Unfortunately, DMARC, when implemented by sending
domains publishing a strongly asserted DMARC antiforgery policy, tends
to be a disaster for mailing lists: Subscribers sending from such mail
domains gradually discover that their outbound mail, when routed out
through mailing list software and thus retransmitted to mailing list
subscribers, gets refused (as forged) upon arrival at many of the
subscribers' receiving SMTP servers.

Q: Why does that mail get rejected as forged?

A: Because the mailing list manager (MLM) software alters and makes
additions to the sender's headers and body text, on the copies
retransmitted to subscribers, with the result that the message no longer
matches its DKIM cryptographic signature.


Q: Which sending domains are affected?

A: I referred to these as sending domains with 'strongly asserted DMARC
antiforgery policies'. Specifically, this means domains that publish
p=reject or p=quarantine as part of the DMARC policies in their DNS.
Here's an example of the former, domain mongodb.com:

$ dig -t txt _dmarc.mongodb.com 
[...]
_dmarc.mongodb.com.    300    IN    CNAME   mongodb.com.hosted.dmarc-report.com.
mongodb.com.hosted.dmarc-report.com. 300 IN TXT    "v=DMARC1; p=reject; rua=mailto:1eed4417@mxtoolbox.dmarc-report.com,mailto:dmarc_agg@vali.email,mailto:dmarc_reports@mongodb.com; ruf=mailto:1eed4417@forensics.dmarc-report.com,mailto:dmarc_reports@mongodb.com"
[...]
$

Q: Which receiving domains reject such mail?

A: Domains that implement DMARC and respect/enforce (some) sending domains'
strongly asserted DMARC policies. For example, GMail exactly enforces
sending domains' published DMARC policies (if any), when it decides what
arriving mail to reject as forged.



Q: If Mailman rewrites my mail for transmission to subscribers, what
would that look like?

A: Like this (using me as an example poster)

From: Rick Moen via Dng <dng@???>
(with)
Reply-To: Rick Moen <rick@???>

instead of the normal

From: Rick Moen <rick@???>

This example is what would occur if domain linuxmafia.com had a strongly
asserted DMARC policy, which in reality it doesn't (because domain owner
Rick Moen doesn't like DMARC).



Q: Isn't 'munging' (forcing) of the Reply-To: header by anyone but the
sender been officially a bad idea ever since IETF adopted RFCs 2822
and 2369 in 2001?

A: Yes. Ironic, isn't it? GNU Mailman adopted and recommended this
mitigation for the problems caused by DMARC anway, as it's the least-bad
response to the fundamental hostility DMARC has for mailing lists as
reflectors. The Mailman developers might eventually come up with
something better, but this is the best solution they have at this
writing.


Q: Are other MLMs also affeected?

A: Yes.


Q: Who decided to adopt this modification to Dng's operation?

A: It was a unanimous recommendation of the Devuan Project's weekly
Jitsi conference on December 5, 2018.