On Wed, Jan 12, 2005 at 03:42:02PM +0100, Santiago Vila wrote: > On Tue, 11 Jan 2005, Blars Blarson wrote: > > If you want to analyze the spam getting through and make spamassassin > > rules that would catch it and not non-spam messages that would be > > useful. > > That's exactly the point: There is already a spamassassin rule for razor. > But everything it has been told about razor is "latency issues". > > May I know what's the nature or severity of the latency problem razor > has that made it to be rejected for use in bugs.debian.org? > > Is it that it adds more latency to the one from the DNS checks or is > it that it has too much latency by itself?
When we enabled network checks in spamassassin, the result was that mail was being processed more slowly than it was arriving. Therefore, we turned off network checks. The machine is not overloaded; much of the problem is that we currently run spamassassin serially (which in turn was faster than just having procmail fork-bomb the machine with spamassassin processes as floods of mail arrived ...). A patch to scripts/spamscan (in debbugs CVS) to allow it to process multiple messages in parallel would be welcome. > In the former case: Michael Tokarev told me about a tool he is writing > which is something like the rblcheck program, but does DNS queries in > parallel. Could a tool like that help to make possible to re-introduce > razor in the spamassassin chain? That sounds like it would help. Has he looked at adns, which should solve much of the problem for him? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
