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 
  To: spamdyke users 
  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]>
  > > To: "spamdyke users" <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
  > > > > 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
  > > 
  > _______________________________________________
  > 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
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to