The clamav problem shouldn't be coming into play, as I had already upgraded to clamav-0.92.1 before installing spamdyke. Thanks for the reminder about that though.
FWIW, the server in question is a PII/266/512 (try not to laugh too hard). It's load average is typically 0.2 or less though. Sam Clippinger wrote: > The issue where timed-out messages are delivered anyway will be fixed in > version 4.0.0. > > I don't see how ClamAV could be causing Eric's timeouts but again, since > I don't (yet) understand what's happening, it's worth a shot. Keeping > ClamAV up to date is always a good idea, whether any problems are > occurring or not. Generally speaking, a slow/unresponsive qmail (or > other child process) can cause an idle timeout in spamdyke 3.1.7 -- I've > fixed this in the next version. > > -- Sam Clippinger > > Bruce Schreiber wrote: >> Michael, >> >> I had the exact same symptom with multiple users. The problem turned >> out to be in ClamAV. There is a DOS exploit in ClamAV that is solved >> with an upgrade to 0.91 or later. (see >> http://xforce.iss.net/xforce/xfdb/35367) Upgrading ClamAV solved the >> problem for the most part. >> >> I agree that the symptom is disturbing. If the mail client is being >> sent a message indicating that the message failed, then it should not >> be sent by Qmail. I believe this is a Spamdyke bug. Spamdyke is >> terminating the client session, but is failing to stop Qmail from >> sending the email. Outlook exacerbates this problem by automatically >> retrying the failed message, without notifying the user. I had one >> customer complain that a message was sent 170 times. Customers eyes >> glaze over when you try to explain why it happened. >> >> Sam, I would appreciate your thoughts on this. >> >> Bruce >> >> >> >> Michael Colvin wrote: >>> Doing this, kind of negates the need for doing it in SpamDyke, except >>> for maybe a "Backup" in case Qmail doesn't for some reason. >>> >>> I think the problem is, some people don't have a timeoutsmtpd file. >>> I had a "Stock" Qmailrocks install that did not have it, and >>> apparently, the "Default" value used by Qmail if that file is missing >>> is 1200 seconds (20 minutes), which of course is kind of ridiculous. >>> So, with even a modest value in SpamDyke of 300 >>> seconds, SpamDyke would occassionally timeout a connection, and in >>> some cases, I think because of the way SpamDyke disconnected the >>> session, the sending server didn't realize the message had been >>> sent. I belive it is discusses in this thread: >>> >>> http://www.mail-archive.com/spamdyke-users@spamdyke.org/msg00746.html >>> >>> >>> >>> >>> **Michael J. Colvin** >>> >>> **NorCal Internet Services** >>> >>> **//www.norcalisp.com// <http://www.norcalisp.com/>** >>> >>> >>> >>> <http://www.norcalisp.com/> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] *On Behalf Of *Paulo >>> Henrique >>> *Sent:* Sunday, April 27, 2008 6:18 PM >>> *To:* spamdyke users >>> *Subject:* Re: [spamdyke-users] Timeout problem >>> >>> I had a problem like this and decided putting the timeout from >>> qmail less than the timeout from spamdyke, see: >>> >>> cat /var/qmail/control/timeoutsmtpd >>> 240 >>> grep idle-timeout-secs /var/qmail/control/spamdyke/spamdyke.conf >>> idle-timeout-secs = 300 >>> >>> >>> >>> After that never had problem with the repetition of messages. >>> >>> 2008/4/22 Eric Shubert <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: >>> >>> I had a problem receiving a particular email message. It >>> would always send >>> the same amount of data, then timeout. The same amount of >>> data was >>> sent/received with timeouts of 60 and 180 seconds. >>> >>> I logged the message (great little feature of spamdyke btw), >>> and the end >>> part of the message log always shows: >>> <HR align="left" SIZE=1 color=black> >>> <div align="left"><font face="arial" >>> size="1">14072172</font></div></td></tr></TBODY></TABLE> >>> </BODY></HTML> >>> >>> FF> 04/22/2008 17:11:13 >>> . >>> QUIT >>> >>> <FF 04/22/2008 17:11:13 >>> 421 Timeout. Talk faster next time. >>> >>> <XX 04/22/2008 17:11:33 >>> 250 ok 1208909493 qp 11949 >>> 221 doris.shubes.net <http://doris.shubes.net> - Welcome to >>> Qmail Toaster Ver. 1.3 SMTP Server >>> >>> 04/22/2008 17:11:33 CLOSED >>> >>> >>> Here's the smtp log for the successful receipt (with no >>> spamdyke): >>> 04-22 17:21:13 tcpserver: pid 12162 from 208.46.47.130 >>> <http://208.46.47.130> >>> 04-22 17:21:13 tcpserver: ok 12162 doris:192.168.71.11:25 >>> <http://192.168.71.11:25> :208.46.47.130::51303 >>> 04-22 17:21:13 CHKUSER accepted sender: from >>> <[EMAIL PROTECTED]::> remote >>> <rapport.mysurvey.com:unknown:208.46.47.130 >>> <http://208.46.47.130>> rcpt <> : sender accepted >>> 04-22 17:21:13 CHKUSER accepted rcpt: from >>> <[EMAIL PROTECTED]::> remote >>> <rapport.mysurvey.com:unknown:208.46.47.130 >>> <http://208.46.47.130>> rcpt <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> : >>> found existing recipient >>> 04-22 17:21:34 simscan:[12162]:CLEAN >>> (-6.20/99.00):20.2626s:April Edition of >>> MySurvey.com Opinion >>> Matters:208.46.47.130:[EMAIL PROTECTED]:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>: >>> 04-22 17:21:34 tcpserver: end 12162 status 0 >>> >>> >>> After receiving the entire message, I see this portion that >>> was received >>> after the part logged by spamdyke: >>> <IMG >>> >>> SRC="https://www.mysurvey.com/gems/gems_open_tracking.cfm?indid=14072172&cmpid=1105&r=1720290&rundate=22-APR-2008+11%3a52%3a55&z=67129618CF0844A786F0E0A6C20C49CD >>> >>> <https://www.mysurvey.com/gems/gems_open_tracking.cfm?indid=14072172&cmpid=1105&r=1720290&rundate=22-APR-2008+11%3a52%3a55&z=67129618CF0844A786F0E0A6C20C49CD>"border="0" >>> width="1" height="1"> >>> >>> ------=_Layout_Part_DC7E1BB5_1105_4DB3_BAE3_2A6208EB099A-- >>> >>> >>> Any idea why this would timeout (consistently, like >>> clockwork) with >>> spamdyke, but not without it? This message timed out all day >>> long with >>> spamdyke, but was received successfully on the first attempt >>> without >>> spamdyke. Did spamdyke somehow choke on the last bit? >>> >>> FWIW, it appears that the entire email was a bit hosed, as >>> the html did not >>> render properly in the client view (mac mail) once the entire >>> message was >>> received. >>> >>> -- >>> -Eric 'shubes' >>> _______________________________________________ >>> spamdyke-users mailing list >>> spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org> >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>> >>> >>> >>> >>> -- >>> Paulo Henrique Fonseca >>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> spamdyke-users mailing list >>> spamdyke-users@spamdyke.org >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>> >> ___ >> >> .mdEmail and .mdSecureIM allow tramsmission of PHI in compliance with HIPAA. >> Each is included when you register a .md Domain Name. >> http://www.max.md/register.php?affid=footer1 >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> spamdyke-users mailing list >> spamdyke-users@spamdyke.org >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> > _______________________________________________ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
