Justin Mason wrote: >> FWIW, though, SpamAssassin 2.6x has a very sophisticated DNSBL lookup >> algorithm which (a) runs all queries in parallel and (b) aborts ones >> that are taking significantly longer than the others, reducing problems >> if one or two hosts go down. So nowadays this should be *more* efficient >> run from SpamAssassin than from the MTA.
Jason Haar <[EMAIL PROTECTED]> writes: > I don't doubt it. But that means spamc hangs around for up to 10 seconds > awaiting a response on a system that runs "spamd -m XX" - i.e. XX max > processes. It's more like 3 seconds when some DNSBL are timing out, not 10. Sometimes, the MX checking tests can be slow, but you can turn those off independently of the DNSBL (RBL)tests. > If you ran RBL checks out on the SMTP server, then you may be > inefficient, but at least that 25K SMTP process is dealing with it > rather than a 28M spamd process... You realize that fork() in Linux (and BSD too, I'm sure) doesn't copy every page? 28M virtual size != the actual additional memory used by a spamd process. Nevermind the fact that most DNSBLs aren't accurate enough as outright reject/blocks. SpamAssassin is much more accurate than MTA blacklists. Daniel -- Daniel Quinlan anti-spam (SpamAssassin), Linux, http://www.pathname.com/~quinlan/ and open source consulting
