On Sep 01, Eugen Leitl [[EMAIL PROTECTED]] wrote: > On Sun, 1 Sep 2002, Ken Weingold wrote: > > I've been noticing that one too. I'm not familiar with Vipul's or > > TMDA, but Spamassassin has a rule for when the From: and To: are the > > same. > > I think from the ISP mail server admin's point of view he should wish to > shift the CPU load to the end user. He has allready paid for the peer > traffic, and now he could at least doesn't pay for ridiculous amounts of > rackmount boxes.
If you're talking about me, I'm not an ISP admin. Corporate America all the way. :-/ Our end user CPU load is our CPU load. > > > [2] BTW, if you get a clever idea for a new spam blocking system, please > > > don't write it in perl. Anything that a serious mail server has to > > > run per every message damn well better be in C or better. > > > > Oh. :) > > I think the bottleneck is pattern matching. As such it doesn't matter, as > Perl's regexp stuff is highly optimized C. Considering that we aren't using any pattern matching, no. (Vipul's is checksumming + network query, the new bayesian methods are word-granular statistical analysis. I've also seen some that use perl as a wrapper to run various scanners written in other languages, with predictable results.) The problem is instantiating perl once (or more times, if using multiple checks) per every damn message. That isn't cheap. Solutions that use a daemon could write the daemon in perl and it would be less of a problem, provided the client that has to talk to the daemon isn't also perl.
msg30618/pgp00000.pgp
Description: PGP signature
