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."
Not ultimately a solution (Score:5, Insightful)
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 [twistedmatrix.com] or something
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 (Score:4, Insightful)
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." (Score:1, Insightful)
Re:"High performance" , "perl" , sorry? (Score:2, Insightful)
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? (Score:3, Insightful)
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