I hade customers which got emails again and again in spamdyke version prior to 3.1.4. The maximum timeout I have been setting was 600. Whitelisting didn't help.
Version 3.1.4 of spamdyke fixed this behaviour for me. Maybe because of the changes of sendrecv in release 3.1.4? On 06 Feb 08, Chris Robinson wrote: > Maybe I didn't express myself properly. Spamdyke was timeing out the > connection perfectly correctly because the client was inactive for more than > 60 seconds which was spamdyke's default idle timeout. So the client's > Outlook sees the disconnection and retries, often resulting in another > partial copy of the same message. That is why I've probably fixed it by > setting "idle-timeout-secs=1200", which should handle even the slowest > clients. > > But it's not the cause, it's the effect that concerns me. The partial > message received before the disconnection (e.g. 50 Kb of a 200Kb email) has > been piped to qmail-smtpd which then actually delivers it. How could > qmail-smtpd deliver a message that has not been properly terminated? Does > spamdyke simply close the pipe to qmail-smtpd, as would happen if > qmail-smtpd were connected directly to the client and qmail-smtpd initiated > the timeout? > > Somehow a fundamental principle of SMTP MTAs is being breached, namely that > an incomplete session will never result in delivery, local or remote, of a > partial message. > > My details: > > xinetd.d > --------- > server = /var/qmail/bin/tcp-env > server_args = -Rt0 /usr/local/bin/spamdyke -f > /usr/np/mail/spamdyke/spamdyke.conf /var/qmail/bin/qmail-smtpdauth > /var/qmail/bin/checkpassword /bin/true > > Clamav and Spamassassin are only run after qmail-local pipes it to procmail > via the .qmail file, so they can't be affecting the issue. Of course neither > of those programs are run when the recipient is remote and qmail-remote > handles it. But even remote recipients are receiving multiple, partial > copies of the same message > > Cheers and thanks for the response, > Chris Robinson > > ----- Original Message ----- > From: "Sam Clippinger" <[EMAIL PROTECTED]> > To: "spamdyke users" <[email protected]> > Sent: Wednesday, February 06, 2008 18:11 > Subject: Re: [spamdyke-users] Spamdyke passes partial emails to qmail after > timeout > > > > Most likely, this is a virus/spam filter issue. Some qmail > > installations pass the incoming email to Spamassassin or ClamAV before > > acknowledging the delivery. When that happens, spamdyke's idle timeout > > can trigger a disconnection if the scanner takes too long (this is > > common for large attachments). > > > > The best way to be sure is to enable full logging (with "full-log-dir") > > and examine the logs for disconnected deliveries. The log will contain > > timestamps that will show long each response was delayed. > > > > Of course, it's also possible you've found a bug. :) In that case, I'll > > need to find a way to reproduce it, so I may need you to (privately) > > send me a few full logs along with details of your spamdyke configuration. > > > > -- Sam Clippinger > > > > Chris Robinson wrote: > > > Hi Everyone, > > > > > > I run mail servers for about 30 companies (qmail /spamdyke 3.1.0 / > Fedora > > > 2.4.21) and started experiencing a problem whereby some users complained > > > that they could send an email and it was received by the recipient > corrupted > > > multiple times in varying sizes until eventually the final version would > > > arrive correct in full. To cut a long story short I eventually tracked > it > > > down from a string in a user's Outlook log "Talk faster next time". A > google > > > revealed all. It wasn't coming from qmail but from spamdyke, which > explained > > > why I couldn't grep it in the qmail source. > > > > > > I've probably fixed it by setting "idle-timeout-secs=1200". But what > worries > > > me is why the recipient got anything except the final good email. If > > > spamdyke issues that 421 error then breaks the connection, the user's > > > Outlook can justifiably assume that the email won't have been accepted > by > > > the server, nor sent to the recipient. But what seems to happen is that > the > > > part that has been received down the pipe so far has been passed by > spamdyke > > > to qmail-smtpd which has passed it to qmail-queue and thence to the > local or > > > remote recipient. Surely no "250 OK 123 qp 456" has come out of qmail? > > > > > > Is this a spamdyke issue or a qmail issue? > > > > > > Cheers, > > > Chris Robinson > > > > > > > > > > > > _______________________________________________ > > > spamdyke-users mailing list > > > [email protected] > > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > _______________________________________________ > > spamdyke-users mailing list > > [email protected] > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
