Asynchronous Programming for Spam Elimination 63
ttul writes "Stas Bekman (formerly the maintainer of mod_perl) has been quietly building an asynchronous programming framework to build high performance network applications in Perl. His recent Perl.com article describes how he has used the Event::Lib module (that lives on top of the popular libevent library) to write a traffic-shaping email proxy to get rid of spam. Asynchronous programming is challenging at the best of times. Read on to find out how to do it the easy way in Perl."
Clever, but... (Score:2, Interesting)
Delays aside, I just can't buy into network-layer rate limiting when it comes to email. The metric for anti-spam success is measured in "messages" (or more accurately, "recipients"). Nobody ever calls their local email admin to say, "hey, I've received 1.3 megabytes of spam this week, what gives?"; instead, the problem is always quantified by the number of individual messages the end user had to look at and consider before deciding what to do.
Because of this, rate-limiting should be done per-recipient. That way, there's no question what a particular sender is going to get through. Once they pass the limit you've specified for their class of IP (known mail server, dynamic IP, etc) during whatever timeframe, they receive an SMTP 4xx error until that timeframe is up. That still slows them down, but you can't get around it with smaller messages, etc.
Re:oblig. checklist :) (Score:3, Interesting)
Re:As if PERL wasn't hard enough to read... (Score:2, Interesting)