Slashdot Mirror
Asynchronous Programming for Spam Elimination
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."
The article is correct - mail servers do not mind waiting a few minutes/hours/days to deliver their mail. Unfortunately, end-users do mind. The inherent delays for just about every message would be particularly painful for business email users, but even residential ISP customers are constantly opening tickets when they observe a delay (I work closely with several large ISPs, which is how I know).
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.
It evolves, which is even more amusing to me.
Did you consider some event-driven thing using POE?
-- Ed Avis ed@membled.com