[BALUG-Admin] Going through delivery notices for balug-* subscribers

[Rick Moen]

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-transaction-problem-in-exim-conf.45326/

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.