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]> > > 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 > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
