Quoting 'smee via Dng (dng@???):

> Is there a clear rule about when the sender displays as an individual,
> vs "individual via DNG<dng@???>"?

Herewith, a repost:


Date: Thu, 6 Dec 2018 02:02:30 -0800
From: Rick Moen <rick@???>
To: dng@???
Subject: Dng now alters (some) posts to compensate for DMARC antiforgery

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 at mail-receipt time 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.