Subject: pkg/33654: mail/exim -- spamd timeout to low since 4.50
To: None <,,>
From: Andreas Hallmann,,, <>
List: pkgsrc-bugs
Date: 06/06/2006 13:40:01
>Number:         33654
>Category:       pkg
>Synopsis:       mail/exim -- spamd timeout to low since 4.50
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 06 13:40:00 +0000 2006
>Originator:     Andreas Hallmann
>Release:        NetBSD 3.0_STABLE
System: NetBSD moshus 3.0_STABLE NetBSD 3.0_STABLE (AHASS5) #10: Fri May 26 12:48:08 CEST 2006 root@kukalda:/export/work/build.objs/v8/3.0/export/netbsd/netbsd-3-0/src/sys/arch/sparc/compile/AHASS5 sparc
Architecture: sparc
Machine: sparc
In latest exim releases, support for spamd was improved a lot.
In that corse, spamd timeout was decreased from 3600 seconds to 120 seconds.
This is a bit short on slow machines for very long mails ( near the 80k border).
So happens that without any need, mails where temporarily rejected which
can lead to some kind of starvation. I.e. Mails with long processing time 
get resend over and over again to bounce at the end (after a 3-7 days?)

	Get a slow gateway machine and send in a long but less than 80k patch.
	Get a fast gateway with a lot parallel spamd processes, take it off net
	for a while. Then in all wating mail streams in, 
	watch for rejections due to spamd timeaouts. 
	Add the following patch (with documentation) to patches:

---------------------------------------- snip -------------------------------
In the move from exim 4.44 to 4.50 the handling of spamassassins spamd was modified.
It is a large improvement. Exim has started to protect itself from spamd anomalies.

Unfortunately the timeout waiting for spamassassin to complete has droped from 3600 seconds
to 120 seconds. So my good old Sparc Station 2 has faced tought timing constraints.
Others with more parallel spamd's on heavy loaded sites are reporting same problems.  

I will suggest relaxing it to 240 secs. Which leave resonable headroom for exim to complete
within the 300 secs smtp timeout spec, for an smtp session to complete.
This more or less seams to be the consensus on exim list.

But if the same host has to do virus checking, well then the remaining 60 secs are to short.

It would be better to make it an exim config file option, in the long run. 
Since I believe this will be done --- this patch should give heavy loaded or small mail gates
more headroom in the meantime. Hey, we have to get mail in, didn't we?

--- ./src/spam.h.orig	2005-10-04 10:55:28.000000000 +0200
+++ ./src/spam.h
@@ -12,7 +12,7 @@
 /* timeout for reading and writing spamd */
-#define SPAMD_TIMEOUT 120
+#define SPAMD_TIMEOUT 240
 /* maximum length of the spam bar */
 #define MAX_SPAM_BAR_CHARS 50
----------------------------------- snip ---------------------------------------------------