[sf-lug] DMARC & Mailman, etc. (was: Re: Fwd: Bounce action notification)

Sun Dec 1 14:34:32 PST 2024

[Bcc: Al]
This is consequence of quite known issue with how DMARC breaks
mailing lists, and the older version of Mailman 2 on linuxmafia.com
and its lack of availability of workarounds for that.

Oh, ... reminds me ... a possibly ugly kludge of a workaround for such
recipients,
is if they are or set themselves to digest mode.

It's already been discussed quite a bit on the SF-LUG <sf-lug at linuxmafia.com>
list.

I was thinking of mentioning it again anyway, as I and many don't
receive emails from many list members due to this.  Of course it also
causes issues that are quite the annoyance for the list admins too,
as this is repeated (at least indirect) complaint of list members -
not receiving emails, not having their posts delivered to many list members,
possibly getting unsubscribed from excessive bounces, etc.

Thus far the longer term plan is to do the upgrades such that
linuxmafia.com will be able to (natively from Debian) install
"new" enough version of Mailman 2 that has those DMARC workarounds
available.
And that version of Debian will also support Mailman 3,
so it could also be transitioned to Mailman 3, and/or
other listserver software.

And I've already thoroughly tested the (fairly long and complex) set of
upgrade procedures to get linuxmafia.com to that point (tested on another
VM - initialized as an exact clone of linuxmafia.com, and then proceeding
from there).  It's waiting on a few resources to get that done:
o my time :-)  (I can generally at least wiggle it in - but will take fair
chunk
  of total time)
o Rick's final "go for it" (I probably also want to get sufficient set of
regression
  checks out of Rick, so I can step-wise do the testing so if anything
starts to
  go sideways, even a bit, should be able to catch and correct in quite
short order,
  and also be better assured all the needed was successfully completed -
but thus far
  all tests on the upgraded VM have looked fine - but need a more full set
of tests)
o storage space - need more storage space for the VM and related data,
etc.  At present
  is rather a squeeze, and might be hazardous to attempt such upgrade at
present (most
  notably not much space for backups/snapshots or the like).  And yes,
there's also
  a plan to address that (Rick and I are working on it - but don't expect
that to be
  fully taken care of all that soon ... but hopefully between now and
February or
  so, we'll have that all squared away, and that will no longer be a
blocker ...
  and would also have likely side effect of correcting an intermittent
storage issue
  on the physical host machine).

I'd also, much earlier, offered to SF-LUG, if they wanted me to host list
on the BALUG VM,
and could there do so under sf-lug.org domain (would probably do
sf-lug at lists.sf-lug.org),
I could well do that (and would now be on Mailman 3 rather than Mailman 2),
but at least
last time around that was rejected by plurality that bothered to "vote"
(express opinion
on the matter), though relatively few expressed so much as opinion one way
or the other.

