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."

Comments

Not ultimately a solution

[frenetic3]

so they wrote an asynchronous proxy that slows down connections. cool trick, but not any kind of scalable solution.

the core assumption, and the only thing that makes this work, is that botnet spam software will _always_ just give up after 30 seconds; if this throttling technique ever became commonplace, spammers would just write their own asynchronous mailer -- it's not THAT hard. windows has the same kind of async networking support (either through the winsock API and/or IO completion ports, or what have you) and i'm sure the spam/botnet software authors have no qualms about holding open a couple thousand sockets on the rooted windows machine (times a few hundred thousand machines.) furthermore, i bet there are some shitty legitimate MTAs that would just give up too, causing actual mail to get discarded :)

(that, and they shoulda used twisted or something :) -- using a pool of apache/mod_perl instances to handle connections is grossly inefficient.)

ok, ok, maybe this sounds overly critical. it's a clever, thinking-out-of-the-box idea, but certainly not the panacea we're looking for to stop spam.

-fren

Re:Not ultimately a solution

[A beautiful mind]

It's an arms race. Graylisting, higher MX spam traps, etc.

They all rely on the "we only have to be better than the neighbour's mailserver" principle. Until everyone starts doing it these things work and then new methods get invented to combat spam. Not that suprising, but saying no to this approach is basically silly. There is NO good way to eliminate spam, because stupid people exist. So people hack around the problem.

Re:"... the easy way in Perl."

[Anonymous Coward]

He didn't say it couldn't be done, he said it was not easy with Perl. The language is entirely relevant to this assertion.

Re:"High performance" , "perl" , sorry?

[chromatic]

Remember kids, if your process is IO-bound, you want the fastest possible code ever to make sleeping on those system calls as efficient as possible!

Re:"High performance" , "perl" , sorry?

[angel'o'sphere]

You seem to have never used PERL? PERL is in most regards in a speed range of > 85% of C/C++. For the stuff PERL is optimzed for it is nearly at 95% of C++ with a FAR shorter development cycle.

At least your comment is the msot silliest I have ever seen. What will a mail filter/forwarder do 90% of its time? NOTHING, being blocked listening on a socket. It realyl does not matter if the listening process is written in assembler (granted, which is very portable from sparc to i386 to PowerPC) and jsut waits "faster" or is written in PERL ....

angel'o'sphere