On 10/25/06 9:23 AM, "Peter J. Holzer" <[EMAIL PROTECTED]> wrote:
> On 2006-10-25 07:22:02 -0500, Peter Eisch wrote: ... >> I came at the problem from users getting multiple copies of email. After >> tracking the problem it was clear that client had gone away at some point >> during the scan. The queuing unfortunately still took place. While one >> spamd spun out of control, other incoming would get delivered multiple >> times. The sending MTA would simply retry later. If spamd chewed for an >> hour on an email and eventually returned, the mail was queued to the >> recipient. The resulting 250 Queued would be written to a dead socket. The >> recipient would then receive that email multiple times. These were >> typically larger email but small enough to be scanned. > > Yep. RFC 2821 says that the client should wait at least 10 minutes after > the terminating "." for the reply from the server. Unfortunately some > clients aren't that patient. So it is clearly desirable to keep the time > for scanning and queueing a message short. > This is good info -- I figured that there probably was a defined standard but I hadn't been able to locate it in an RFC. > If your system is mostly idle, but scanning of a few messages takes a > long time (maybe because of slow DNS lookups), returning an early > temporary error may help. > I hate to bring up signals or timers running in forked processes, but maybe at a minimum I should change my logic to assume the 10 minute milestone. > But that wasn't the case I was thinking of: I was thinking of the case > where the average time to scan a mail approaches the average time > between mails. In this case, returning a 45x error while spamd is still > scanning the mail, makes the problem worse: Spamd will continue to scan > the mail (AFAIK there is no way to abort it), thus delaying the scanning > of other mails. So when the client retries, scanning will take even > longer than before, so it won't be queued, but adds additional load, so > scanning gets even slower ... you get the picture. > Yes. Once the message is off to spamd, I haven't been able to kill it. I can close my read socket and ignore the eventual outcome but spamd kept running. Oddly, this parallels the exact behavior in the topic of this thread. > >> It would be best there were a way to "ping" the sending MTA to ensure that >> if you continue on to queue the message that it will be there to receive the >> confirmation that the message was queued. > > It may be possible to do that with a (non-blocking) read. But I don't > think this is reliable: If the client gets impatient and sends a QUIT > before disconnecting, that doesn't work, because the QUIT is still "in > the queue", so EOF hasn't been reached yet. > > I don't know if you can determine whether the socket is still writable > without actually writing to it. If that works it should be more reliable - > you still have a race condition, but the critical time is much shorter. > Does a select() on a socket testing write reflect the lower level session status? This is probably the question. I run under Apache, so it might take me a bit to figure this out -- perl.apache.org appears to be down right now. peter