And unfortunately, some years back, berkeley.edu outsourced
(most?) all their email (at least that domain, and most if not all
subdomains thereof) to Google's Gmail, so ... they don't have nearly
the control over it that they used to ... though presumably they do
at least still control DNS (though alas, they also lost control of DNS
for berkeley.ca.us. - but that's yet another story).

So, yes, DNS and SMTP mail server configurations and behavior
matter.  But alas, DMARC, etc. is problematic with lists, and
in many/most cases where DMARC has been implemented, that will
typically fail (be outright rejected) or land in "Spam" or "Junk"
or the like (quarantined), rather land in the "inbox" for many/most
recipients.  If you compare that to where workaround have been implemented,
e.g. the BALUG lists, you'll find similar has generally much better delivery
around DMARC, as it uses DMARC work-arounds, and has for quite a long time.
See, e.g.:
https://lists.balug.org/mailman3/hyperkitty/search?q=BALUG%3A+Lists%2C+stats%2C+etc.&page=1&mlist=balug-admin%40lists.balug.org&sort=date-desc
And note also headers do get rewritten for those with DMARC where
it would otherwise likely fail, e.g., changes from:
From: Michael Paoli <Michael.Paoli at berkeley.edu>
to:
From: Michael Paoli via BALUG-Admin <balug-admin at lists.balug.org>
Reply-To: Michael Paoli <Michael.Paoli at berkeley.edu>
Can also test it out on test lists, if one wants to see
the various behaviors:
http://linuxmafia.com/mailman/listinfo/test
https://lists.balug.org/mailman3/postorius/lists/balug-test.lists.balug.org/

references/excerpts:
mboxgrep(1)
grep(1)
sed(1)
Rick on DMARC/DKIM & related mailman, etc.:
http://linuxmafia.com/pipermail/sf-lug/2024q1/015984.html
http://linuxmafia.com/pipermail/sf-lug/2022q2/015594.html
http://linuxmafia.com/pipermail/sf-lug/2021q3/015357.html
http://linuxmafia.com/pipermail/sf-lug/2021q2/015279.html
http://linuxmafia.com/pipermail/sf-lug/2021q2/015247.html
http://linuxmafia.com/pipermail/sf-lug/2020q3/015010.html
http://linuxmafia.com/pipermail/sf-lug/2020q3/014927.html
http://linuxmafia.com/pipermail/sf-lug/2020q2/014752.html
http://linuxmafia.com/pipermail/sf-lug/2020q2/014747.html
http://linuxmafia.com/pipermail/sf-lug/2020q2/014741.html
http://linuxmafia.com/pipermail/sf-lug/2020q2/014736.html
migrate SF-LUG list to BALUG VM?:
http://linuxmafia.com/pipermail/sf-lug/2021q2/015298.html
http://linuxmafia.com/pipermail/sf-lug/2021q2/015247.html
http://linuxmafia.com/pipermail/sf-lug/2021q2/015246.html

On Sun, Dec 1, 2024 at 8:45 AM Al wrote:

> sorry, wasn't thinking, Berkeley doesn't default to MX, it has the usual
> long but flat list, no reference to sublists:
> ;; ANSWER SECTION:
> _spf.berkeley.edu.      10800   IN      TXT     "v=spf1 ip4:
> 169.229.218.128/25 ip4:192.31.161.27 ip4:169.229.54.192/26
> ip6:2607:f140:0:1000::/64 ip4:96.46.132.200/29 ip4:199.188.157.80 " "
> ip4:199.59.200.201 ip4:169.229.200.131 ip4:104.45.175.206
> ip4:52.224.142.128 ip4:169.229.159.67 ip4:208.75.120.0/22 ip4:
> 205.207.104.0/22 ip4:34.236.72.193 ip6:2607:f140:1:12::131 ~all"
>
>
> On 12/1/2024 08:33, Al wrote:
>
> I'm sure by now you've seen the approx. 30 reject messages detected at
> linuxmafia.com for the stats distribution.
> big "mailing list / dmarc" s**t show with berkeley.edu
>
> seems like the usual, though I don't track the berkeley dmarc records.
> currently though it screams 'reject' and IIRC the default is MX records but
> I'll have to
> go refresh my memory on that.
>
> ;; ANSWER SECTION:
> _dmarc.berkeley.edu.    10800   IN      TXT     "v=DMARC1; p=reject;
> pct=100; rua=mailto:dmarcrpt at berkeley.edu <dmarcrpt at berkeley.edu>; ruf=
> mailto:dmarcrpt at berkeley.edu <dmarcrpt at berkeley.edu>"
>
> is it time to suffer through rewriting the "From:" header to something
> like: OriginalSender <sflug.org at linuxmafia.com> <sflug.org at linuxmafia.com>
> and work with some combination of Reply-To:/Sender:/X-Original-From: ?
>
> I wonder if someone less knowledgeable changed Berkeley's records recently?
> I see the record at UCSF seems to reflect more experience if still a bit
> stringent.  It includes subdomains and uses proofpoint.com to handle
> reports.
> Still, it also rejects everything and defaults to MX.
>
> -------- Forwarded Message --------
> Subject: Bounce action notification
> Date: Sun, 01 Dec 2024 06:45:36 -0800
> From: mailman at linuxmafia.com
> To: sf-lug-owner at linuxmafia.com
>
> This is a Mailman mailing list bounce action notice:
>
> List: sf-lug
> Member: @yahoo.com
> Action: Subscription disabled.
> Reason: Excessive or fatal bounces.
>
>
> The triggering bounce notice is attached below.
>
> Questions? Contact the Mailman site administrator at
> mailman at linuxmafia.com.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20241201/7cd42a0d/attachment-0001.html>