I don’t like spammers. At all. In fact, as some may know, I have the dubious distinction of being the original spam fighter.
Spam has come a long way since then, but it’s still a tactic reserved to the lowest category of exploitive, thieving vermin. And we still deal with our share of spam issues at NearlyFreeSpeech.NET.
Every now and then, a spammer finds one of our members’ sites that has an exploitable PHP mail() form. When this happens, the result is always the same: 50,000 – 150,000 junk mail messages flood into our system destined for all eight corners of the world (half of them bounce).
That clogs up our whole email system, and because our network is distributed it often takes us awhile to figure out what’s going on. Meanwhile, our email systems are pretty fast so they are more than happy to pump out several hundred junk mail messages every second until we pull the plug. I don’t care how fast your reaction time is, that’s way too many.
To combat this, we’ve introduced two new features: a default rate limit (20 email messages per minute per site) and a point-based queuing system for mail. Each site has a “bank” of email sending points. Your site earns one point each minute, up to a maximum of 100. When the site sends a message via PHP, it will deduct a point from the bank. If it hits zero, email will go into a queue until more points are available. (So not to worry, nothing legitimate will be lost even if you send out a lot of email at once. At the worst, it’ll get slowed down a bit.)
If a sizable queue forms, we will see it and be able to respond before the bulk of the junk gets unleashed on the world. If we check it out, and it’s legitimate, we can pass it right through. If it’s not… it never gets off the launch pad. This is adaptable on an per-site basis, so people running mailing lists and other high-volume or “bursty” senders won’t be affected. (Sites that do send large volumes of email tend not to get exploited anyway.)
We’ve added a line to the site info panel showing the current/maximum email bank values and the number of messages currently queued to send, if any.
Right now, this does not affect CGI scripts that send mail via sendmail. Such scripts represent a small fraction of email sent, exploits targeting them are even more rare, and they are pretty easy for us to catch manually. Even so, we will be backfilling that in the future to provide complete protection.
We fight a constant battle to keep the handful of spammers, scammers, and fraudsters at bay without restricting what our huge majority of perfectly legitimate users are able to do. We’ve had to make some tough compromises to stop spammers, like blocking email from the ssh server to stop spammers from setting up free trial accounts and using them to spew garbage. That’s why it’s nice to have a solution like this that kicks the bad guys right where it hurts without impacting the members we care about.
Sorry, the comment form is closed at this time.