Steve Litt migrated GoLUG's mailing list on an emergency basis to ezmlm. I just wanted to make him aware of the DMARC problem.
----- Forwarded message from Rick Moen <[email protected]> ----- Date: Sat, 24 Sep 2022 21:29:13 -0700 From: Rick Moen <[email protected]> To: [email protected] Subject: DMARC mitigation, ezmlm, and [email protected] Organization: If you lived here, you'd be $HOME already. I'm going to need to skip a _whole_ lot of detail, here, as I'm not going to write a whole darned tutorial about MLMs (mailing list managers) and the SMTP forgery problem. I need to skip a lot and get to the point. Yahoo introduced around 2012 a suggested set of extensions to SMTP and DNS to detect and defeat (1) correction and changes to the internal contents of the sender's mail, and (2) forgery of the sender's domain. This was a stack of two standards. DKIM is message-signing, signing the body-text and selected interior headers using a key published by the sending domain in the sending domain's DNS. DMARC is a higher-level standard that allows an organisation to publish in its DNS a policy that specifies which mechanism (DKIM, SPF, or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures—and a reporting mechanism for actions performed under those policies. Problem: The way DKIM was drafted, it is hostile to mailing lists, in that any mailing list subscriber's domain that publishes a p=reject or p=quarantine policy in its DNS DMARC record will arrive at fellow-subscribers' mail providers, after transiting the MLM, now failing DMARC validation, and _if_ the receiving SMTP host implements DMARC and honours the sending subscriber's domain's DMARC policy, the receiving SMTP host will reject or spambox ("quarantine") the posting as forged. Rejections get reported back to the MLM software as 55x SMTP rejections, i.e., hardfail delivery failures, and thus the _receiving_ subscribers (not the sending one) get their "bounce scores" in the MLM incremented, eventually getting delivery disabled and unsubscribed. Take a moment to think about how pernicious and iceberg-like (9/10 below the surface) this effect is. The _sender_ posting from a DMARC-afflicted domain perceives and experiences no problem. It is _other_ subscribers, ones whose mail providers enforce the _sender's_ domain's overly aggressive DMARC policy, who mysteriously fail to receive postings, over time get high bounce scores, get their delivery disabled, etc. _They_ tend eventually, in bewilderment, complain to the listadmin, who, unless quite technical and/or warned about this menace, will be also puzzled and apologetic, but have no idea where the problem arose. And, ultimately, the problem isn't even the sending subscriber. It's DKIM/DMARc. Important to note, also, Yahoo did not _need_ to define DKIM in such a haphazard way as to break DKIM alignment just by passing the mail through an MLM reflector. They could have drafted it so that MLM-standard modifications, namely the footer, the extra headers, minor changes to the Subject header, and so on, were disregarded for purposes of DKIM/DMARC compliance verification. They just couldn't be arsed to do so. When it was pointed out to the DKIM/DMARC designers that any DMARC p=reject or p=quarantine policy is damaging to, and hostile to the operation of, all the entire planet's MLMs, their official answer, as seen in the DMARC FAQ[1], amounts to, "Well tough. Every mailing list program in the world will have to get rewritten to compensate for the way DKIM works." Really. That's their position. Rewrite everything, or we'll sabotage your mailing lists. The proprietary LISTSERV software came up with some kludge to work around the DMARC problem. I _think_ so did Sympa. And recent versions of Mailman2 and Mailman3 have a kludge. I can speak to how the Mailman workaround -- which, by the way, at least in Mailman2 versions that offer it, is non-default and must be defensively enabled by a wary listadmin -- functions. Alteration 1 of 2: In the listadmin configuration pages for a mailing list, go to Privacy Options, Sender Filters. Change "Action to take when anyone posts to the list from a domain with a DMARC Reject/Quarantine Policy" from "Accept" (default) to "Munge From". Here's the help text for that (in part): 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: No Do nothing special. This is appropriate for anonymous lists. It is appropriate for dedicated announcement lists, unless the From: address of authorized posters might be in a domain with a DMARC or similar policy. It is also appropriate if you choose to use dmarc_moderation_action other than Accept for this list. 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. Wrap Message Just wrap the message in an outer message with the From: header containing the list's posting address and with the original From: address added to the addresses in the original Reply-To: header and with Content-Type: message/rfc822. This is effectively a one message MIME format digest. The transformations for anonymous_list are applied before any of these actions. It is not useful to apply actions other than No to an anonymous list, and if you do so, the result may be surprising. The Reply-To: header munging actions below interact with these actions as follows: first_strip_reply_to = Yes will remove all the incoming Reply-To: addresses but will still add the poster's address to Reply-To: for all three settings of reply_goes_to_list which respectively will result in just the poster's address, the poster's address and the list posting address or the poster's address and the explicit reply_to_address in the outgoing Reply-To: header. If first_strip_reply_to = No the poster's address in the original From: header, if not already included in the Reply-To:, will be added to any existing Reply-To: address(es). Alteration 2 of 2: Change item "Shall the above dmarc_moderation_action apply to messages From: domains with DMARC p=quarantine as well as p=reject" from "no" (default) to "yes". The above Mailman kludge is a clever (if regrettable) workaround where Mailman swaps out the sending subscriber's genuine "From:" header for a faked one substituting the mailing list's own address as claimed sender, doing this damage _selectively_ only on postings from subscribers with sending domains publishing p=reject or p=quarantine DMARC policies (i.e., aggressive DMARC policies). So, it is targeted semantic damage to the sender's mail, targeted in the sense of it _not_ being applied except in the case of domains that would otherwise cause problems. It is a least-bad aftermarket fix by the Mailman developers. And that brings me to ezmlm. Daniel J. Bernstein ("djb") wrote it, and there's a lot to like about it. He orphaned it in 1997. The DMARC problem was sprung onto the world in 2012. Dan purported to retroactively place almost all of his software, by unilateral act of will, into the public domain in a public anouncement on Nov. 30, 2007, after a hilarious losing fight with Theo de Raadt and other key OpenBSD figures in 2013, over Dan's confusing but proprietary licensing that he consistently used up until then. (See; http://linuxmafia.com/pub/humour/dan-versus-theo) What Dan has _not_ done, is resume software maintenance. Which is fine! I appreciate what Dan has done for this world. Seriously. Dan considers me something of a personal devil figure (long story possibly having to do with my having been a prominent public critic, and explainer, of his apparently deliberately confusing licensing), but I have never returned the gesture of hostility. I even have mostly nice things to say about the djbware crowd, and almost never use bad words like "cult". ;-> And, since 2007, when Dan did the problematic-but-good-enough public domain thing, I'd even consider using some of the various stuff. But who is keeping ezmlm current? Some software can be considered "finished" rather than unmaintained, the classic example being procmail. But, not to put too fine a point on it, has someone retrofitted a DMARC mitigation to ezmlm? Will anyone? I ask because I don't know. I worry a bit, because, over the decades before 2007, when Dan used his semi-covertly-proprietary licensing to enforce some modernity-hostile improvements (such as FHS compliance), the *ix software world mostly moved on from his stuff. The argument that qmail was better than Sendmail lost force when Postfix and Courier-MTA and Exim joined in. The argument that djbdns was better than BIND8 lost force when NSD, Unbound, PowerDNS, MaraDNS, and Deadwood joined in. And the argument that ezmlm was better than majordomo failed in the face of Mailman2 and Sympa. Maybe unfair? But the mindshare left. Possibly ezmlm's day has returned, with Mailman3 doing dumb things and not getting better. I see a claim that "ezmlm-idx has a workaround for DMARC". https://www.openwall.com/lists/musl/2017/12/05/3 If I were you, Steve, I'd look into that. [1] https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F See also: https://dmarcian.com/mailing-lists-dmarc/ ----- End forwarded message ----- _______________________________________________ luv-main mailing list -- [email protected] To unsubscribe send an email to [email protected]
