[conspire] (forw) DMARC mitigation, ezmlm, and golugtech at lists.troubleshooters.com

[Rick Moen]

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 <rick at linuxmafia.com> -----

Date: Sat, 24 Sep 2022 21:29:13 -0700
From: Rick Moen <rick at linuxmafia.com>
To: golugtech at lists.troubleshooters.com
Subject: DMARC mitigation, ezmlm, and golugtech at lists.troubleshooters.com
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 -----