Scott, I take it you are passing this information on to them? Or do you want me to forward to them under the incident I have open?
John Tolmachoff Engineer/Consultant/Owner eServices For You > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of R. Scott Perry > Sent: Saturday, December 06, 2003 8:33 AM > To: [EMAIL PROTECTED] > Subject: RE: [Declude.JunkMail] Declude not taking action > > > >We've already tracked it down about as far as it can go. IMail's process > >that handles the queue run is processing E-mails between the time that > >they are saved to the hard drive (or unlocked) by the SMTPD process and > >the time that Declude is able to re-lock the files. > > > >We are trying to think of possible workarounds. However, since this is > >happening at a time that Declude isn't even running, it gets very tricky. > > Unfortunately, it looks like there isn't much that we can do here. There > are some measures we could take that would help to some extent, but not > enough to significantly reduce the problem. > > In testing here on a server at 100% CPU usage, it could take over a full > second from the time that SMTPD32.exe unlocked the Q*.SMD file (to be > technical, renamed the T*.SMD file to Q*.SMD) until the time that > Declude.exe was fully loaded (versus about 50ms at 0% CPU). Normally, the > time to start a process isn't a problem -- almost all of that 1 second of > time is being used by other processes. But there is a delay of about 1 > second where there isn't any chance for Declude to lock the Q*.SMD > file. During this time, the file is vulnerable to being stolen by queue > management. > > On a server with 86,400 E-mails/day (to make math easier, that's 1 per > second), a server with 0% CPU and a 30-minute queue timer would have 48 > queue runs in a day, with about a 5% chance that any given queue run would > steal an unprocessed E-mail. At that rate, you aren't likely to notice > any > unprocessed E-mails. But at 100% CPU usage, there's nearly a 100% chance > that any queue run will steal at least one unprocessed E-mail. > > The good news, though, is that this should be very easy for Ipswitch to > fix. Specifically, the function that they use to determine if there are > any Q*.SMD files waiting to be re-tried includes the time that the file > was > created. They can check to see if it is less than 10 minutes old; if so, > they can skip that file. Since 10 minutes is the minimum amount of time > between queue runs, E-mail that was received in the past 10 minutes does > not need to be re-tried. If they are worried that it would take up to 20 > minutes for an E-mail to be re-tried for the first time when the queue > timer was set to 10 minutes, they could make the check for 1 minute > (giving > Declude ample time to start, and ensuring that first re-tries are done > within 11 minutes). > > -Scott > --- > Declude JunkMail: The advanced anti-spam solution for IMail mailservers. > Declude Virus: Catches known viruses and is the leader in mailserver > vulnerability detection. > Find out what you've been missing: Ask about our free 30-day evaluation. > > --- > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.com)] > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
