On 09/17/2015 11:38 AM, Robert Sparks wrote:

If anyone has a mitigation strategy that's working well, please let me know.

I think much of this has appeared earlier in this thread, but we have seen large volumes of these at mail.python.org. These have all been web subscribes, and in spite of the fact that we have enabled the SUBSCRIBE_FORM_SECRET feature which requires that the web subscribe POST data contain a token which requires that it be a submission of a form retrieved at least SUBSCRIBE_FORM_MIN_TIME (default 5 seconds) and no more than FORM_LIFETIME (default 1 hour) earlier, the bots were sometimes slow enough that even when I increased SUBSCRIBE_FORM_MIN_TIME to 8 seconds, many subscribe requests still succeeded.

I then implemented a GLOBAL_BAN_LIST to supplement the individual, per list ban_list. We have been using the regexp

^.*\+.*\d{3,}@

in the GLOBAL_BAN_LIST and this is effective so far. Note that this could just as well be '^.*\+.*\d{3}@'. It is what it is because it evolved from '^.*\+\d{3,}@' after we saw a few of the form 'some.words+more-words123456@gmail.com' type addresses.

Note that since these are web subscribes and the address is banned, there is no backscatter. There is just a 'address is banned' notation on the web response.

For those interested, the GLOBAL_BAN_LIST implementation is at <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1574>.

Also, there is a withlist script at <https://www.msapiro.net/scripts/add_banned.py> (mirrored at <http://fog.ccsf.edu/~msapiro/scripts/add_banned.py>) which can be used to add an address or pattern to the ban_list if all lists in lieu of implementing a GLOBAL_BAN_LIST.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan