RE: [Declude.JunkMail] Declude not taking action
Hi; Some common observations about Declude not seeing emails: - Last night I personally had 2 emails that were not seen by Declude and 4 were in the Admin mailbox. At least these are the ones that I have seen. Of all of these none have the IMail spam headers. - In our configuration we do all the IP4r tests in IMail and add header for Declude to analyze. It is as if IMail never added the headers.. Since none are there. Could it be that IMail somehow skips its own spam test? Should we not expect if IMail has done all that it was to do the headers from its spam test would show up? Why are they absent? - Our system is also setup to delete emails that fail 13+ tests by IMail and not even bother Declude with it. - Matt: We are doing address verification. I will disable it and see if that can help. I have found this to be a very valid test and I know it is resource intensive. I will disable it. - Declude's action for all these emails should have been delete. Based on the conditions that are present in all of these emails none should have made it since they have email addresses in the CC field that are listed in our delete filter if found in the recipients. May be if we try to present the common factors of the ones that are being skipped we can find what is causing it. I know for sure we are getting 5+ a day.. Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Sunday, December 07, 2003 7:37 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action Kami Razvan wrote: I have spent a lot of my years in the field of mathematics. A study done a while back and it is related to data-mining stated.. men buy baby diapers and orange juice on Tuesdays more than any other day of the week. Sure it's useful, what it says is that there is something else going on here at least on your system. It could be possible that this can happen during the entire duration of processing the queue instead of the instant where it is initiated. It could be related to using some of IMail 8's filters before handing off to Declude, for instance the address verification which can produce delays of many seconds and make your window much wider. And of course the frequency of running your spool and your processor load can affect this, though to a smaller degree than your experience suggests. Matt --- [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.
Re: [Declude.JunkMail] Declude not taking action
Kami, I believe that what you are getting at is a very likely explanation for this. I had never seen this before the other day, and it seems that most of the reports are coming from IMail 8 users who are using IMail to run tests before Declude gets the message. I figure that my system's window is only about 1/5 of a second, but if IMail is doing address verification, this could be as much as a minute (based on previous discussions). That would make this 300 times more frequent on your system than it would be on mine with other things being equal. The good news I guess is that if it is skipping IMail's tests also, and the delays in processing some things like address verification are as long as indicated, IMail will want to see fit to fix this quickly, at least in version 8. I really don't want to upgrade, so lets hope for my sake and many others that they fix it in version 7 as well. This is a major flaw in their process. I'm guessing that the totality of your IMail filtering might be something to look at instead of just that one test. I would imagine that it could take up to 2 seconds for all of the DNS-based tests to be run. The fact that you see so many of these and I have only seen one suggests strongly that the delay itself with IMail 8 is the reason. I certainly would have caught this many other times in my own inbox considering the volume that gets sent to it. Matt Kami Razvan wrote: Hi; Some common observations about Declude not seeing emails: - Last night I personally had 2 emails that were not seen by Declude and 4 were in the Admin mailbox. At least these are the ones that I have seen. Of all of these none have the IMail spam headers. - In our configuration we do all the IP4r tests in IMail and add header for Declude to analyze. It is as if IMail never added the headers.. Since none are there. Could it be that IMail somehow skips its own spam test? Should we not expect if IMail has done all that it was to do the headers from its spam test would show up? Why are they absent? - Our system is also setup to delete emails that fail 13+ tests by IMail and not even bother Declude with it. - Matt: We are doing address verification. I will disable it and see if that can help. I have found this to be a very valid test and I know it is resource intensive. I will disable it. - Declude's action for all these emails should have been delete. Based on the conditions that are present in all of these emails none should have made it since they have email addresses in the CC field that are listed in our delete filter if found in the recipients. May be if we try to present the common factors of the ones that are being skipped we can find what is causing it. I know for sure we are getting 5+ a day.. Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Sunday, December 07, 2003 7:37 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action Kami Razvan wrote: I have spent a lot of my years in the field of mathematics. A study done a while back and it is related to data-mining stated.. men buy baby diapers and orange juice on Tuesdays more than any other day of the week. Sure it's useful, what it says is that there is something else going on here at least on your system. It could be possible that this can happen during the entire duration of processing the queue instead of the instant where it is initiated. It could be related to using some of IMail 8's filters before handing off to Declude, for instance the address verification which can produce delays of many seconds and make your window much wider. And of course the frequency of running your spool and your processor load can affect this, though to a smaller degree than your experience suggests. Matt --- [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.
Re: [Declude.JunkMail] Declude not taking action
John, 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.6% 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.
Re: [Declude.JunkMail] Declude not taking action
Dave, IMail delivered a copy to Declude that was deleted, but IMail also delivered a copy directly to me without processing it with Declude. There were two copies of this message as a result of the queue being run at this particular instant in time. The copy that was delivered without being scanned by Declude did not have any Declude headers in it. IMail writes the file to the disk and there is a delay between then and when it gets handed off to Declude in which the queue might be run. If the queue gets run during that window, IMail will deliver it without it being scanned. I would imagine that depending on the instant, Declude may or may not also get a copy for processing. You can set up IMail rules to catch this stuff, at least if it is going to a local sender (not sure about gatewayed domains). Just set up a rule for does not contain some piece of header code that Declude inserts, and have those messages forwarded to a particular account. I'm not sure that there is any way to set up rules for gatewayed domains, but if someone knows how to make this work, maybe it would help some of the others by sharing it. Matt Dave Marchette wrote: Gotcha. But do the headers of the copy that Imail delivered\stole have any Declude markings in the header? -Original Message- From: Matthew Bramble [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 4:42 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action Dave, It appears that the E-mail getting delivered improperly is the result of IMail stealing a copy and processing it apart from Declude. In the example that I provided, Declude deleted the copy that it got because it scored too high, but IMail delivered a copy before it was scanned by Declude. Matt Dave Marchette wrote: Apologies if this has already been mentioned, but this may be a quick easy way to find out exactly what messages(and quantity of messages) never got scanned by Declude on a per server basis: If you have Declude configured to add anything consistent to the headers, like an x-note: or whatever else, you can use the 'copy all mail to a box' feature of Imail, then write a processing rule on the copy box to delete all mail in the copy box that has the x-note: data from Declude header. Then, you can periodically check that box to see how many are being missed, because the only mail that will end up in that box will be mail that Declude never tried to scan. There are perhaps other ways to use domain proc rules to do this as well but this would be my preferred method. --- [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.
RE: [Declude.JunkMail] Declude not taking action
Dave Marchette wrote: Gotcha. But do the headers of the copy that Imail delivered\stole have any Declude markings in the header? === Hi again.. This is another one I just noticed. Received: from 69.0.99.172.adsl.snet.net [69.0.99.172] by foroosh.com (SMTPD32-8.04) id AA7C17D40132; Mon, 08 Dec 2003 02:38:36 -0500 Received: from [165.62.147.14] by 69.0.99.172.adsl.snet.net SMTP id 4m09B17hhW88aw for [EMAIL PROTECTED]; Sun, 07 Dec 2003 12:30:11 -0700 Message-ID: [EMAIL PROTECTED] From: Joni Bates [EMAIL PROTECTED] Reply-To: Joni Bates [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: *** 10+ emails listed here of all X-employees*** Subject: Fwd: Best source for medicines online jye lepfu ce rzdu Date: Sun, 07 Dec 03 12:30:11 GMT X-Mailer: PIPEX NetMail 2.2.0-pre13 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=.2551F.7.97CEE2ADB.D X-Priority: 5 X-MSMail-Priority: Low X-RCPT-TO: [EMAIL PROTECTED] Status: U X-UIDL: 360625989 == As you see.. No Imail headers are listed. There is also no Declude headers. Regards, Kami --- [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.
RE: [Declude.JunkMail] Declude not taking action
- In our configuration we do all the IP4r tests in IMail and add header for Declude to analyze. It is as if IMail never added the headers.. Since none are there. Could it be that IMail somehow skips its own spam test? Should we not expect if IMail has done all that it was to do the headers from its spam test would show up? Why are they absent? It sounds like the bug is hitting IMail, too. I'd actually call that a double-bug, if it is really true. The problem here seems to be that IMail's SMTPD process is unlocking the E-mail, but then leaving it unlocked while it runs the spam tests! That's the first bug -- it is supposed to lock the file. The next bug is the even more serious one, that allows the queue manager to send out E-mail that hasn't been fully processed yet. May be if we try to present the common factors of the ones that are being skipped we can find what is causing it. I know for sure we are getting 5+ a day.. It looks like you've found the common factor. We're going to do some testing here, but for some reason the IMail v8 anti-spam on our test server doesn't seem to be working. -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.
RE: [Declude.JunkMail] Declude not taking action
FYI, I have a support incident open with Ipswitch on this issue and have passed on others information posted here. Here is there response this morning: John, We're looking into it a bit further, I've passed the info to RD for some further insight. Thanks for your patience. 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: Monday, December 08, 2003 5:03 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action - In our configuration we do all the IP4r tests in IMail and add header for Declude to analyze. It is as if IMail never added the headers.. Since none are there. Could it be that IMail somehow skips its own spam test? Should we not expect if IMail has done all that it was to do the headers from its spam test would show up? Why are they absent? It sounds like the bug is hitting IMail, too. I'd actually call that a double-bug, if it is really true. The problem here seems to be that IMail's SMTPD process is unlocking the E-mail, but then leaving it unlocked while it runs the spam tests! That's the first bug -- it is supposed to lock the file. The next bug is the even more serious one, that allows the queue manager to send out E-mail that hasn't been fully processed yet. May be if we try to present the common factors of the ones that are being skipped we can find what is causing it. I know for sure we are getting 5+ a day.. It looks like you've found the common factor. We're going to do some testing here, but for some reason the IMail v8 anti-spam on our test server doesn't seem to be working. -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.
RE: [Declude.JunkMail] Declude not taking action
I figure that each individual E-mail on my system has about a 0.6% chance of being stolen and delivered by the queue. Matt: I have spent a lot of my years in the field of mathematics. A study done a while back and it is related to data-mining stated.. men buy baby diapers and orange juice on Tuesdays more than any other day of the week. While it sounds interesting it is real hard to make any use of it. :) -- I am either very lucky or the 0.6% is only concentrating itself to my mailbox. On our very small volume server I got 2 last night and that is only me - others are probably getting it and not letting us know. Attached is an email that IMail added its headers but Declude never saw. I get about 2-3 daily. Regards, Kami ---BeginMessage--- Title: brakeman piocr The Digital Power Filter works on 99% of Digital Cable Boxes. Simple to hook up, it will be giving you the Viewing pleasure that you want right away. http://www.ulikeit.biz/promo.php?id=93827 exclude http://www.ulikeit.biz/remove.php?id=93827 ---End Message---
RE: [Declude.JunkMail] Declude not taking action
Apologies if this has already been mentioned, but this may be a quick easy way to find out exactly what messages(and quantity of messages) never got scanned by Declude on a per server basis: If you have Declude configured to add anything consistent to the headers, like an x-note: or whatever else, you can use the 'copy all mail to a box' feature of Imail, then write a processing rule on the copy box to delete all mail in the copy box that has the x-note: data from Declude header. Then, you can periodically check that box to see how many are being missed, because the only mail that will end up in that box will be mail that Declude never tried to scan. There are perhaps other ways to use domain proc rules to do this as well but this would be my preferred method. -Original Message- From: Kami Razvan [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 1:35 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action I figure that each individual E-mail on my system has about a 0.6% chance of being stolen and delivered by the queue. Matt: I have spent a lot of my years in the field of mathematics. A study done a while back and it is related to data-mining stated.. men buy baby diapers and orange juice on Tuesdays more than any other day of the week. While it sounds interesting it is real hard to make any use of it. :) -- I am either very lucky or the 0.6% is only concentrating itself to my mailbox. On our very small volume server I got 2 last night and that is only me - others are probably getting it and not letting us know. Attached is an email that IMail added its headers but Declude never saw. I get about 2-3 daily. Regards, Kami --- [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.
Re: [Declude.JunkMail] Declude not taking action
Not related to your problem but do yourself a favor block @mcsi.net only thing I ever seen from there is spam. Best regards, Eje Aya Gustafsson mailto:[EMAIL PROTECTED] The Family Entertainment Network http://www.fament.com Phone : 620-231- Fax : 240-376-7272 - Your Full Time Professionals - Online Store http://www.wisp-router.com/ MikroTik, Star-OS, PACWireless, EnGenius, RF Industries -- KR I figure that each individual E-mail on my system has about a 0.6% KR chance of being stolen and delivered by the queue. KR Matt: KR I have spent a lot of my years in the field of mathematics. A study done a KR while back and it is related to data-mining stated.. men buy baby diapers KR and orange juice on Tuesdays more than any other day of the week. KR While it sounds interesting it is real hard to make any use of it. :) -- I KR am either very lucky or the 0.6% is only concentrating itself to my KR mailbox. KR On our very small volume server I got 2 last night and that is only me - KR others are probably getting it and not letting us know. KR Attached is an email that IMail added its headers but Declude never saw. KR I get about 2-3 daily. KR Regards, KR Kami -- [This E-mail scanned for viruses by Declude Virus] --- [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.
Re: [Declude.JunkMail] Declude not taking action
Kami Razvan wrote: I have spent a lot of my years in the field of mathematics. A study done a while back and it is related to data-mining stated.. men buy baby diapers and orange juice on Tuesdays more than any other day of the week. Sure it's useful, what it says is that there is something else going on here at least on your system. It could be possible that this can happen during the entire duration of processing the queue instead of the instant where it is initiated. It could be related to using some of IMail 8's filters before handing off to Declude, for instance the address verification which can produce delays of many seconds and make your window much wider. And of course the frequency of running your spool and your processor load can affect this, though to a smaller degree than your experience suggests. Matt --- [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.
Re: [Declude.JunkMail] Declude not taking action
Dave, It appears that the E-mail getting delivered improperly is the result of IMail stealing a copy and processing it apart from Declude. In the example that I provided, Declude deleted the copy that it got because it scored too high, but IMail delivered a copy before it was scanned by Declude. Matt Dave Marchette wrote: Apologies if this has already been mentioned, but this may be a quick easy way to find out exactly what messages(and quantity of messages) never got scanned by Declude on a per server basis: If you have Declude configured to add anything consistent to the headers, like an x-note: or whatever else, you can use the 'copy all mail to a box' feature of Imail, then write a processing rule on the copy box to delete all mail in the copy box that has the x-note: data from Declude header. Then, you can periodically check that box to see how many are being missed, because the only mail that will end up in that box will be mail that Declude never tried to scan. There are perhaps other ways to use domain proc rules to do this as well but this would be my preferred method. --- [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.
RE: [Declude.JunkMail] Declude not taking action
Gotcha. But do the headers of the copy that Imail delivered\stole have any Declude markings in the header? -Original Message- From: Matthew Bramble [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 4:42 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action Dave, It appears that the E-mail getting delivered improperly is the result of IMail stealing a copy and processing it apart from Declude. In the example that I provided, Declude deleted the copy that it got because it scored too high, but IMail delivered a copy before it was scanned by Declude. Matt Dave Marchette wrote: Apologies if this has already been mentioned, but this may be a quick easy way to find out exactly what messages(and quantity of messages) never got scanned by Declude on a per server basis: If you have Declude configured to add anything consistent to the headers, like an x-note: or whatever else, you can use the 'copy all mail to a box' feature of Imail, then write a processing rule on the copy box to delete all mail in the copy box that has the x-note: data from Declude header. Then, you can periodically check that box to see how many are being missed, because the only mail that will end up in that box will be mail that Declude never tried to scan. There are perhaps other ways to use domain proc rules to do this as well but this would be my preferred method. --- [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.
RE: [Declude.JunkMail] Declude not taking action
There is only one Q file per message. If Declude locks it, Imail can do nothing with it. In the cases I have seen, there is a line in the log stating could not lock file. John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Sunday, December 07, 2003 4:42 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action Dave, It appears that the E-mail getting delivered improperly is the result of IMail stealing a copy and processing it apart from Declude. In the example that I provided, Declude deleted the copy that it got because it scored too high, but IMail delivered a copy before it was scanned by Declude. Matt Dave Marchette wrote: Apologies if this has already been mentioned, but this may be a quick easy way to find out exactly what messages(and quantity of messages) never got scanned by Declude on a per server basis: If you have Declude configured to add anything consistent to the headers, like an x-note: or whatever else, you can use the 'copy all mail to a box' feature of Imail, then write a processing rule on the copy box to delete all mail in the copy box that has the x-note: data from Declude header. Then, you can periodically check that box to see how many are being missed, because the only mail that will end up in that box will be mail that Declude never tried to scan. There are perhaps other ways to use domain proc rules to do this as well but this would be my preferred method. --- [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.
RE: [Declude.JunkMail] Declude not taking action
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.6% 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. --- [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.
RE: [Declude.JunkMail] Declude not taking action
Scott, since my own server only gets about 4000 messages per day, is there any testing or logging I can do that will help track this down? John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, December 05, 2003 10:51 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action This issue has really gotten my attention since one of the 0.1% of messages not scanned happened to have a virus attachment and caused a bit of ruckus with the client got it and demanded to know why he is paying me money to scan messages and then a virus got through. (Fortunately, I am adamant at making sure there is current AV on each computer, so that caught it.) John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, December 05, 2003 8:25 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action, IMail 7.15 H2 with Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Well, I was really hoping it would have been a Declude problem...that way it probably would have been fixed in days as opposed to requiring me to get an upgrade to IMail 8 for them to fix the issue. I'm going to reduce my queue from running every 15 minutes to every hour just to lessen the possibility of this happening. Please keep us posted if you hear anything. I imagine it will take them a while and IMail 7 users may be out in the dark. Matt R. Scott Perry wrote: This is the first time that I have ever seen this and it occurred just a few days after upgrading from 1.75i6 to 1.76i28-30. Unlike some others that I have noted in the past, I am using IMail 7.15 Hotfix 2, so it doesn't seem related to IMail 8. This is getting scary. It looks like there is a serious bug in IMail v7 and v8 that is just starting to be discovered: --- IMail Log --- 20031205 184256 127.0.0.1 SMTPD (046101B0) [208.7.179.15] connect 64.119.217.36 port 41441 20031205 184258 127.0.0.1 SMTPD (queue run) 13471 1 69 20031205 184258 127.0.0.1 SMTPD (046101B0) [64.119.217.36] E:\spool\D1800046101b02123.SMD 1332 20031205 184258 127.0.0.1 SMTP (3696) processing E:\spool\Q1800046101b02123.SMD 12/05/2003 18:43:02 Q1800046101b02123 Scanned: Virus Free [MIME: 1 765] 12/05/2003 18:43:04 Q1800046101b02123 Msg failed DELETE (Weight of 80 reaches or exceeds the limit of 30.). Action=DELETE. This is the same pattern that we tracked in another E-mail: [1] IMail's SMTPD process starts receiving the E-mail. [2] IMail starts a queue run to deliver E-mail in the spool [3] IMail's SMTPD process saves the E-mail to the hard drive [4] IMail's queue run delivers the E-mail [5] IMail's SMTPD process starts Declude [6] IMail tries to deliver the E-mail that Declude scanned Ipswitch has been notified that there is a problem here; hopefully, they will take care of it. -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. --- [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.
RE: [Declude.JunkMail] Declude not taking action
This issue has really gotten my attention since one of the 0.1% of messages not scanned happened to have a virus attachment and caused a bit of ruckus with the client got it and demanded to know why he is paying me money to scan messages and then a virus got through. (Fortunately, I am adamant at making sure there is current AV on each computer, so that caught it.) John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, December 05, 2003 8:25 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action, IMail 7.15 H2 with Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Well, I was really hoping it would have been a Declude problem...that way it probably would have been fixed in days as opposed to requiring me to get an upgrade to IMail 8 for them to fix the issue. I'm going to reduce my queue from running every 15 minutes to every hour just to lessen the possibility of this happening. Please keep us posted if you hear anything. I imagine it will take them a while and IMail 7 users may be out in the dark. Matt R. Scott Perry wrote: This is the first time that I have ever seen this and it occurred just a few days after upgrading from 1.75i6 to 1.76i28-30. Unlike some others that I have noted in the past, I am using IMail 7.15 Hotfix 2, so it doesn't seem related to IMail 8. This is getting scary. It looks like there is a serious bug in IMail v7 and v8 that is just starting to be discovered: --- IMail Log --- 20031205 184256 127.0.0.1 SMTPD (046101B0) [208.7.179.15] connect 64.119.217.36 port 41441 20031205 184258 127.0.0.1 SMTPD (queue run) 13471 1 69 20031205 184258 127.0.0.1 SMTPD (046101B0) [64.119.217.36] E:\spool\D1800046101b02123.SMD 1332 20031205 184258 127.0.0.1 SMTP (3696) processing E:\spool\Q1800046101b02123.SMD 12/05/2003 18:43:02 Q1800046101b02123 Scanned: Virus Free [MIME: 1 765] 12/05/2003 18:43:04 Q1800046101b02123 Msg failed DELETE (Weight of 80 reaches or exceeds the limit of 30.). Action=DELETE. This is the same pattern that we tracked in another E-mail: [1] IMail's SMTPD process starts receiving the E-mail. [2] IMail starts a queue run to deliver E-mail in the spool [3] IMail's SMTPD process saves the E-mail to the hard drive [4] IMail's queue run delivers the E-mail [5] IMail's SMTPD process starts Declude [6] IMail tries to deliver the E-mail that Declude scanned Ipswitch has been notified that there is a problem here; hopefully, they will take care of it. -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. --- [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.
RE: [Declude.JunkMail] Declude not taking action
One more thing, is there a way (Bill) of (1st) comparing the c:\declude.log for unique IDs to say the virus log for unique ID and (2nd) list those found in declude.log but not in the virus log? Then we could take those and find all the log lines for those and see if they are were delivered by Imail right as a queue run happened. When Queue Manager makes a timed run, does it look at all Q files, or those over a certain age or what? John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, December 05, 2003 10:58 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action Scott, since my own server only gets about 4000 messages per day, is there any testing or logging I can do that will help track this down? John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, December 05, 2003 10:51 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action This issue has really gotten my attention since one of the 0.1% of messages not scanned happened to have a virus attachment and caused a bit of ruckus with the client got it and demanded to know why he is paying me money to scan messages and then a virus got through. (Fortunately, I am adamant at making sure there is current AV on each computer, so that caught it.) John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, December 05, 2003 8:25 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action, IMail 7.15 H2 with Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Well, I was really hoping it would have been a Declude problem...that way it probably would have been fixed in days as opposed to requiring me to get an upgrade to IMail 8 for them to fix the issue. I'm going to reduce my queue from running every 15 minutes to every hour just to lessen the possibility of this happening. Please keep us posted if you hear anything. I imagine it will take them a while and IMail 7 users may be out in the dark. Matt R. Scott Perry wrote: This is the first time that I have ever seen this and it occurred just a few days after upgrading from 1.75i6 to 1.76i28-30. Unlike some others that I have noted in the past, I am using IMail 7.15 Hotfix 2, so it doesn't seem related to IMail 8. This is getting scary. It looks like there is a serious bug in IMail v7 and v8 that is just starting to be discovered: --- IMail Log --- 20031205 184256 127.0.0.1 SMTPD (046101B0) [208.7.179.15] connect 64.119.217.36 port 41441 20031205 184258 127.0.0.1 SMTPD (queue run) 13471 1 69 20031205 184258 127.0.0.1 SMTPD (046101B0) [64.119.217.36] E:\spool\D1800046101b02123.SMD 1332 20031205 184258 127.0.0.1 SMTP (3696) processing E:\spool\Q1800046101b02123.SMD 12/05/2003 18:43:02 Q1800046101b02123 Scanned: Virus Free [MIME: 1 765] 12/05/2003 18:43:04 Q1800046101b02123 Msg failed DELETE (Weight of 80 reaches or exceeds the limit of 30.). Action=DELETE. This is the same pattern that we tracked in another E-mail: [1] IMail's SMTPD process starts receiving the E-mail. [2] IMail starts a queue run to deliver E-mail in the spool [3] IMail's SMTPD process saves the E-mail to the hard drive [4] IMail's queue run delivers the E-mail [5] IMail's SMTPD process starts Declude [6] IMail tries to deliver the E-mail that Declude scanned Ipswitch has been notified that there is a problem here; hopefully, they will take care of it. -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. --- [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
RE: [Declude.JunkMail] Declude not taking action
Scott, since my own server only gets about 4000 messages per day, is there any testing or logging I can do that will help track this down? 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. -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.
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.
RE: [Declude.JunkMail] Declude not taking action
In the mean time, until Ipswitch fixes this, is it safe to assume that the chance incident of failure can be reduced by some percentage by utilizing a monstrously overrated processor for a given volume of mail? -- Processor power up, chance of failure down, perhaps dramatically? -Original Message- From: R. Scott Perry [mailto:[EMAIL PROTECTED] 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.
RE: [Declude.JunkMail] Declude not taking action
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.
RE: [Declude.JunkMail] Declude not taking action
In the mean time, until Ipswitch fixes this, is it safe to assume that the chance incident of failure can be reduced by some percentage by utilizing a monstrously overrated processor for a given volume of mail? -- Processor power up, chance of failure down, perhaps dramatically? Yes. The ways to minimize the chances of this happening are to increase the delay between queue runs (the default is 30 minutes), lower the CPU usage (by increasing the CPU power or finding ways of reducing the CPU load), or reducing the number of E-mails processed per day. On a typical server with 30 minute queue runs, there is about a 0.003% chance of any given E-mail being usurped like this. So it is very rare, but when you are dealing with 10,000s or 100,000s of E-mails per day, it will happen. We are still investigating to see if there are ways that we are minimize the delay, until Ipswitch is able to take care of the problem. -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.
RE: [Declude.JunkMail] Declude not taking action
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? Anyone who is having this problem is welcome to forward the information to Ipswitch. Ipswitch doesn't have an official line of communication with developers, and this is the type of problem that they will likely need to hear from customers about before fixing (unless we do enough testing to show them exactly what may happen to their customers who are not running Declude). -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.
RE: [Declude.JunkMail] Declude not taking action
One more note: This is the last report from our server: LocalDeliver1119 RemoteDeliver493 We get about 5+ of these emails a day that is not caught. Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Saturday, December 06, 2003 1:02 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action In the mean time, until Ipswitch fixes this, is it safe to assume that the chance incident of failure can be reduced by some percentage by utilizing a monstrously overrated processor for a given volume of mail? -- Processor power up, chance of failure down, perhaps dramatically? Yes. The ways to minimize the chances of this happening are to increase the delay between queue runs (the default is 30 minutes), lower the CPU usage (by increasing the CPU power or finding ways of reducing the CPU load), or reducing the number of E-mails processed per day. On a typical server with 30 minute queue runs, there is about a 0.003% chance of any given E-mail being usurped like this. So it is very rare, but when you are dealing with 10,000s or 100,000s of E-mails per day, it will happen. We are still investigating to see if there are ways that we are minimize the delay, until Ipswitch is able to take care of the problem. -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.
RE: [Declude.JunkMail] Declude not taking action
Scott .. I am not sure about this.. Our server load is quite small... Maximum 2000 emails a day. Our server is a Compaq quad 550 MHz and about 1.2 GB or RAM. One just can't expect to need more power for such a small volume of email? Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Saturday, December 06, 2003 1:02 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action In the mean time, until Ipswitch fixes this, is it safe to assume that the chance incident of failure can be reduced by some percentage by utilizing a monstrously overrated processor for a given volume of mail? -- Processor power up, chance of failure down, perhaps dramatically? Yes. The ways to minimize the chances of this happening are to increase the delay between queue runs (the default is 30 minutes), lower the CPU usage (by increasing the CPU power or finding ways of reducing the CPU load), or reducing the number of E-mails processed per day. On a typical server with 30 minute queue runs, there is about a 0.003% chance of any given E-mail being usurped like this. So it is very rare, but when you are dealing with 10,000s or 100,000s of E-mails per day, it will happen. We are still investigating to see if there are ways that we are minimize the delay, until Ipswitch is able to take care of the problem. -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.
RE: [Declude.JunkMail] Declude not taking action
I am not sure about this.. Our server load is quite small... Maximum 2000 emails a day. Our server is a Compaq quad 550 MHz and about 1.2 GB or RAM. One just can't expect to need more power for such a small volume of email? I'm not saying that you should increase the CPU power of the server -- it will *not* fix the problem. It will just help minimize it. Doubling the CPU power would have the effect of roughly halving the number of E-mails this problem occurs with. In your case, though, unless you have high CPU usage for some reason during the times that this occurs, you should rarely see it happen (perhaps once a week, not several times a day). -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.
RE: [Declude.JunkMail] Declude not taking action
Although this is not the same issue as Declude not getting called, I did want to bring it to everyones attention. For those of you that Store and Forward to other email servers, Imail 8.04 is having issues with removing body text from emails on the smtp rdeliver action to a remote server. I have tested it numerous times and have been able to reproduce it. Ipswitch is aware of it and acknowledges an issue and their dev. team is working to fix it. Keith winmail.dat
RE: [Declude.JunkMail] Declude not taking action
Keith, Thanks. I hadn't seen it but I'll be on the lookout now. George -Original Message- From: Keith Johnson [mailto:[EMAIL PROTECTED] On Behalf Of Keith Johnson Sent: Saturday, December 06, 2003 2:10 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action Although this is not the same issue as Declude not getting called, I did want to bring it to everyones attention. For those of you that Store and Forward to other email servers, Imail 8.04 is having issues with removing body text from emails on the smtp rdeliver action to a remote server. I have tested it numerous times and have been able to reproduce it. Ipswitch is aware of it and acknowledges an issue and their dev. team is working to fix it. Keith attachment: winmail.dat
Re: [Declude.JunkMail] Declude not taking action
John, yes, this can be done. But, if you are running the latest beta, nothing will be written to the declude.log file. However, if you are still running one of the latest pre-beta interim releases, and still want to track this, let me know and I will send you a script. Bill - Original Message - From: John Tolmachoff (Lists) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 05, 2003 11:05 PM Subject: RE: [Declude.JunkMail] Declude not taking action One more thing, is there a way (Bill) of (1st) comparing the c:\declude.log for unique IDs to say the virus log for unique ID and (2nd) list those found in declude.log but not in the virus log? Then we could take those and find all the log lines for those and see if they are were delivered by Imail right as a queue run happened. When Queue Manager makes a timed run, does it look at all Q files, or those over a certain age or what? John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, December 05, 2003 10:58 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action Scott, since my own server only gets about 4000 messages per day, is there any testing or logging I can do that will help track this down? John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, December 05, 2003 10:51 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action This issue has really gotten my attention since one of the 0.1% of messages not scanned happened to have a virus attachment and caused a bit of ruckus with the client got it and demanded to know why he is paying me money to scan messages and then a virus got through. (Fortunately, I am adamant at making sure there is current AV on each computer, so that caught it.) John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, December 05, 2003 8:25 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action, IMail 7.15 H2 with Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Well, I was really hoping it would have been a Declude problem...that way it probably would have been fixed in days as opposed to requiring me to get an upgrade to IMail 8 for them to fix the issue. I'm going to reduce my queue from running every 15 minutes to every hour just to lessen the possibility of this happening. Please keep us posted if you hear anything. I imagine it will take them a while and IMail 7 users may be out in the dark. Matt R. Scott Perry wrote: This is the first time that I have ever seen this and it occurred just a few days after upgrading from 1.75i6 to 1.76i28-30. Unlike some others that I have noted in the past, I am using IMail 7.15 Hotfix 2, so it doesn't seem related to IMail 8. This is getting scary. It looks like there is a serious bug in IMail v7 and v8 that is just starting to be discovered: --- IMail Log --- 20031205 184256 127.0.0.1 SMTPD (046101B0) [208.7.179.15] connect 64.119.217.36 port 41441 20031205 184258 127.0.0.1 SMTPD (queue run) 13471 1 69 20031205 184258 127.0.0.1 SMTPD (046101B0) [64.119.217.36] E:\spool\D1800046101b02123.SMD 1332 20031205 184258 127.0.0.1 SMTP (3696) processing E:\spool\Q1800046101b02123.SMD 12/05/2003 18:43:02 Q1800046101b02123 Scanned: Virus Free [MIME: 1 765] 12/05/2003 18:43:04 Q1800046101b02123 Msg failed DELETE (Weight of 80 reaches or exceeds the limit of 30.). Action=DELETE. This is the same pattern that we tracked in another E-mail: [1] IMail's SMTPD process starts receiving the E-mail. [2] IMail starts a queue run to deliver E-mail in the spool [3] IMail's SMTPD process saves the E-mail to the hard drive [4] IMail's queue run delivers the E-mail [5] IMail's SMTPD process starts Declude [6] IMail tries to deliver the E-mail that Declude scanned Ipswitch has been notified that there is a problem here; hopefully, they will take care of it. -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
RE: [Declude.JunkMail] Declude not taking action
If it will help Ipswitch decide to fix it... John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Bill Landry Sent: Saturday, December 06, 2003 12:35 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action John, yes, this can be done. But, if you are running the latest beta, nothing will be written to the declude.log file. However, if you are still running one of the latest pre-beta interim releases, and still want to track this, let me know and I will send you a script. Bill - Original Message - From: John Tolmachoff (Lists) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 05, 2003 11:05 PM Subject: RE: [Declude.JunkMail] Declude not taking action One more thing, is there a way (Bill) of (1st) comparing the c:\declude.log for unique IDs to say the virus log for unique ID and (2nd) list those found in declude.log but not in the virus log? Then we could take those and find all the log lines for those and see if they are were delivered by Imail right as a queue run happened. When Queue Manager makes a timed run, does it look at all Q files, or those over a certain age or what? John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, December 05, 2003 10:58 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action Scott, since my own server only gets about 4000 messages per day, is there any testing or logging I can do that will help track this down? John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, December 05, 2003 10:51 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Declude not taking action This issue has really gotten my attention since one of the 0.1% of messages not scanned happened to have a virus attachment and caused a bit of ruckus with the client got it and demanded to know why he is paying me money to scan messages and then a virus got through. (Fortunately, I am adamant at making sure there is current AV on each computer, so that caught it.) John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, December 05, 2003 8:25 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Declude not taking action, IMail 7.15 H2 with Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30 Well, I was really hoping it would have been a Declude problem...that way it probably would have been fixed in days as opposed to requiring me to get an upgrade to IMail 8 for them to fix the issue. I'm going to reduce my queue from running every 15 minutes to every hour just to lessen the possibility of this happening. Please keep us posted if you hear anything. I imagine it will take them a while and IMail 7 users may be out in the dark. Matt R. Scott Perry wrote: This is the first time that I have ever seen this and it occurred just a few days after upgrading from 1.75i6 to 1.76i28-30. Unlike some others that I have noted in the past, I am using IMail 7.15 Hotfix 2, so it doesn't seem related to IMail 8. This is getting scary. It looks like there is a serious bug in IMail v7 and v8 that is just starting to be discovered: --- IMail Log --- 20031205 184256 127.0.0.1 SMTPD (046101B0) [208.7.179.15] connect 64.119.217.36 port 41441 20031205 184258 127.0.0.1 SMTPD (queue run) 13471 1 69 20031205 184258 127.0.0.1 SMTPD (046101B0) [64.119.217.36] E:\spool\D1800046101b02123.SMD 1332 20031205 184258 127.0.0.1 SMTP (3696) processing E:\spool\Q1800046101b02123.SMD 12/05/2003 18:43:02 Q1800046101b02123 Scanned: Virus Free [MIME: 1 765] 12/05/2003 18:43:04 Q1800046101b02123 Msg failed DELETE (Weight of 80 reaches or exceeds the limit of 30.). Action=DELETE. This is the same pattern that we tracked in another E-mail: [1] IMail's SMTPD process starts receiving the E-mail. [2] IMail starts a queue run to deliver E-mail in the spool [3] IMail's SMTPD process saves the E-mail to the hard drive [4] IMail's queue run delivers the E-mail [5] IMail's SMTPD process starts Declude [6] IMail tries to deliver the E
RE: [Declude.JunkMail] Declude not taking action, IMail 7.15 H2 with Declude 1.76i30 H2 with Declude 1.76i30
We're still running 7.07 here. We're not seeing any of the problems you're referring to in this version, so I think the bugs very likely started in the next major release 7.10, which had problems on our server. This is getting scary. It looks like there is a serious bug in IMail v7 and v8 that is just starting to be discovered: --- [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.
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.6% 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.
Re: [Declude.JunkMail] Declude not taking action, IMail 7.15 H2 with Declude 1.76i30 H2 with Declude 1.76i30 Declude 1.76i30 H2 with Declude 1.76i30
Well, I was really hoping it would have been a Declude problem...that way it probably would have been fixed in days as opposed to requiring me to get an upgrade to IMail 8 for them to fix the issue. I'm going to reduce my queue from running every 15 minutes to every hour just to lessen the possibility of this happening. Please keep us posted if you hear anything. I imagine it will take them a while and IMail 7 users may be out in the dark. Matt R. Scott Perry wrote: This is the first time that I have ever seen this and it occurred just a few days after upgrading from 1.75i6 to 1.76i28-30. Unlike some others that I have noted in the past, I am using IMail 7.15 Hotfix 2, so it doesn't seem related to IMail 8. This is getting scary. It looks like there is a serious bug in IMail v7 and v8 that is just starting to be discovered: --- IMail Log --- 20031205 184256 127.0.0.1 SMTPD (046101B0) [208.7.179.15] connect 64.119.217.36 port 41441 20031205 184258 127.0.0.1 SMTPD (queue run) 13471 1 69 20031205 184258 127.0.0.1 SMTPD (046101B0) [64.119.217.36] E:\spool\D1800046101b02123.SMD 1332 20031205 184258 127.0.0.1 SMTP (3696) processing E:\spool\Q1800046101b02123.SMD 12/05/2003 18:43:02 Q1800046101b02123 Scanned: Virus Free [MIME: 1 765] 12/05/2003 18:43:04 Q1800046101b02123 Msg failed DELETE (Weight of 80 reaches or exceeds the limit of 30.). Action=DELETE. This is the same pattern that we tracked in another E-mail: [1] IMail's SMTPD process starts receiving the E-mail. [2] IMail starts a queue run to deliver E-mail in the spool [3] IMail's SMTPD process saves the E-mail to the hard drive [4] IMail's queue run delivers the E-mail [5] IMail's SMTPD process starts Declude [6] IMail tries to deliver the E-mail that Declude scanned Ipswitch has been notified that there is a problem here; hopefully, they will take care of it. -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.
