possible backscatter attack using Mailman3 servers
Greetings. On a system running Mailman 3.3.9 and Postfix, I'm seeing about 20-30 entries per day in the Postfix queue where it appears a Gmail user signs up for a mailing list that requires confirmation, and Gmail responds that the user is too busy to handle requests.
There are no publicly advertised email lists on this server, and I don't ever see anything in the Mailman logs indicating the user ever tried signing up.
I've pasted the mail.log transaction below, with only slight obfuscation:
"mail10.example1.com" is this server's canonical hostname
lists are hosted on "lists.example2.com" and "mail.example3.com"
"someuser9413@gmail.com" is the user supposedly signing up
Thanks in advance for clues on determining where these requests are coming from, and how I might block them. I have a strong interest in having my server not amplifying backscatter traffic like this.
Alternatively, if this is a Postfix problem, please let me know that too.
dn
Jan 3 10:29:22 mail10 postfix/postscreen[4052406]: CONNECT from [::1]:55274 to [::1]:25 Jan 3 10:29:22 mail10 postfix/postscreen[4052406]: WHITELISTED [::1]:55274 Jan 3 10:29:22 mail10 postfix/postscreen[4052406]: using backwards-compatible default setting respectful_logging=no for client [::1]:55274 Jan 3 10:29:22 mail10 postfix/smtpd[4052407]: connect from localhost[::1] Jan 3 10:29:22 mail10 postfix/smtpd[4052407]: discarding EHLO keywords: CHUNKING Jan 3 10:29:22 mail10 postfix/smtpd[4052407]: 4YPsYG1X2xzHQfw: client=localhost[::1] Jan 3 10:29:22 mail10 postfix/cleanup[4052628]: 4YPsYG1X2xzHQfw: message-id=<173592896219.2314.15515568084960961396@mail10.example1.com> Jan 3 10:29:22 mail10 postfix/smtpd[4052407]: disconnect from localhost[::1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Jan 3 10:29:22 mail10 postfix/qmgr[3635053]: 4YPsYG1X2xzHQfw: from=<postmaster@example2.com>, size=901, nrcpt=1 (queue active) Jan 3 10:29:22 mail10 postfix/10025/smtpd[4052639]: connect from localhost[127.0.0.1] Jan 3 10:29:22 mail10 postfix/10025/smtpd[4052639]: discarding EHLO keywords: CHUNKING Jan 3 10:29:22 mail10 postfix/10025/smtpd[4052639]: 4YPsYG33SkzHSdN: client=localhost[127.0.0.1] Jan 3 10:29:22 mail10 postfix/cleanup[4052628]: 4YPsYG33SkzHSdN: message-id=<173592896219.2314.15515568084960961396@mail10.example1.com> Jan 3 10:29:22 mail10 postfix/10025/smtpd[4052639]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Jan 3 10:29:22 mail10 postfix/qmgr[3635053]: 4YPsYG33SkzHSdN: from=<postmaster@example2.com>, size=1939, nrcpt=1 (queue active) Jan 3 10:29:22 mail10 amavis[4017234]: (4017234-09) Passed CLEAN {RelayedInternal}, MYNETS/MYUSERS LOCAL [::1]:55274 ESMTP/ESMTP <postmaster@example2.com> -> <someuser9413@gmail.com>, (), Queue-ID: 4YPsYG1X2xzHQfw, Message-ID: <173592896219.2314.15515568084960961396@mail10.example1.com>, mail_id: P9P7GnranpAW, b: Zp0DirpBL, Hits: -, size: 900, queued_as: 4YPsYG33SkzHSdN, Subject: "[mail.example3.com] Please Confirm Your Email Address", From: <postmaster@example2.com>, helo=mail10.example1.com, dkim_new=dkim:example1.com, 217 ms Jan 3 10:29:22 mail10 postfix/amavis/smtp[4052633]: 4YPsYG1X2xzHQfw: to=<someuser9413@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.24, delays=0.02/0/0.01/0.21, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4YPsYG33SkzHSdN) Jan 3 10:29:22 mail10 postfix/qmgr[3635053]: 4YPsYG1X2xzHQfw: removed Jan 3 10:29:22 mail10 postfix/smtp[4052642]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2607:f8b0:4023:c0d::1b]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256 Jan 3 10:29:22 mail10 postfix/smtp[4052642]: 4YPsYG33SkzHSdN: host gmail-smtp-in.l.google.com[2607:f8b0:4023:c0d::1b] 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 98e67ed59e1d1-2f2ed632fdfsi39876934a91.55 - gsmtp (in reply to RCPT TO command) Jan 3 10:29:22 mail10 postfix/smtp[4052642]: Trusted TLS connection established to gmail-smtp-in.l.google.com[142.251.2.27]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256 Jan 3 10:29:22 mail10 postfix/smtp[4052642]: 4YPsYG33SkzHSdN: to=<someuser9413@gmail.com>, relay=gmail-smtp-in.l.google.com[142.251.2.27]:25, delay=0.46, delays=0.01/0/0.4/0.04, dsn=4.2.1, status=deferred (host gmail-smtp-in.l.google.com[142.251.2.27] 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 d2e1a72fcca58-72aad8fd529si37008995b3a.196 - gsmtp (in reply to RCPT TO command))
On 1/3/25 16:18, David Newman wrote:
Greetings. On a system running Mailman 3.3.9 and Postfix, I'm seeing about 20-30 entries per day in the Postfix queue where it appears a Gmail user signs up for a mailing list that requires confirmation, and Gmail responds that the user is too busy to handle requests.
There are no publicly advertised email lists on this server, and I don't ever see anything in the Mailman logs indicating the user ever tried signing up.
This is an attack mail bombing the user. The requests that result in the can come via web or email. Mailman's logging of subscribes has been missing most events through Mailman 3.3.10. See https://gitlab.com/mailman/mailman/-/issues/1143 which will be fixed in 3.3.11, but subscribes waiting user confirmation still won't be logged.
However, the message with subject "Please Confirm Your Email Address" comes from Django allauth so it isn't actually Mailman sending it but rather Django allauth as a result of a request to sign up for a Django account at https://mail.example3.com/accounts/signup/. You can probably find that request in your web server logs, and you may find the user and/or email in the Django admin UI.
Since django-mailman3 1.3.6, you can disable these signups by putting
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
in your Django settings, but then your users won't be able to sign up for web accounts.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/3/25 5:44 PM, Mark Sapiro wrote:
Greetings. On a system running Mailman 3.3.9 and Postfix, I'm seeing about 20-30 entries per day in the Postfix queue where it appears a Gmail user signs up for a mailing list that requires confirmation, and Gmail responds that the user is too busy to handle requests.
There are no publicly advertised email lists on this server, and I don't ever see anything in the Mailman logs indicating the user ever tried signing up.
This is an attack mail bombing the user. The requests that result in the can come via web or email. Mailman's logging of subscribes has been missing most events through Mailman 3.3.10. See https://gitlab.com/ mailman/mailman/-/issues/1143 which will be fixed in 3.3.11, but subscribes waiting user confirmation still won't be logged.
However, the message with subject "Please Confirm Your Email Address" comes from Django allauth so it isn't actually Mailman sending it but rather Django allauth as a result of a request to sign up for a Django account at https://mail.example3.com/accounts/signup/. You can probably find that request in your web server logs, and you may find the user and/or email in the Django admin UI.
Thanks VERY much for this.
No such users in the Django UI, but the web server logs have 252 attempts from 132 unique IPv4 addresses registered to different ISPs throughout Europe.
So, even though Mailman support for more detailed logging of sub and unsub requests would be useful, it likely would not have helped with attacks from many source IP addresses.
Since django-mailman3 1.3.6, you can disable these signups by putting
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
in your Django settings, but then your users won't be able to sign up for web accounts.
I have made this change. As for not having web accounts, this just means new users cannot sign up to manage their Mailman settings, correct? I presume existing web accounts will continue to work.
Thanks again!
dn
On Sat, Jan 4, 2025 at 5:30 AM David Newman <dnewman@networktest.com> wrote:
On 1/3/25 5:44 PM, Mark Sapiro wrote:
Greetings. On a system running Mailman 3.3.9 and Postfix, I'm seeing about 20-30 entries per day in the Postfix queue where it appears a Gmail user signs up for a mailing list that requires confirmation, and Gmail responds that the user is too busy to handle requests.
There are no publicly advertised email lists on this server, and I don't ever see anything in the Mailman logs indicating the user ever tried signing up.
This is an attack mail bombing the user. The requests that result in the can come via web or email. Mailman's logging of subscribes has been missing most events through Mailman 3.3.10. See https://gitlab.com/ mailman/mailman/-/issues/1143 which will be fixed in 3.3.11, but subscribes waiting user confirmation still won't be logged.
However, the message with subject "Please Confirm Your Email Address" comes from Django allauth so it isn't actually Mailman sending it but rather Django allauth as a result of a request to sign up for a Django account at https://mail.example3.com/accounts/signup/. You can probably find that request in your web server logs, and you may find the user and/or email in the Django admin UI.
Thanks VERY much for this.
No such users in the Django UI, but the web server logs have 252 attempts from 132 unique IPv4 addresses registered to different ISPs throughout Europe.
So, even though Mailman support for more detailed logging of sub and unsub requests would be useful, it likely would not have helped with attacks from many source IP addresses.
Since django-mailman3 1.3.6, you can disable these signups by putting
ACCOUNT_ADAPTER =
'django_mailman3.views.user_adapter.DisableSignupAdapter'
in your Django settings, but then your users won't be able to sign up for web accounts.
I have made this change. As for not having web accounts, this just means new users cannot sign up to manage their Mailman settings, correct? I presume existing web accounts will continue to work.
You could also try this: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... It really helped in many cases, although with the change you already made, it becomes a useless effort.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
participants (3)
-
David Newman -
Mark Sapiro -
Odhiambo Washington