Seven things to note/follow-up things I did. Item #6 includes a question.
Item 1, Google being a problem child:
sarah@cloudmade.com, BALUG-Announce, disabled too many bounces sarah@cloudmade.com host aspmx2.googlemail.com [142.250.115.26] SMTP error from remote mail server after RCPT TO:sarah@cloudmade.com: 451-4.3.0 Multiple destination domains per transaction is unsupported. Please 451 4.3.0 try again. o33-20020a05687107a100b0010cf5ab4f5dsi16685048oap.145 - gsmtp: retry timeout exceeded RM: So, this is Google being a pooh-pooh head. Discussed at places like https://forum.directadmin.com/threads/gmail-multiple-destination-domains-per...
Since lists.balug.org uses Exim, the mitigation mentioned for Exim in that and similar discussions of how to deal with GMail's fussiness _could_ be enabled. Worth considering.
_OTOH_, it's just a tempfail, on their part. Subscribers who got these would have gotten their mail after retry attempts. So, the counter-argument would be "No, we're not going to make outbound mail inefficient just because Google is being a pooh-pooh head."
Item 2, probably DNSBL refusals:
pozar@lns.com, BALUG-Announce, disabled too many bounces pozar@lns.com host lns.com [107.161.208.1] SMTP error from remote mail server after RCPT TO:pozar@lns.com: 554 5.7.1 Service unavailable; Client host [96.86.170.229] blocked using b.barracudacentral.org; http://www.barracudanetworks.com/reputation/?pr=1&ip=96.86.170.229
As a reminder, 96.86.170.229 being on a bunch of industry DNSBLs still exists, and is on your plate, Michael. E.g., if you're pretty sure we're running a clean mail operation, you could go through the IP-removal drill at those DNSBLs. I've systemically removed _one_ possible cause of our getting there, by switching off "monthly password reminder" mails. So, at least _that_ would not get falsely reported to the DNSBLs by subscribers.
https://multirbl.valli.org/dnsbl-lookup/96.86.170.229.html lists nine blacklists. (There are some double-counts among the nine.)
One of the interesting ones is the RFC Clueless "postmaster" DNSBL, claiming that IP 96.86.170.229 refuses mail to postmaster@ . You said you checked that from an external IP. This is me verifying that they're on crack.
$ telnet 96.86.170.229 25 Trying 96.86.170.229... Connected to 96.86.170.229. Escape character is '^]'. 220 balug-sf-lug-v2.balug.org ESMTP Exim 4.92 Mon, 25 Jul 2022 22:03:51 +0000 HELO linuxmafia.com. 250 balug-sf-lug-v2.balug.org Hello linuxmafia.com [96.95.217.99] MAIL FROM: root@linuxmafia.com 250 OK RCPT TO: postmaster@lists.balug.org 250 Accepted DATA 354 Enter message, ending with "." on a line by itself From: root@linuxmafia.com To: postmaster@lists.balug.org Subject: test1
Testing. . 250 OK id=1oG6Bp-0005to-1X MAIL FROM: root@linuxmafia.com 250 OK RCPT TO: postmaster@balug.org 250 Accepted DATA 354 Enter message, ending with "." on a line by itself From: root@linuxmafia.com To: postmaster@balug.org Subject: test2
Testing. . 250 OK id=1oG6Cm-0005to-UY quit 221 balug-sf-lug-v2.balug.org closing connection Connection closed by foreign host. $
Maybe there's a polite way to say "Dear Sirs: You're on crack" and get removal (and help them figure out why they got a false positive).
Item 3, cryptic DSNs, retention, and re-enablement:
aavasthi@vmware.com, BALUG-Announce, disabled too many bounces. Reported error: 550 5.7.1 TRANSPORT.RULES.RejectMessage; the message was rejected by organization policy DSN generated by: DM6PR05MB5083.namprd05.prod.outlook.com
This is an example of what I call a "cryptic DSN", that _may_ refer to bad IP reputation. Thus, I retained subscribers like this, and re-enabled mail delivery.
Item 4, antispam heuristic on crack:
host gourmet7.spamgourmet.com [216.75.62.102] SMTP error from remote mail server after pipelined end of data: 550-X-Host-Lookup-Failed: Reverse DNS lookup does not match for 96.86.170.229 550 (deferred) cba@groundworkopensource.com
WTF?
$ dig -x 96.86.170.229 +short balug.org. $
I re-enabled delivery.
Item 5, removal of proven bad addresses from balug-talk and balug-admin (too):
I fed that massive set of e-mail addresses to unsubscribe into, also, the mass-removal form for balug-talk. That resulted in removing these bad addresses:
shane@eckertdevelopment.com rbuster@busterdigital.com ken@gaugler.com livinglatexkali@gmail.com joe@2resonate.net jlo@takalo.org andy@simulsys.demon.co.uk mail-archiver@skryb.info linux@roguehorse.com pricen@live-int.com
Feeding it into the mass-removal form for balug-admin resulted in removing these bad addresses:
mail-archiver@skryb.info linux@roguehorse.com
Item 6, can we please fix the listadmin rosters?
As I've said several times, I think showing in public a "role" address of balug-talk-owner@lists.balug.org for the four balug-* mailing lists (in Mailman's per-list config) is a bad idea and an accident waiting to happen. Would you at least please tell me how that address (currently) resolves (e.g., is it a line in /etc/aliases?) and to what address(es)?
In addition, I continue to urge substituting the real listadmin address(es) for the role address.
Item 7, probable violation of antispam best practices / rule:
It occurs to me that this practice of BALUG's (disclosed on https://lists.balug.org/cgi-bin/mailman/listinfo/balug-announce), alone, is likely to get BALUG's IP onto DNSBLs:
If you're subscribed to BALUG-Talk and/or BALUG-Admin, but not subscribed to BALUG-Announce, expect that we will subscribe you to BALUG-Announce. If you wish to be excepted from that (or for more information), please see: BALUG-announce-do-not-auto-add.html.
That outright violates the mail-industry rule that nobody should ever be put onto a mailing list without 3-way handshake. It can be and perhaps is cited as our IP being a spamhaus. Saying we do it and allowing people who object to write to balug-announce-do-not-auto-add@balug.org to request removal doesn't solve the problem.
I (again) urge BALUG ceasing to do it.