On Thu, Feb 01, 2024 at 02:54:20PM -0800, Jake wrote:
It's ok that you don't have time to work on it
- do you think you can tell me
a little more about what skill set we need to have to work on it? Is Postfix
the software we're running that we need to poke at? We need to configure it
to consider the replies we get from Google to be permanent, rather than retry?
Postfix is the Mail Transfer Agent (MTA) software that handles the nitty
gritty of actually sending and receiving emails on the server. Mailman
(and its various components) partially integrates with postfix and
provides all of the higher-level mailing list features (subscription
management, bounce processing, etc).
When a user (or a bot) subscribes to a mailing list, the subscription
confirmation email gets generated by mailman and handed over to postfix
for mailing. In the case of these bots, the destination server is gmail,
so postfix connects to gmail and attempts to send the email. Gmail
rejects the message with a 450 rejection code and a human-readable text
blurb with some details on why it was rejected. In SMTP, a 450 is a
temporary rejection. Thus, postfix puts the mail in its retry queue and
will try sending the same message again later. The alerts you are
getting are from postfix saying that a message has been stuck in this
retry queue for longer than normal. By default, messages will be dropped
from this queue if they don't get through after 5 days.
The specific text of the rejection suggests that these mailboxes are
receiving vastly larger amounts of mail than is normal. Normal users
would rarely if ever receive over 3600 emails in a single day, which is
why I think it would be pretty safe to treat this particular temporary
rejection as a permanent rejection. The only risk would be that if any
of our existing list subscribers actually hit that limit, they might be
automatically unsubscribed by mailman due to the rejection.
Alternately, if we want to add steps to the page where
people "sign up" to the
mailing list, would that be Postorius software? This page:
https://sudoroom.org/lists/postorius/lists/sudo-discuss.sudoroom.org/
Indeed, that would be a valid way of making it harder for bots to
attempt to subscribe. It would also add friction for human users, and
would be more complicated and harder to integrate cleanly since mailman
is a Debian package that will potentially overwrite changes made to its
files whenever an update is run.
My next step will be to write an email to the sudo
discuss list looking for
someone who has the time and skills to work on this, and then filter for
members we can trust with access to the server backend :)
I'll see if I can take a stab at this over the weekend. Can you forward
me the most recent of these warning emails as an attachment? That way I
can take a look at the headers.
But yeah, if I can't get it done, feel free to ask around. Someone with
experience managing email servers would be great. Postfix is a very
common MTA, so almost anyone with email server experience should be at
least somewhat familiar with it.
--Sean