On 12/14/12 12:52 PM, Mark Sapiro wrote:

The League CA Cities wrote:

...

some of my list are being spammed with bot subscription request. I am looking for a way to add a hidden field to the subscription page of each list that a bot would see but a human user will not.

I would like to have Mailman automatically drop any subscription request that has the hidden field fill out.

This is not a solution to the problem you face. What you want is a hidden field in the form that contains secret data the bot doesn't know. Then you reject the request if the form comes back without the secret.

Actually that is a well know method to stop many bots. They will crawl the web looking for subscription forms, and when they find one, fill it out. If you add a field to the form that humans with normal web browsers will not see, and thus not fill out, then a bot that is filling out most fields (as it might be a required field, and they don't want to make the effort to try to parse a reply back) will trip up and fill in the honeypot field.

Normally this is done by using CSS to hide the field, using the attribute display:none

For other types of bots, having a key on the page that is needed to be returned will help, as it will catch bots that "know" what the subscription form looks like and just go around trying to submit it. Even better is to give out different keys each time, and checking that the key isn't too old or too young (figuring a human will take at least a few seconds to fill out the form, but the bot won't be patient enough to do that).

-- Richard Damon

Mark Sapiro writes:

The asking of a question which requires an "obvious to a human but extremely difficult to a machine" answer is probably the best defence as long as the questions and answers aren't fixed over many Mailman installations.

That's a great idea, actually! How about a standard (but optional) feature for the subscription page like this:

*Please read the following description carefully. You will be* *tested on the content later. *

This is the mailman-users list.  It is used for communication
about the Mailman mailing list management software, primarily
among users, although developers often participate.

To subscribe

Your name: [                                                ]
Your email: [                                               ]

*Test question: *

• Do programmers of this package lurk here? (yes/no) [ ]*

Of course the "test question" would be list-owner configured, a la the "security question" for password recovery that is commonly implemented. The portions enclosed in stars would only be generated if the "test question" were non-blank.

The answer to the "test question" could be further obfuscated by placing it on a different page.

Steve

On 12/14/12 10:58 PM, Mark Sapiro wrote:

Richard Damon wrote:

...

For other types of bots, having a key on the page that is needed to be returned will help, as it will catch bots that "know" what the subscription form looks like and just go around trying to submit it. Even better is to give out different keys each time, and checking that the key isn't too old or too young (figuring a human will take at least a few seconds to fill out the form, but the bot won't be patient enough to do that).

Except for the "too young" part this is what is implemented by <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1371>. Too young could be a useful addition.

But, as Stephen points out, if the people who deploy these bots are really interested in "getting the job done", they will figure out all these tricks and deploy new bots that will succeed in spite of us.

The asking of a question which requires an "obvious to a human but extremely difficult to a machine" answer is probably the best defence as long as the questions and answers aren't fixed over many Mailman installations.

These methods are designed to repel "most" attacks. The basic idea is make it difficult enough to "beat the defense" that the spammer goes elsewhere. The idea is these bots are written to do as little processing as needed to find entry vectors. If you are step more difficult than most, then it isn't worth upgrading the bot to beating the defense, as the additional processing to get to you costs a lot more sites not checked.

Since the whole purpose of the subscription page is to allow an interested person to subscribe, it becomes very hard to totally block the spammer, as if they really want YOU, then the cost to have a person do it manually isn't that extremely high. The one thing the list owner has going is that it is unlikely that they are a big enough of a unique target to attract a dedicated spammer. What might be more of a issue would be a "hacktivist", but that is a totally different type of protection needed.

-- Richard Damon

Mark Sapiro writes:

The League CA Cities wrote:

...

some of my list are being spammed with bot subscription request. I am looking for a way to add a hidden field to the subscription page of each list that a bot would see but a human user will not.

I would like to have Mailman automatically drop any subscription request that has the hidden field fill out.

This is not a solution to the problem you face. What you want is a hidden field in the form that contains secret data the bot doesn't know. Then you reject the request if the form comes back without the secret.

This won't work if the 'bot is actually visiting the subscription page first; even a CSRF cookie (or any other one-time-key) will fail. This wouldn't be hard for spammers to implement at all. And of course anything you don't tell the 'bot will probably not be known.

Actually, all you want is a custom form requiring the user to enter some data that they won't know unless they actually understand the text of the form (aka CAPTCHA, but there's probably no need to vex your users with distorted images of text as long as it's not a standard Mailman feature). Something like

Tell me again, what list do you want to subscribe to? [ ]

would do.