Re: Debbugs and spam
In article <[🔎] 41E7360A.8010700@azure.humbug.org.au> aj@azure.humbug.org.au writes:
>Looks like we've gotten to the point where we get so much spam that
>spamscan can't cope with it as fast as it's coming in.
No, other than a problem with spamassassin getting hung processing
certain broken spams recently. (I need to check if it exists in the
unstable version and report it still, I'm busy with non-debian stuff
at the moment.)
>I think we need
>to start doing stuff about that; but that implies changing the way the
>BTS behaves; eg, not accepting mail that's not authenticated in some
>way, and not showing the full contents of bug reports to web browsers
>that aren't authenticated in some way.
Rewriting spamscan to be multi-threaded seems the next logical step to
me. Unfortunatly made even tricker by some of the code I've added
recently.
>Certainly I prefer that to the alternatives, which seem to be randomly
>dropping huge chunks of mail and discouraging users from submitting
>bugs, or just plain closing down the BTS; but no doubt lots of people
>will be utterly disgusted by the idea...
Killing the spamscan process was enogh to get it to get going again,
and once the broken messages were out of the queue it had no problem
catching up.
If someone with more procmail experience with me can write a filter
for them we can avoid it. (Perl rejex is easy, but procmail doesn't
do the perl extantions.)
--
Blars Blarson blarson@blars.org
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
Reply to: