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:1eed4...@mxtoolbox.dmarc-report.com,mailto:dmarc_agg@vali.email,mailto:dmarc_repo...@mongodb.com; ruf=mailto:1eed4...@forensics.dmarc-report.com,mailto:dmarc_repo...@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@lists.dyne.org> (with) Reply-To: Rick Moen <r...@linuxmafia.com> instead of the normal From: Rick Moen <r...@linuxmafia.com> 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng