I was wrong - I *do* have idle-timeout-secs specified as 60. I'll go ahead and bump it up just above my timoutsmtpd value, and we'll see what happens.
Sam Clippinger wrote: > I would be very interested to know if that solves your problem, Eric. I > can't see why it would, but since I don't (yet) understand what's wrong, > I can't rule anything out. :) > > Looking through the logs you gave me, I can't see why the timeout is > being triggered at all. The remote server is sending data constantly, > so the idle timer should be reset multiple times per second. I think it > may have something to do with the exact composition of the message -- > it's possible that there's a bug in the way spamdyke manipulates its > buffers to hold and move data (version 3.1.6 fixed a problem like > this). At the moment, I'm trying to reconstruct the message that's > triggering this bug on Eric's server so I can reproduce this error > myself. I haven't had any success triggering this bug by using just any > large message. > > -- Sam Clippinger > > Eric Shubert wrote: >> That's interesting, Paulo. I have timeoutsmtpd at 600, and nothing specified >> for idle-timeout-secs. Sam's having a look at a couple of my logs. I'll be >> glad to try this out if Sam gives me the word (I don't want to mess up his >> debugging efforts). I wonder if idle-timeout-secs is somehow not being >> initialized/defaulted properly. >> >> Thanks for the input Paulo. >> >> Paulo Henrique wrote: >> >>> 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 -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
