25 Jan
2024
25 Jan
'24
2:03 a.m.
it looks like it's happening again? Third one in three days like this...
-jake
This is the mail system at host sudoroom.org.
####################################################################
# THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################
Your message could not be delivered for more than 3 hour(s).
It will be retried until it is 2 day(s) old.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<EWBLUE09(a)GMAIL.COM>OM>: host alt1.gmail-smtp-in.l.google.COM[108.177.104.26]
said: 450-4.2.1 The user you are trying to contact is receiving mail at a
rate that 450-4.2.1 prevents additional messages from being delivered.
Please resend your 450-4.2.1 message at a later time. If the user is able
to receive mail at that 450-4.2.1 time, your message will be delivered. For
more information, go to 450 4.2.1
https://support.google.com/mail/?p=ReceivingRate
ez8-20020a0568082a0800b003bbd77157dasi5153333oib.163 - gsmtp (in reply to
RCPT TO command)
NOTE: emails to the Info list were sent to an individual email address (such as
info(a)sudoroom.org) with the PRESUMPTION OF PRIVACY. They may include personal information
which the sender would not have sent to a public list (such as sudo-discuss). If you must
forward messages to a public list, please take great care to REMOVE SENSITIVE INFORMATION!
_______________________________________________
Info mailing list -- info(a)sudoroom.org
To unsubscribe send an email to info-leave(a)sudoroom.org
31 Jan
31 Jan
1:58 p.m.
a new spate of failed emails....it seems like it's time for a captcha or
something! anyone willing to work on this?
anything i can do to help? I'm not sure how or where to edit things but I can
try, if someone can advise me
-jake
On Thu, 25 Jan 2024, Jake via sudo-sys wrote:
it looks like it's happening again? Third one in
three days like this...
-jake
2:06 p.m.
to provide more context, it seems that spammers are signing up for our email
list with failing email addresses for some reason:
https://sudoroom.org/lists/hyperkitty/list/info@sudoroom.org/
I think Sean blacklisted tor exit nodes to address this but it started
happening again?
-jake
On Wed, 31 Jan 2024, Jake via sudo-sys wrote:
10:40 p.m.
On Wed, Jan 31, 2024 at 02:06:24PM -0800, Jake wrote:
Sorry I haven't had the time to look into this. I have no idea if this
campaign was solely done through Tor, and blocking often devolves into
an endless game of whack-a-mole.
Just throwing an idea out there: the gmail rejection is a very specific
one that is extremely unlikely to occur for normal users. It might be OK
to do some Postfix regex voodoo to turn that error into a permanent
failure so it doesn't try to queue up those messages for retry.
--Sean
1 Feb
1 Feb
2:54 p.m.
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?
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/
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 :)
thank again
-jake
On Wed, 31 Jan 2024, Sean Greenslade via sudo-sys wrote:
10:22 p.m.
On Thu, Feb 01, 2024 at 02:54:20PM -0800, Jake wrote:
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.
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.
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
440
days inactive
448
days old
5 comments
2 participants
participants (2)
-
Jake -
Sean Greenslade