Opened 2 years ago

Last modified 12 days ago

#11675 assigned Bug/Something is broken

Account being spammed by "New subscription requests"

Reported by: Owned by:
Priority: Urgent Component: Tech
Keywords: Cc:
Sensitive: no


Since April 10, one of our lists: resistanceinbrooklyn@… has been getting up to 25 messages of a day purporting to be New subscription requests. But they are clearly spam, as each day several appear with the same first part of the addressed followed by "+" and a different suffix.

See sample below.

How can we stop this time-consuming spam?

Thanks, Bob Lederer

Subject: New subscription request to list Resistanceinbrooklyn from killerkeemstar+xkts@… Date: Sat, 16 Apr 2016 15:44:51 -0400 From: resistanceinbrooklyn-owner@… To: resistanceinbrooklyn-owner@…

Your authorization is required for a mailing list subscription request approval:

For: killerkeemstar+xkts@… List: resistanceinbrooklyn@…

At your convenience, visit:

to process the request.

Change History (17)

comment:1 Changed 2 years ago by

  • Keywords added
  • Owner set to
  • Priority changed from Medium to Urgent
  • Status changed from new to assigned

Thank you for reporting this. I can see that not only your list but all of our lists are being spammed by subscriptions. We have a fail2ban filter meant to limit this kind of list subscription spamming but these subscription are using a pattern that is not triggering the fail2ban rules all of the time. I'm copying to jamie here as I continue searching for a solution.

comment:2 Changed 2 years ago by

So again, thank you for bringing this to our attention. It seems that bots were auto subscribing a large number of addresses to all of our lists using a gmail alias patterns.

We were finally able to stop bots from auto subscribing using the technique described here:

This is actually almost identical to one of the administrative scripts shared by mailman's lead developer.

We successfully banned new subscriptions matching the appropriate regex like this:

/usr/lib/mailman/bin/withlist -a -r ban "^[^+]+\+[^+]+@gmail\.com"

This stopped the attack but there were already a few thousand pending subscription requests spread out across all lists and some lists processed subscriptions automatically. I made conservative use of another two of Mark Shapiro's scripts and to delete the pending subscription requests what appeared to be false subscriptions.

The same process was repeated on leslie and assata.

Last edited 2 years ago by (previous) (diff)

comment:3 Changed 2 years ago by

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:4 Changed 8 months ago by

  • Resolution fixed deleted
  • Status changed from closed to assigned

More subscriptions in the same spirit - here are examples:

comment:5 Changed 8 months ago by

I banning new subscriptions with:

/usr/lib/mailman/bin/withlist -a -r ban "^(the_real_green_giant|therealgreengiant|squoon|sqoonart)\+[^+]+@(hotmail\.com|hotmail\.co\.uk|live\.com|outlook\.com)"

comment:6 Changed 8 months ago by

I then looked for all requests using this pattern with:

/usr/lib/mailman/bin/list_requests  | egrep -o "(the_real_green_giant|therealgreengiant|squoon|sqoonart)\+[^+]+@(hotmail\.com|hotmail\.co\.uk|live\.com|outlook\.com)" | tee delete.these.requests

And then deleted them with:

for email in $(sort delete.these.requests | sort | uniq); do /var/lib/mailman/bin/erase "$email"; done

I'm pretty sure we are not done with this issue... not sure how we can address this is in a better way to detect and stop this kind of abuse.

comment:7 Changed 7 months ago by

This takes a really long time.

I sped things up for resistanceinbrooklyn by getting a list of the addresses with pending subscribes for them:

/usr/lib/mailman/bin/list_requests -l resistanceinbrooklyn  | egrep -o "(the_real_green_giant|therealgreengiant|squoon|sqoonart)\+[^+]+@(hotmail\.com|hotmail\.co\.uk|live\.com|outlook\.com)" | tee res.deletes

And then removing just those from just this list:

