On 11 Sep 2007, at 05:15, Thomas Schulz wrote:
On 30 Aug 2007, at 16:55, Micke Andersson wrote:
Richard Hobbs wrote:
Hello,
To add information to this problem, it appears that spamd does
eventually give up after 5 minutes - which then bounces the
message back
to the sender stating:
421 SMTP incoming data timeout - message abandoned
Obviously, this cannot keep happening, but i don't know how to
stop it...
Any advice greatly appreciated.
Thanks again,
Richard.
Hi, I have had exactly the same problem as you, with about the very
same setup as you!
The problem where actually a TCP problem, and not a SpamAssassin
problem!
From a bunch of TCPDUMPs from my side and a good partner side, we
did finaly track down the problem to
TCP_WINDOW_SCALING, which is set to 1 (True) on Debian, which seems
to give a problem
to Exim. My solution for the problem was to set this parameter to 0
(false)
Easiest done by
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
And further on, this seems to be a problem mostly against old
versions of Sendmail, when they
where sending to us, and had some kind of attachment in the email
as well!
(I don't really know where the bug is, if it is in Exim or TCP, I
found a solution and is pleased with that)
Hope this helps you out, a bit of topic though!
This may have fixed the problem by simply severely reducing the data
transmission speed.
With window scaling off your maximum window size is a mere 64K,
hardly enough these days.
I have had this problem since upgrading to the latest SA.
But I had also at the same time taken the opportunity to add a load
of spam and ham to bayes.
It makes much more sense that spamd is trying to do a bayes expire
and taking too long.
sa-learn --force-expire took a good 4 minutes
Setting auto expire off as suggested in this thread has fixed the
problem for me.
THEREFORE
The actual problem must be that it is taking longer to do the bayes
expire than spamd's timeout child setting each new spamd child tries
to do a bayes expire but never has enough time to complete it.
Other wise one would expect just a single spamd to go 99% not every
spamd.
Right?
Perhaps the bayes auto expire code should be moved to the parent
process to prevent this problem.
If I remember correctly, in 3.2.x the logic was changed to have the
child
process the mail first and then do the expire. I don't know if
that would
have fixed your problem or not.
This problem is with 3.2.3
I noticed that there were always two spamd at 99% so perhaps two
processes try to do the expire simultaneously and block ?
Setting bayes auto expire to 0 in local.cf has fixed the problem.
Tom Schulz
Applied Dynamics Intl.
[EMAIL PROTECTED]
