Sam, can you make it an option if possible please? i.e. Default = current
behaviour, but can be changed if really needed?

It's just that I suspect your method is probably the best and most sensible
for 99% of situations.

Faris.

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:spamdyke-users-
> [EMAIL PROTECTED] On Behalf Of Sam Clippinger
> Sent: 07 February 2008 15:15
> To: spamdyke users
> Subject: Re: [spamdyke-users] Spamdyke passes partial emails to
> qmailafter timeout
> 
> 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


_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to