> 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. Tom Schulz Applied Dynamics Intl. [EMAIL PROTECTED]
