If I'm correct, you like Kami, are also using IMail 8 to pre-process your E-mail? If so, that would explain the discrepancy. The longer the window that the message sits in the original spool, the more likely the queue will steal it or a copy of it.
Matt
John Tolmachoff (Lists) wrote:
Matthew, I have confirmed that this occurred on my server 4 times on Thursday. That works out to 1/10 of 1%. A lot more than your figure. Like I stated before, this is a concern as it let a virus through.
John Tolmachoff Engineer/Consultant/Owner eServices For You
-----Original Message----- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Saturday, December 06, 2003 4:40 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action
I did some math related to my machine assuming 1/5 of a second window for this bug to appear, and on 5,000 E-mails a day, and 24 runs of the queue. I figured that on average, this would only happen once every 360 days. It's actually quite remarkable that this was caught, and I can see why this bug has been around for so long without being detected.
I figure that each individual E-mail on my system has about a 0.00006% chance of being stolen and delivered by the queue. I'm not very worried considering, however, Ipswitch should certainly move to take care of their problem.
Matt
R. Scott Perry wrote:
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
--- [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.
