The changes to sendrecv aren't related to this -- sendrecv is a program I wrote only for testing spamdyke (as part of the testing scripts). It isn't involved in spamdyke's operation at all. The changes to sendrecv in 3.1.4 were needed because spamdyke was corrupting the SSL handshake. sendrecv contained a matching bug that covered the corruption and allowed the SSL handshake to proceed correctly.
You're seeing this behavior because when spamdyke disconnects a remote client due to a timeout (either idle timeout or maximum connection time), it sends a terminating dot and a "QUIT" command to qmail. This was a judgement call on my part -- I felt that it was better to close qmail correctly and deliver whatever data had been sent than to potentially lose it if the client didn't retry. Not all clients correctly handle errors during/after the DATA command. I also assumed qmail already behaved this way, though I didn't test it. If that assumption is wrong and this is causing problems, I can easily change it. -- Sam Clippinger Chris Robinson wrote: > Thanks Hartmut, > > I think you may be right about the sendrecv changes, specially if the > child process somehow closed the connection to qmail in a way that > satisfied qmail-smtpd. Could it be that the child was actually sending > the SMTP terminating dot without receiving it from the departed client? > > Whatever. > > Chris > > ----- Original Message ----- > *From:* Andreas <mailto:[EMAIL PROTECTED]> > *To:* spamdyke users <mailto:spamdyke-users@spamdyke.org> > *Sent:* Thursday, February 07, 2008 14:15 > *Subject:* Re: [spamdyke-users] Spamdyke passes partial emails to > qmailafter timeout > > Hi Hartmut, > > I had the same phenomen on 1 of my qmail-servers as long as I had a > nameserver related problem. > I had up to 750 processes of spamdyke. > I had to reboot the server to get rid of those processes, just killing > them was not enough, they immediately reappeared. > Sind my nemserver works properly I have, on the same machine, just 10-20 > processes of spamdyke and it works fine now. > My spamdyke- version is 3.15. > Bye > > Andreas > Am Donnerstag, den 07.02.2008, 08:36 +0100 schrieb Hartmut Wernisch: > > 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] <mailto:[EMAIL PROTECTED]>> > > > To: "spamdyke users" <spamdyke-users@spamdyke.org > <mailto:spamdyke-users@spamdyke.org>> > > > 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 > > > > > spamdyke-users@spamdyke.org > <mailto:spamdyke-users@spamdyke.org> > > > > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > _______________________________________________ > > > > spamdyke-users mailing list > > > > spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org> > > > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > > > > > > > _______________________________________________ > > > spamdyke-users mailing list > > > spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org> > > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > > _______________________________________________ > > spamdyke-users mailing list > > spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org> > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > _______________________________________________ > spamdyke-users mailing list > spamdyke-users@spamdyke.org <mailto: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 _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