for email in $(cat res.deletes); do echo /var/lib/mailman/bin/withlist -r discard_address resistanceinbrooklyn "$email"; done

comment:8 Changed 7 months ago by

I've re-started running the process to delete them all - but this time running under nice. It seems to take about 45 seconds for each address (and there are thousands of them).

comment:9 Changed 7 months ago by

I found a few references to this problem.

There was an old patch that was created.

And this whole thread is good.

I also just updated #11683 with a proposal for doing some preventative maintenance on inactive lists.

comment:10 Changed 4 months ago by

More problems. Now resistanceinbrooklyn is getting spammed with email in the form:

  • ryan+zlqqcw@…
  • ryan+zkjomz@…
  • ryan+ytlavae@…

It seems like someone is picking a fight with

I just added that pattern to the ban list:

/usr/lib/mailman/bin/withlist -a -r ban "^ryan\+[^+]"

comment:11 Changed 4 months ago by

I also wanted to add that we have a cron job that clears pending messages after 60 days, so manually clearing these is not necessary.

comment:12 Changed 4 months ago by

Bob reported today more fake requests.

comment:13 Changed 4 months ago by

I found them with:

./bin/list_requests  -l resistanceinbrooklyn
17 Resistanceinbrooklyn moderator request(s) waiting

Pending subscriptions: (twinu) Sun Jan  7 14:58:13 2018 (qtpwh) Sun Jan  7 17:17:38 2018 (pzvhvi) Sun Jan  7 17:20:51 2018 (vjr) Sun Jan  7 17:47:13 2018 (fxqb) Sun Jan  7 17:54:06 2018 (ydvi) Sun Jan  7 17:57:04 2018 (dfyyg) Sun Jan  7 19:35:49 2018 (skctsb) Sun Jan  7 20:33:36 2018 (usbjcay) Sun Jan  7 20:51:23 2018 (extdd) Sun Jan  7 21:49:50 2018 (ziuiskh) Sun Jan  7 21:55:13 2018 (xidqxm) Sun Jan  7 22:01:25 2018 (joh) Sun Jan  7 22:21:15 2018 (fyjt) Mon Jan  8 12:23:51 2018 (myjcfliy) Mon Jan  8 13:24:41 2018 (snijaovl) Mon Jan  8 13:35:12 2018 (year) Mon Jan  8 13:55:56 2018

And banned with:

/usr/lib/mailman/bin/withlist -a -r ban "^vetus\+[^+]+@mail\.gr"

comment:14 Changed 4 months ago by

I've been giving this some thought and wonder if there is a better way to protect ourselves against this kind of attack - specifically using postfwd at the postfix level.

The approach we are taking has some problems:

  • It is only applied against current lists (new lists created after today don't have the protection)
  • It has to be constantly updated when a slight variation in the email is used
  • It is hard to fix mistakes

comment:15 Changed 13 days ago by

I've just initiated a new ban with the following.

/usr/lib/mailman/bin/withlist -a -r ban "^neil\+[^+]+@neildeer\.com"

I'm now deleting pending subscriptions.

Also looking at this

comment:16 Changed 13 days ago by

So I think removing or rate limiting somehow the postfix aliases -admin-, -confirm-, -join-, -leave-, -request-, -subscribe-, -unsubscribe- and other commands somehow would be an ideal solution. Would that mean editing and maintaning our own /var/lib/mailman/bin/ ?

There is also the option of setting generic_nonmember_action to discard messages by default. I am not sure if that works for subscription requests as well. And unless I'm mistaken it would also mean admins get no notice when non members attempt to send any type of post or request.

comment:17 Changed 12 days ago by

I think you are on the right track.

I also think postfwd might be the appropriate way to manage this.

It's not installed on leslie/mailman but we should add it. (see /etc/postfix/ on a mosh to get an idea of how this works).

The nice part with postfwd is that I think we could differential between the use of those email addresses from people mailing from the outside in and email messages generated internally by mailman.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.