[Mailman-Users] Automated Subscription Bots Inundating List Owners With Subscription Requests

[Kalbfleisch, Gary]

Hi Stephen,

Thank you for your reply.  My responses are below


> -----Original Message-----
> From: Stephen J. Turnbull [mailto:stephen at xemacs.org]
> Sent: Friday, October 19, 2012 9:20 PM
> To: Kalbfleisch, Gary
> Cc: mailman-users at python.org
> Subject: [Mailman-Users] Automated Subscription Bots Inundating List
> Owners With Subscription Requests
> 
> > Kalbfleisch, Gary originally writes:
> 
>  > inundated with confirmation request messages, and you cannot delete
>  > them all at once on the "Tend to pending moderator requests"
>  > screen.  You have to select "Discard" for each of them
>  > individually.  I don't know if this has been changed yet.
>
> Stephen J. Turnbull writes:
> 
> As far as I can see, these are batchable (you only need to click
> "Submit" once -- version 2.1.15, but I doubt this has changed in many
> years).
> 
> Is your issue that the moderator has to tick each box?  I really don't
> think that should change; otherwise you would lose valid subscription
> requests when being attacked in this way.
> 
> Is the issue that lists get so many requests that it overflows the
> screen, and you can only do (say) 20 at once?
> 

Kalbfleisch, Gary responds:

Messages are batchable, but administrative tasks are not.  As you noted you must tick each box, and yes I'm talking pages and pages of bogus subscription requests.  Quite tedious.  I think these too should be batchable but perhaps separately.  What I would like to be able to do is to change all administrative messages to discard (or whatever) with one click, then go back and change the legitimate subscription requests back to accept.

>  > I had to block access to the web interface from off site at our
>  > router to stop the deluge of messages.
> 
> I think this is the best way to handle it.
> 
> There really ought to be a way for a host to request that a service be
> firewalled programmatically, although it would have to be designed
> *very* carefully.
> 

After analyzing the httpd logs I have identified three primary sources of the bogus subscription requests, the most predominant being associated with http://mailbait.info.  If you list admins out there are not familiar with mailbait.info you should check it out.  It is a service (I use that term loosely here) for filling up your inbox.  People submit hosts that send out email messages via web forms which are exploited for this purpose.  If you run it (and you can do this without filling in the email address field so you can see how it works) you will see that it skips from one Mailman site to another submitting bogus subscription requests.  As per the Mailbait FAQ, "MailBait does not condone using other people's email address with this service.", however they make no efforts to prevent it. 

You cannot filter on IP addresses because the source address is that of the person that runs it, not Mailbait itself.  I created an iptables filter that looks for the string "mailbait.info", which appears in the Referer field of most of the packets.   I investigated creating a filter utilizing the iptables "recent" directive, which filters on the number of consecutive hits per time period, but the hits are spread out between each host sufficiently to make this ineffective.  This is true for the other two sources (not associated with Mailbait)  I identified as well, which I traced to ISP DHCP ranges.

>  > I have seen this starting to occur at some other Mailman sites as
>  > well.  Anyone else seeing this or have any ideas about how best to
>  > handle this?  I have it under control for now but it is changing
>  > the way we use our lists.
> 
> Sadly, I don't see how that can be avoided.  The problem is the SMTP
> and HTTP protocols themselves, which have no easily used provision for
> authentication or authorization of clients.  (How many students do you
> know who walk around with a personal X.509 certificate?)
> 
> If you have suggestions for the admin interface, that would be very
> helpful.  Even if you don't have a lot of confidence in them, this is
> a hard problem that requires wild ideas.
> 

CAPTCHA for subscription requests would go a long way in preventing this type of exploitation.

Thank you,

-- Gary Kalbfleisch 
-- Director of Technology Support Services 
-- Shoreline Community College 
-- (206) 546-5813 
-- (206) 546-6943 Fax