Just to follow myself up, it looks like "spamc -t 30" means if spamd doesn't return in 30sec, spamc will simply output the email to stdout and exit. spamd carries on processing the email and I can see the final spamd syslog report when it finishes in >30sec. Unfortunately we re-invoke spamc and it just goes through the same problem again :-( It's a pity spamd can't keep a small cache of checksum'ed previous messages and their scores, so that if it sees the same message again within (say) 10-30 min, it just throws up the cached score?
Jason On 09/08/2009 01:50 PM, Jason Haar wrote: > Hi there > > We're having problems with a particular class of email. >400K in size, > text-only. spamd takes 40-80sec to process it, and spamc is set with a > 30sec timeout. The long processing time isn't network-related: it's > all those "body" searches that are causing the hang. > > Obviously there are several things that could be done. Increase spamc > timeout or reduce the limit of the maxsize handed off to spamc. > However, they are both already non-default for good reasons, so I'd > rather not fiddle with them for such a corner-case. > > So are there any other options? Allowing spamd to only scan the first > 50KB of text attachments would do the trick. I can't think of a way > that could be misused by spammers? (ie they aren't going to send > text-spam where the first 50KB is "bayes killer" and the final bit is > the spam - potential customers won't scroll past the first couple of > screens to find the spam). Or a spamd-based "max-runtime" setting? > -- > Cheers > > Jason Haar > Information Security Manager, Trimble Navigation Ltd. > Phone: +64 3 9635 377 Fax: +64 3 9635 417 > PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
