Re: [sniffer] OT - Microsoft Patch Day - Exchange and SMTP updates
The MS04-35 reissue some how slipped under the radar yesterday of the other patches.. So far no public exploits for that. However, SANS is indicating POC code has been released for MS05-05/09. So far for the cycle I patched one LOW volume production mail server and one standby server. Both of those are showing no issues. Anyone else apply these yet? Darrell Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, MRTG Integration, and Log Parsers. Colbeck, Andrew writes: Hello, all. Aside from the usual Internet Explorer and Office patches, this patch cycle also includes an update to the October update MS04-035 which affects a DNS query vulnerability in the SMTP handling in Windows 2000/2003 as well as Exchange 2003. http://www.microsoft.com/technet/security/bulletin/ms04-035.mspx This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] OT - Microsoft Patch Day - Exchange and SMTP updates
Yes, I patched 3 servers last night and tested without issue. Most of the way through a normal workday now, also without issue. Message volumes are high enough that I expect any problems to have turned up by now. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darrell ([EMAIL PROTECTED]) Sent: Thursday, February 10, 2005 10:49 AM To: sniffer@SortMonster.com Subject: Re: [sniffer] OT - Microsoft Patch Day - Exchange and SMTP updates The MS04-35 reissue some how slipped under the radar yesterday of the other patches.. So far no public exploits for that. However, SANS is indicating POC code has been released for MS05-05/09. So far for the cycle I patched one LOW volume production mail server and one standby server. Both of those are showing no issues. Anyone else apply these yet? Darrell Check out http://www.invariantsystems.com for utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, MRTG Integration, and Log Parsers. Colbeck, Andrew writes: Hello, all. Aside from the usual Internet Explorer and Office patches, this patch cycle also includes an update to the October update MS04-035 which affects a DNS query vulnerability in the SMTP handling in Windows 2000/2003 as well as Exchange 2003. http://www.microsoft.com/technet/security/bulletin/ms04-035.mspx This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Changes - another reminder.
Hello Sniffer Folks, This is a _special_ reminder that we are in the process of migrating our servers and applications to a new facility. Over the past few weeks we have been testing and tweaking software, the new hardware, networks, firewalls, configurations, procedures... and occasionally we've been letting you know that we're getting ready to do this so that you won't be surprised by any unavoidable interruptions. What is _special_ about this reminder is that we are very close to the switch-over. If all goes as planned, the switch-over may occur any time in the next 48 hours. There is no specific moment in time that the switch-over will occur. It is a large process requiring the coordination of several hundred steps. During this period you may see the following problems or issues: * You may not receive one or more update notifications. * You may not be able to download your rulebase file(s). * You may not be able to upload your log file(s). * You may not be able to access special applications. All of these are likely to occur at one point or another - at least for short periods - while DNS records are changed, data is transferred to new servers, etc. It is our plan that most of these events will be so short-lived as to pose no problem to you and perhaps even to go un-noticed. IMPORTANT Your Message Sniffer software will continue to work normally! We have designed Message Sniffer to be resilient in the face of any kind of temporary interruption. At most you might see a slight increase in spam leakage if/when rulebase updates are delayed. --- Thanks to all of you for your support and patience. See you on the other side ;-) Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Changes - another reminder.
If I may suggest: - at least 24 hours before the cut-over, change DNS timeout for A and CNAME records to 4 hours. - on the day of the cutover, change DNS timeouts to 1 hour That will minimize any impact. - after the cutover was successful, change DNS timeouts for the updated records to longer values. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, February 14, 2005 02:06 PM To: sniffer@sortmonster.com Subject: [sniffer] Changes - another reminder. Hello Sniffer Folks, This is a _special_ reminder that we are in the process of migrating our servers and applications to a new facility. Over the past few weeks we have been testing and tweaking software, the new hardware, networks, firewalls, configurations, procedures... and occasionally we've been letting you know that we're getting ready to do this so that you won't be surprised by any unavoidable interruptions. What is _special_ about this reminder is that we are very close to the switch-over. If all goes as planned, the switch-over may occur any time in the next 48 hours. There is no specific moment in time that the switch-over will occur. It is a large process requiring the coordination of several hundred steps. During this period you may see the following problems or issues: * You may not receive one or more update notifications. * You may not be able to download your rulebase file(s). * You may not be able to upload your log file(s). * You may not be able to access special applications. All of these are likely to occur at one point or another - at least for short periods - while DNS records are changed, data is transferred to new servers, etc. It is our plan that most of these events will be so short-lived as to pose no problem to you and perhaps even to go un-noticed. IMPORTANT Your Message Sniffer software will continue to work normally! We have designed Message Sniffer to be resilient in the face of any kind of temporary interruption. At most you might see a slight increase in spam leakage if/when rulebase updates are delayed. --- Thanks to all of you for your support and patience. See you on the other side ;-) Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Changes - Heavy lifting is complete...
Hello sniffer, Will anyone who is not still alive please raise your hand anyone? All joking aside: We are finished with all of the heavy parts of our move now and as far as I can tell everything important is working as it should. Please let us know how we did. Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Changes - Heavy lifting is complete...
Pete McNeil wrote: Hello sniffer, Will anyone who is not still alive please raise your hand anyone? All joking aside: We are finished with all of the heavy parts of our move now and as far as I can tell everything important is working as it should. Please let us know how we did. IMHO you did excellent!! It looks like the new facilities have *greatly* increased my download speed. I was sometimes seeing as slow as 10KB/s previously, and usually around 80KB/s. Now I'm seeing about 1.6MB/s Huge increase, and yes that's 1.6 MegaBytes not MegaBits!! Thanks, Russ --- [This E-mail scanned for viruses by Declude Virus] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Interesting Article
On Friday, February 18, 2005, 12:43:14 PM, Computer wrote: CHS Hi Sniffer Folks, CHS CHS Here's an interesting article: CHS http://www.technewsworld.com/story/39578.html I think this is a rehash of a story that showed up a few weeks ago. One of the advantages of SNF is that it doesn't use DNS for anything - so this entire threat is a non-issue for SNF users, at least for the most part. Slow news day I guess... Thanks! _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Interesting Article
Also, leading Internet service company AOL (NYSE: AOL) said it noticed a sharp drop in spam being sent to its members during 2004. Yet most observers say spam is at least as bad A result of AOL's aggressive legal stand (helped by their location in VA and the support by their local law enforcement) - so I have been told by someone in the industry. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 01:14 PM To: Computer House Support Subject: Re: [sniffer] Interesting Article On Friday, February 18, 2005, 12:43:14 PM, Computer wrote: CHS Hi Sniffer Folks, CHS CHS Here's an interesting article: CHS http://www.technewsworld.com/story/39578.html I think this is a rehash of a story that showed up a few weeks ago. One of the advantages of SNF is that it doesn't use DNS for anything - so this entire threat is a non-issue for SNF users, at least for the most part. Slow news day I guess... Thanks! _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] IIS SMTP Integration
It needs to be a transport sink, or at least work with one in order to prevent ongoing issues with brute force spam floods. Huh? Why would it need to be a transport sink? Why first accept and store the message - and then generate bounce messages (in case it's a false positive)? Scanning at protocol time will take just as long (a few milliseconds) - but you'll be able to drop connection as soon as you determine you don't want the mail. This way, the other party has notice in case of FP and you are not responsible for generating bounces and you are not going to spam job-jobbed users. In a protocol sink, the sink can pass the in-memory email directly to the Sniffer service - no need to write to disk/read from disk and starting command-prompt tasks etc etc. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Friday, February 18, 2005 07:23 PM To: sniffer@SortMonster.com Subject: Re: [sniffer] IIS SMTP Integration Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). Yes, that really is a key issue. It needs to be a transport sink, or at least work with one in order to prevent ongoing issues with brute force spam floods. I'm not sure that Peter from VamSoft understands the large market out there for non-Exchange based setups, or even for going the extra mile that is necessary for this stuff, though that might be an issue with resources and not just simply understanding. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] IIS SMTP Integration
The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Okay, but if you wait until the message is stored in the queue and NOW you have to scan each one with a command-line process - how is THAT better (that's the transport sink scenario). What you want to do is: A) upon connection, check DNS BLs - if matches, add points B) upon HELO, check HELO rules - if matches, add points C) upon MAIL FROM - check for , if it matches, set a flag (there should only be ONE recipient) check DNS BLs for blacklisted recipients, if matches, add points D) upon RCPT TO - check for valid recipient - if more than 2 invalid recipients, drop connection. If sender is and more than 1 recipient, drop connection If recipient is Postmaster@ or Abuse@ or Root@ (etc) and more than 1 recipient, drop connection (with proper return code too many recipients) E) at EOD (after the CR.CR), - check for SMTP AUTH (so you can skip scanning) - otherwise scan the content with Sniffer (and Virus Scanner) - add points If the points exceed your threshold at ANY time, drop connection. No bounce message necessary, no need to store the message in the queue, etc. Whenever you drop connection, add IP to your tarpit/graylist list. Use that for subsequent upon connections Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. You can do that by processing the log file. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). M Yes, that really is a key issue. It needs to be a transport sink, or M at least work with one in order to prevent ongoing issues with brute M force spam floods. I'm not sure that Peter from VamSoft understands M the large market out there for non-Exchange based setups, or even for M going the extra mile that is necessary for this stuff, though that M might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] IIS SMTP Integration
Hi Andrew: The idea being that you don't want any more content searching than is necessary The content searching happens at the very end of the protocol conversation. By that time you already have processed your IP, HELO, SENDER etc. policies (e.g. DNS BL, local BLs, etc.) Or are you saying you want to only search for content when there is NO dictionary attack - but if you happen to be under dictionary attack you want to let all the spam go through unchecked? Seems counterintuitive to me. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). M Yes, that really is a key issue. It needs to be a transport sink, or M at least work with one in order to prevent ongoing issues with brute M force spam floods. I'm not sure that Peter from VamSoft understands M the large market out there for non-Exchange based setups, or even for M going the extra mile that is necessary for this stuff, though that M might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] IIS SMTP Integration
I guess you essentially got my point and what appears to be Sandy's. Once you take an Exchange server (or any other server) and insert such a gateway, you loose your ability to do address validation. Nowadays this is vital due to real world circumstances as you have yourself experienced. If Sniffer was introduced with some form of MS SMTP integration and was unable to do address validation during the RCPT TO, then it could very well create issues beyond what it solves (backscatter and potentially drowning the CPU). There will be a solution created for this at some point within the next year I'm sure. As to how far it goes in terms of spam blocking, I don't know. I suppose the best solution would be to have a full Declude installation bound to MS SMTP doing both OnInBound and OnArrival sinks. The market potential for this would be rather large in comparison to targeting specific mail servers as they do now, though it appears that it would be somewhat more complicated. Matt Andy Schmidt wrote: The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Okay, but if you wait until the message is stored in the queue and NOW you have to scan each one with a command-line process - how is THAT better (that's the transport sink scenario). What you want to do is: A) upon connection, check DNS BLs - if matches, add points B) upon HELO, check HELO rules - if matches, add points C) upon MAIL FROM - check for , if it matches, set a flag (there should only be ONE recipient) check DNS BLs for blacklisted recipients, if matches, add points D) upon RCPT TO - check for valid recipient - if more than 2 invalid recipients, drop connection. If sender is and more than 1 recipient, drop connection If recipient is Postmaster@ or Abuse@ or Root@ (etc) and more than 1 recipient, drop connection (with proper return code "too many recipients) E) at EOD (after the CR.CR), - check for SMTP AUTH (so you can skip scanning) - otherwise scan the content with Sniffer (and Virus Scanner) - add points If the points exceed your threshold at ANY time, drop connection. No bounce message necessary, no need to store the message in the queue, etc. Whenever you drop connection, add IP to your "tarpit/graylist" list. Use that for subsequent "upon connections" Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. You can do that by processing the log file. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). M Yes, that really is a key issue. It needs to be a transport sink, or M at least work with one in order to prevent ongoing issues with brute M force spam floods. I'm not sure that Peter from VamSoft understands M the large market out there for non-Exchange based setups, or even for M going the extra mile that is necessary for this stuff, though that M might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible
Re: [sniffer] IIS SMTP Integration
Title: Message Yeah, I mixed up some words earlier in my reply to Sandy's post. I should have said that it needed to be paired with or run as a protocol/OnInBound sink that also does address validation. That's probably what confused you as to the meaning of what I had said earlier. I'm only roughly familiar with the terminology. Matt Andy Schmidt wrote: Uh, I see, you are not against the protocol sink in principal - you are only against it IF there is no means of doing address validation (and possible some other checks) at the same time. Yes, I have other protocol sinks in place (including ORF) that allow me to do protocol rejections on the other items (and have been sitting on my relay customers to give me access to their user base as well). So in my case, Sniffer will ONLY check a small percentage of emails (those to valid recipientsthat didn't have more than two false recipients and didn't have a HELO with my IP and didn't use SMTP AUTH and who didn't fail certain various *proxy DNSBLs.) Once I have my last two customers' LDAP information integrated, I'llblock off my Imail/Declude server altogether and usetwo IIS SMTP servers as incoming gateways.Ideally I want to move my Sniffer license to the IIS SMTP server and then buy an extra license for the second IIS SMTP server. With ORF's 2.0 graylisting and tarpitting, things will become pretty solid - and Sniffer integration was/is the missing brick in the wall. PS: Let's not forget, there is no reason why Sniffer couldn't be configured to check either at the protocol level OR the transport level.ORF currentlydoes that. But I think it's important that protocol is offered as one choice. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Friday, February 18, 2005 10:33 PM To: sniffer@SortMonster.com Subject: Re: [sniffer] IIS SMTP Integration I guess you essentially got my point and what appears to be Sandy's. Once you take an Exchange server (or any other server) and insert such a gateway, you loose your ability to do address validation. Nowadays this is vital due to real world circumstances as you have yourself experienced. If Sniffer was introduced with some form of MS SMTP integration and was unable to do address validation during the RCPT TO, then it could very well create issues beyond what it solves (backscatter and potentially drowning the CPU). There will be a solution created for this at some point within the next year I'm sure. As to how far it goes in terms of spam blocking, I don't know. I suppose the best solution would be to have a full Declude installation bound to MS SMTP doing both OnInBound and OnArrival sinks. The market potential for this would be rather large in comparison to targeting specific mail servers as they do now, though it appears that it would be somewhat more complicated. Matt Andy Schmidt wrote: The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Okay, but if you wait until the message is stored in the queue and NOW you have to scan each one with a command-line process - how is THAT better (that's the transport sink scenario). What you want to do is: A) upon connection, check DNS BLs - if matches, add points B) upon HELO, check HELO rules - if matches, add points C) upon MAIL FROM - check for , if it matches, set a flag (there should only be ONE recipient) check DNS BLs for blacklisted recipients, if matches, add points D) upon RCPT TO - check for valid recipient - if more than 2 invalid recipients, drop connection. If sender is and more than 1 recipient, drop connection If recipient is Postmaster@ or Abuse@ or Root@ (etc) and more than 1 recipient, drop connection (with proper return code "too many recipients) E) at EOD (after the CR.CR), - check for SMTP AUTH (so you can skip scanning) - otherwise scan the content with Sniffer (and Virus Scanner) - add points If the points exceed your threshold at ANY time, drop connection. No bounce message necessary, no need to store the message in the queue, etc. Whenever you drop connection, add IP to your "tarpit/graylist" list. Use that for subsequent "upon connections" Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. You can do that by processing the log file. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]:
RE: [sniffer] IIS SMTP Integration
Hi folks, I think I have ended up on some sort of private email list. Can you please remove [EMAIL PROTECTED] and [EMAIL PROTECTED] from your mail list. Thanks! Ron Doss Quoting Andy Schmidt [EMAIL PROTECTED]: It needs to be a transport sink, or at least work with one in order to prevent ongoing issues with brute force spam floods. Huh? Why would it need to be a transport sink? Why first accept and store the message - and then generate bounce messages (in case it's a false positive)? Scanning at protocol time will take just as long (a few milliseconds) - but you'll be able to drop connection as soon as you determine you don't want the mail. This way, the other party has notice in case of FP and you are not responsible for generating bounces and you are not going to spam job-jobbed users. In a protocol sink, the sink can pass the in-memory email directly to the Sniffer service - no need to write to disk/read from disk and starting command-prompt tasks etc etc. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Friday, February 18, 2005 07:23 PM To: sniffer@SortMonster.com Subject: Re: [sniffer] IIS SMTP Integration Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). Yes, that really is a key issue. It needs to be a transport sink, or at least work with one in order to prevent ongoing issues with brute force spam floods. I'm not sure that Peter from VamSoft understands the large market out there for non-Exchange based setups, or even for going the extra mile that is necessary for this stuff, though that might be an issue with resources and not just simply understanding. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] IIS SMTP Integration
Hello, Can you please remove me from your mail list. My address is [EMAIL PROTECTED] and [EMAIL PROTECTED] Thanks! Ron Quoting Matt [EMAIL PROTECTED]: I guess you essentially got my point and what appears to be Sandy's. Once you take an Exchange server (or any other server) and insert such a gateway, you loose your ability to do address validation. Nowadays this is vital due to real world circumstances as you have yourself experienced. If Sniffer was introduced with some form of MS SMTP integration and was unable to do address validation during the RCPT TO, then it could very well create issues beyond what it solves (backscatter and potentially drowning the CPU). There will be a solution created for this at some point within the next year I'm sure. As to how far it goes in terms of spam blocking, I don't know. I suppose the best solution would be to have a full Declude installation bound to MS SMTP doing both OnInBound and OnArrival sinks. The market potential for this would be rather large in comparison to targeting specific mail servers as they do now, though it appears that it would be somewhat more complicated. Matt Andy Schmidt wrote: The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Okay, but if you wait until the message is stored in the queue and NOW you have to scan each one with a command-line process - how is THAT better (that's the transport sink scenario). What you want to do is: A) upon connection, check DNS BLs - if matches, add points B) upon HELO, check HELO rules - if matches, add points C) upon MAIL FROM - check for , if it matches, set a flag (there should only be ONE recipient) check DNS BLs for blacklisted recipients, if matches, add points D) upon RCPT TO - check for valid recipient - if more than 2 invalid recipients, drop connection. If sender is and more than 1 recipient, drop connection If recipient is Postmaster@ or Abuse@ or Root@ (etc) and more than 1 recipient, drop connection (with proper return code too many recipients) E) at EOD (after the CR.CR), - check for SMTP AUTH (so you can skip scanning) - otherwise scan the content with Sniffer (and Virus Scanner) - add points If the points exceed your threshold at ANY time, drop connection. No bounce message necessary, no need to store the message in the queue, etc. Whenever you drop connection, add IP to your tarpit/graylist list. Use that for subsequent upon connections Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. You can do that by processing the log file. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M Sanford Whiteman wrote: Incidentally, it is a transport sink, not a protocol sink, meaning that envelope rejection is not possible. I can't defend this as solely a choice made for stability, as it was also a choice necessitated by my prototyping in VB (and, though it's been in production, it's not much more than a prototype due to the lack of docs). M Yes, that really is a key issue. It needs to be a transport sink, or M at least work with one in order to prevent ongoing issues with brute M force spam floods. I'm not sure that Peter from VamSoft understands M the large market out there for non-Exchange based setups, or even for M going the extra mile that is necessary for this stuff, though that M might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before
Re[3]: [sniffer] IIS SMTP Integration
On Saturday, February 19, 2005, 4:38:41 AM, Pete wrote: PM On Saturday, February 19, 2005, 1:20:39 AM, ron wrote: rdc Hi folks, rdc I think I have ended up on some sort of private email list. Can you please rdc remove [EMAIL PROTECTED] and [EMAIL PROTECTED] from your mail list. PM I found and removed [EMAIL PROTECTED] from the Message Sniffer D'oh that was silly of me - forgot to change the return address. Sorry for the extra noise. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Determine Version
Is there a easy way to determine the Sniffer version you are running (i.e. command line or the like)? Thanks for the aid. Keith winmail.dat
RE: [sniffer] Determine Version
Title: Message Yup, just type the executable's filename in a command window, and the version information is on the last couple of lines in the resulting help. Andrew 8) p.s. My version says build - v2-3.2 Nov 23 2004 01:21:33 -Original Message-From: Keith Johnson [mailto:[EMAIL PROTECTED] On Behalf Of Keith JohnsonSent: Saturday, February 19, 2005 8:20 AMTo: sniffer@SortMonster.comSubject: Determine Version Is there a easy way to determine the Sniffer version you are running (i.e. command line or the like)? Thanks for the aid. Keith
Re: [sniffer] Determine Version
On Saturday, February 19, 2005, 11:19:32 AM, Keith wrote: KJ Is there a easy way to determine the Sniffer version you are KJ running (i.e. command line or the like)? Thanks for the aid. If you run the SNF executable on the command line by itself it will tell you the version and build information at the bottom of it's message. This is relatively new. If it doesn't do this then it's an old version for sure. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Seperate Lists?
On Saturday, February 19, 2005, 1:28:14 PM, Dave wrote: DK I am all in favor of a SUPPORT list to announce timely DK notifications of problems. solutions and/or changes to your DK product or services. However, the threads Ive been seeing here DK lately are 'iMail' specific or involve theoretical discussion of DK improving iMail performance via a Gateway product using IIS's SMTP DK engine. These discussions have absolutely nothing to do with the DK support of your product in it's current offerings, nor my server DK of choice. DK As a new customer Might I request that you setup a separate list for DK discussion, development, beta, theoretical or iMail issues? If not, then I DK too will also ask to be removed from this list. DK Thanks in advance for your consideration. On this list I hope to provide not only support and announcements but also to foster a community around all of the related issues - often there are things to be learned from other platforms or related discussions - even the theoretical ones. From my perspective the IIS SMTP engine discussion covers a wide range and is on topic. For example, this is how MS Exchange could be supported directly. It is my goal to see SNF available and used well on as many platforms as possible. That said, we do have many IMail users here so those topics are frequent as are Declude discussions. In the end though, there are a lot of people here - most of whom are dealing with problems and issues that are related to spam, email services, and related technologies such as DNS, server performance, networks security, etc. In my view, this community is invaluable and provides an enriched level of support on all issues by sharing experiences and additional perspectives. I would be sorry to see you go, but certainly I understand if this is not a forum you want to follow. Instructions for (un)subscribing to this list are on our help page as indicated in the tag line of these messages. http://www.sortmonster.com/MessageSniffer/Help/Help.html If you do decide to leave this list then please remember to check our web site regularly for any important announcements - we put them in our news section. Support is also available through our support@ address, of course, though I may refer back to this list if I get stumped ;-). Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Seperate Lists?
Pete, Being guilty of being 'chatty' myself, I still second this idea. I would much prefer to pick through an occasional message dealling with global announcements regarding the service than picking through both discussions as well as announcements. I'm not always up to date on this list and others that I follow and I probably will pay less attention to them over time as I get buried in other things as many of us do. Please consider a separate announcement-only list for this purpose. Alternatively, having both mixed will both overwhelm users not interested in the more general discussion and it may also cause those of us that are more 'chatty' to quiet down which stifles the discussion and the benefit that can be gleamed from it. Thanks, Matt Pete McNeil wrote: On Saturday, February 19, 2005, 1:28:14 PM, Dave wrote: DK I am all in favor of a SUPPORT list to announce timely DK notifications of problems. solutions and/or changes to your DK product or services. However, the threads Ive been seeing here DK lately are 'iMail' specific or involve theoretical discussion of DK improving iMail performance via a Gateway product using IIS's SMTP DK engine. These discussions have absolutely nothing to do with the DK support of your product in it's current offerings, nor my server DK of choice. DK As a new customer Might I request that you setup a separate list for DK discussion, development, beta, theoretical or iMail issues? If not, then I DK too will also ask to be removed from this list. DK Thanks in advance for your consideration. On this list I hope to provide not only support and announcements but also to foster a community around all of the related issues - often there are things to be learned from other platforms or related discussions - even the theoretical ones. From my perspective the IIS SMTP engine discussion covers a wide range and is on topic. For example, this is how MS Exchange could be supported directly. It is my goal to see SNF available and used well on as many platforms as possible. That said, we do have many IMail users here so those topics are frequent as are Declude discussions. In the end though, there are a lot of people here - most of whom are dealing with problems and issues that are related to spam, email services, and related technologies such as DNS, server performance, networks security, etc. In my view, this community is invaluable and provides an enriched level of support on all issues by sharing experiences and additional perspectives. I would be sorry to see you go, but certainly I understand if this is not a forum you want to follow. Instructions for (un)subscribing to this list are on our help page as indicated in the tag line of these messages. http://www.sortmonster.com/MessageSniffer/Help/Help.html If you do decide to leave this list then please remember to check our web site regularly for any important announcements - we put them in our news section. Support is also available through our support@ address, of course, though I may refer back to this list if I get stumped ;-). Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Seperate Lists?
On Saturday, February 19, 2005, 2:05:09 PM, Matt wrote: M Pete, M Being guilty of being 'chatty' myself, I still second this idea. I M would much prefer to pick through an occasional message dealling with M global announcements regarding the service than picking through both M discussions as well as announcements. I'm not always up to date on this M list and others that I follow and I probably will pay less attention to M them over time as I get buried in other things as many of us do. M Please consider a separate announcement-only list for this purpose. M Alternatively, having both mixed will both overwhelm users not M interested in the more general discussion and it may also cause those of M us that are more 'chatty' to quiet down which stifles the discussion and M the benefit that can be gleamed from it. Point taken. This seems to be a popular idea so I will look into it. This list, however, will remain chatty. The announcements only list will only be used for that purpose. I would hate to see the discussions on this list quieted. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] Seperate Lists?
Thanks Matt for clarifying my point, and Pete for considering this. Oddly enough, I would likely subscribe to BOTH lists, but the seperation would allow me to filter, target and respond to more 'important' emails notices, and review discussions *IF* and/or when I have time. As an Email/Network Admin and IT Manager, I receive hundreds of emails per day, and so I must be able to automatically prioritize those messages via filters as they arrive so I can focus on Critical information. Thanks again for your consideration! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Saturday, February 19, 2005 2:25 PM To: Matt Subject: Re[2]: [sniffer] Seperate Lists? On Saturday, February 19, 2005, 2:05:09 PM, Matt wrote: M Pete, M Being guilty of being 'chatty' myself, I still second this idea. I M would much prefer to pick through an occasional message dealling with M global announcements regarding the service than picking through both M discussions as well as announcements. I'm not always up to date on M this list and others that I follow and I probably will pay less M attention to them over time as I get buried in other things as many of us do. M Please consider a separate announcement-only list for this purpose. M Alternatively, having both mixed will both overwhelm users not M interested in the more general discussion and it may also cause those M of us that are more 'chatty' to quiet down which stifles the M discussion and the benefit that can be gleamed from it. Point taken. This seems to be a popular idea so I will look into it. This list, however, will remain chatty. The announcements only list will only be used for that purpose. I would hate to see the discussions on this list quieted. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] New change rates analysis
Hello Sniffer Folks, I have updated the change rates analysis page to show a bar graph of the recently created rules and their relative strengths (by age). This replaces the old text report we had before, though the data is still the same and then some. Comments welcome. Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] New change rates analysis
http://www.sortmonster.com/MessageSniffer/Performance/ChangeRates.jsp Oooh, pretty! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Sunday, February 20, 2005 3:52 PM To: sniffer@sortmonster.com Subject: [sniffer] New change rates analysis Hello Sniffer Folks, I have updated the change rates analysis page to show a bar graph of the recently created rules and their relative strengths (by age). This replaces the old text report we had before, though the data is still the same and then some. Comments welcome. Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Notice: Potential outages tonight...
Hello Sniffer Folks, There will be some work on the core router system tonight. This may result in short, intermittent outages. We do not expect any major interruptions. Since Message Sniffer runs locally on your system you should not be effected. However, you may have trouble reaching our web site, uploading logs or downloading rulebases if this happens during one of these short outages. We apologize in advance for any inconvenience. Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] What to do with the spam?
I have been running the demo version of sniffer for about a month or so to try it out before we buy it and have a few questions. 1. Right now all of the spam is going into a directory called spam, since I am getting about 12,000 spams a day being filtered I might as well just have it delete everything and save the disk drive, as there is no way to easily find an email that has been filtered. Is there a way to copy the email into separate directories and subdirectories for each domain/mailbox so that I can go through and look for false positives? I can even create a web site for people to look for their own if this can be done. I have gotten a few complaints about missing mail. Has anyone done this? I know that some of the other spam filters in particular hardware appliances hold the spam in a special spam box so that the clients can look through it and delete it after they find it is actual spam, or have the option of just delete everything. I am using VOPMail 5 on 2000 Server. 2. Not sure how it works once we subscribe, are we able to set our own white/black lists into our filter or do we all get the same filter as everyone else? Is there some sort of user interface panel when we log in to get our new filters or some sort of compiler we run to add in our additional rules? Thanks, Phil This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] What to do with the spam?
On Monday, March 7, 2005, 3:13:40 PM, Phillip wrote: PC I have been running the demo version of sniffer for about a month or so to PC try it out before we buy it and have a few questions. PC 1. Right now all of the spam is going into a directory called spam, since I PC am getting about 12,000 spams a day being filtered I might as well just PC have it delete everything and save the disk drive, as there is no way to PC easily find an email that has been filtered. Is there a way to copy the PC email into separate directories and subdirectories for each domain/mailbox PC so that I can go through and look for false positives? I can even create a PC web site for people to look for their own if this can be done. I have PC gotten a few complaints about missing mail. Has anyone done this? I know PC that some of the other spam filters in particular hardware appliances hold PC the spam in a special spam box so that the clients can look through it and PC delete it after they find it is actual spam, or have the option of just PC delete everything. There are a lot of ways to set up a user searchable quarantine area - all of them (that I am aware of) require a bit of technical work. However, in a pinch you might start with what we do on our small test system. All spam goes into a directory. Nightly a script runs to delete any messages that are older than x (in our case one week at the moment). If anyone complains of a missing message then we search the folder with find or grep for any elements that might be in the message the user was expecting. We have very few of these requests, so this is usually easy to do and doesn't take very long. For example we might search the spam folder for any file containing the expected sender's address, or a particular file name, etc... With a bit more work it is possible to write scripts that will catalog messages by recipient and present the list on a web page that the recipient can view after logging in. If they see a message they want (a line item shows From: To: Subject: Date:) then they can click on the message to have it delivered. I hope these ideas are useful. PC I am using VOPMail 5 on 2000 Server. :-) Thanks! It's good to know you are out there. PC 2. Not sure how it works once we subscribe, are we able to set our own PC white/black lists into our filter or do we all get the same filter as PC everyone else? Is there some sort of user interface panel when we log in to PC get our new filters or some sort of compiler we run to add in our PC additional rules? Registered users begin with the core rulebase and most never alter that. However, you may request any white or black rules you wish and we will work with you to adjust your registered rulebase. You may also block rules that appear in the core rulebase if they conflict with your policies. Normally this work is carried out as a matter of course through our flase positive handling process. For each false positive we will explain the rules that fired and possible recommend an adjustment. Often we make adjustments to the core rulebase to avoid additional false positives and to solve those that might not have been identified or reported. In the end your registered rulebase can be completely customized (within reason) and even extensive modifications are possible if you wish to contract with us to help with those changes. Larger systems that have special agreements with us and/or more than 10 licenses are given access to our online rulebase system and our RESCU (REmote SCripted Updater) utility so that they can make direct adjustments to their rulebase, with our assistance of course. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] What to do with the spam?
Phillip Cohen wrote: 1. Right now all of the spam is going into a directory called spam, since I am getting about 12,000 spams a day being filtered I might as well just have it delete everything and save the disk drive, as there is no way to easily find an email that has been filtered. Is there a way to copy the email into separate directories and subdirectories for each domain/mailbox so that I can go through and look for false positives? Since you are running VopMail, (I also run this on our server), you would need a program to identify the intended recipient and move the mail into their directory. I can see this in my head, it's not too hard. In your agent.bat file you are given a few parameters you can pass to it, like %m %r and a few more. Using these variables, you might be able to determine who the message is intended for and modify the batch file to move it to the proper place. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] SPAM
At 06:40 PM 3/7/2005 -0500, Frederick Samarelli wrote: I am seeing a large amount of SPAM Pass Sniffer today. Am I alone. Actually mine seems to have had somewhat less bleed through then usual over the last couple of days. -- Kirk Mitchell-General Manager[EMAIL PROTECTED] Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] SPAM
On Monday, March 7, 2005, 6:40:52 PM, Frederick wrote: FS I am seeing a large amount of SPAM Pass Sniffer today. FS Am I alone. I didn't see this. According to MDLP the first half of the day (at least) was right in the normal range - about 98.5% of spam captured. http://www.sortmonster.com/MDLP/MDLP-Example-Short.html 89.8% of messages were spam. Anybody else see spam leakage I didn't? Frederick: Any errors in the log? _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] SPAM
No errors. Just SPAM showing as clean. - Original Message - From: Pete McNeil [EMAIL PROTECTED] To: Frederick Samarelli sniffer@SortMonster.com Sent: Monday, March 07, 2005 6:56 PM Subject: Re: [sniffer] SPAM On Monday, March 7, 2005, 6:40:52 PM, Frederick wrote: FS I am seeing a large amount of SPAM Pass Sniffer today. FS Am I alone. I didn't see this. According to MDLP the first half of the day (at least) was right in the normal range - about 98.5% of spam captured. http://www.sortmonster.com/MDLP/MDLP-Example-Short.html 89.8% of messages were spam. Anybody else see spam leakage I didn't? Frederick: Any errors in the log? _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] SPAM
On Monday, March 7, 2005, 7:00:40 PM, Frederick wrote: FS No errors. Just SPAM showing as clean. Be sure to forward / redirect them to the spam@ address if you haven't already. I'll be making another run in an hour or so - I'll look closely at anything that doesn't get tagged on the way to me. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: Re[2]: [sniffer] SPAM
I currently forward all spam from my email account can I add a second address that will be able to forward spam as well? Jonathan SchoemannNetwork Systems EngineerInformation ServicesSt. Agnes HealthCare / CSC[EMAIL PROTECTED]410-368-3110 [EMAIL PROTECTED] 03/07/05 07:09PM On Monday, March 7, 2005, 7:00:40 PM, Frederick wrote:FS No errors. Just SPAM showing as clean.Be sure to forward / redirect them to the spam@ address if you haven'talready. I'll be making another run in an hour or so - I'll lookclosely at anything that doesn't get tagged on the way to me._MThis E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html THIS MESSAGE IS INTENDED ONLY FOR OFFICIAL BUSINESS USE BY THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivery of the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.
Re[4]: [sniffer] SPAM
On Wednesday, March 9, 2005, 2:59:24 PM, Jonathan wrote: JS I currently forward all spam from my email account can I add JS a second address that will be able to forward spam as well? JS Yes. You can forward spam from any account you wish. Spam submissions are considered anonymous and suspect by default for security reasons. Submissions to false@ are restricted to known, registered accounts (others are filtered). If you would prefer, you might consider creating an account on your system to collect spam and then provide us with the pop3 login info. This is what we prefer to do with spamtraps, for example. Our robots can then be programmed to pull down messages from this account on your system. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Submitting to spam@
On Thursday, March 10, 2005, 9:45:11 AM, Mike wrote: MW When I send messages to the [EMAIL PROTECTED] Can I send these as attachments. I MW use outlook and SpamSource http://www.daesoft.com to send to both spamcop MW and sortmonster. I think you said at one time they had to be individual MW messages but wasn't sure if it could be as an attachment. A text attachment from SpamSource should be fine. Thanks! _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Moving Sniffer to Declude/SmarterMail
On Monday, March 14, 2005, 12:47:33 PM, Nick wrote: NM Hi there NM We've just undergone a migration of a 1,000 domain iMail server to NM SmarterMail (for obvious reasons!), and using Declude and Sniffer on the new NM system. NM However, occasionally we see Sniffer jumping out of its perpetual mode by NM spawning thousands of threads which obviously make the server slow down NM considerably. Also, at this time, the Sniffer folder fills up with the NM equivalent temporary files. NM On changing the location of Sniffer in the Declude Global file and allowing NM the threads to disappear, when Sniffer is re-engaged it correctly goes back NM to perpetual mode working from the Service instance of Sniffer. NM Can any of the above be explained? This is extremely unusual and I've not heard of this kind of thing before. The closest connection I have seen is that on one very heavily loaded system (on Linux) a change in the rulebase file caused the persistent instance to pause for a few minutes while the message instances of SNF became impatient --- however in this case the system always recovered on it's own. In your case do you restart the persistent instance or does the system simply recover once you re-enable the clients? Please post the contents of your .stat file and let me know if these are typical values. Does your system have one or two CPUs? Hyperthreading? Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Smartermail
Hello sniffer list, Like so many declude/sniffer users, we have been using IMail for the past seven years and currently host mail for about 1600 domains/5000 users. We are going to be moving to another mail package (you know why) and I know I have seen some comments on this list regarding making the move to Smartermail. From what I can see, Smartermail is *almost* there, but still lacks in a few of areas. I am looking for feedback from recent IMail to Smartermail converts -- the good, the bad and the ugly... Thanks, Steve. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Smartermail
Hi there I was contacted off-list this morning by another user with the same question - below is my reply - we moved just a few days ago from iMail to SmarterMail. Hope it helps... --- We too have been looking for an alternative to iMail for a couple of years now. A number of reasons forced our hand - the increase in price of iMail (more arrogance on their part than cost), the lack of attention they have paid to software design problems we have highlighted to them in the past, and a general slow-down of the server when dealing with many threads. So, we've been watching closely the emergence of SmarterMail and their relationship with Declude. We spoke at lengths with Declude and admired their enthusiasm for the product and the way SmarterMail's technical team seem to be willing to work with users to fine-tune future releases. SmarterTools (the company behind SmarterMail) have iMail users in their sights with a migration tools to grab all the iMail data, and mailbox contents, including address books etc, to SmarterMail. We used this and it took about 6 hours (throughout the night of course!) to migrate around 1,000 domains, 5,000 users and their content. There are a few problems we came across - one being that if the mailbox on iMail hasn't been used - ie the directory structure hasn't yet been created by iMail - the migration tool misses it. One to watch for. Declude's latest version is compatible with SmarterMail, and of course then so to is Sniffer. However, Declude Hijack hasn't been ported yet, but SmarterMail has some similar preventative measures available to do much the same thing. We have a lot of scripting behind our mail servers to automate the administration of accounts from our own control panel. We spent a couple of weeks prior to the migration getting these working on SmarterMail - we found there's nothing that can't be done that can be done on iMail. What is useful is the per-domain stats that can be automatically pulled into XML on the fly - we might run this type of gathering nightly and drop the usage data into the database for general consumption/service levels etc. So, it's all working now - and for the most, all went smoothly. Now were looking at performance. The machine we ported to is three times more powerful, so it's hard to compare exactly, however normal stats look good. We are, however, being plagued by one problem, which on closer inspection may be the cause of Sniffer perpetual dropping out - every few minutes the server will freeze for a few seconds (desktop, web services, pop3 checking, etc halt). Watching the CPU usage we see it drop to almost nothing, then at the end of the freeze, it spikes up to 100% for a few seconds - then the machine releases. It's as though there is some kind of bottleneck from a process that has higher priority over pretty much everything else. We're trying to pinpoint the problem by removing various parts to see if that helps. Today we're going to take off Declude for a few minutes and see if that's the cause. I'm sure this is not normal behaviour. We've reported it to SmarterTools and are awaiting their reply. So, in conclusion, it's a good, reasonably straightforward move considering the task. SmarterMail appears to be a much better mail server in terms of features and the user interface. But there are these few things we need to resolve to fully endorse the new server. Our users can only see basic changes such as a new WebMail facility - the rest can be made to feel the same as iMail. I'll keep you up-to-date with our progress. If Declude/Sniffer/iMail users need any more information on such a migration, I'd be glad to offer some hindsight... Nick Nick Marshall Giacom World Networks Ltd Tel +44 (0) 870 740 Mobile +44 (0) 7799 060 555 Fax +44 (0) 870 740 7177 [EMAIL PROTECTED] Legally privileged/confidential information may be contained in this message. If you are not the addressee(s) legally indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet e-mail messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my firm or employer unless otherwise indicated by an authorised representative independent of this message. Please note that neither my employer nor I accept any responsibility for viruses and it is your responsibility to scan attachments (if any). This email and any files transmitted are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify me by returning the email. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sniffer Sent: 15
Re: [sniffer] Smartermail
Hi Steve, You wrote: We are going to be moving to another mail package (you know why)... I would very much like to hear your comments about Imail and any difficulties you've encountered and why you feel the need to switch. You can write to me offline if you'd prefer. Thank you, Michael Stein Computer House [EMAIL PROTECTED] www.computerhouse.com This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Smartermail
If possible I'm interessed in this discussion me too Thank you Alberto -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Computer House Support Sent: mardi 15 mars 2005 17:20 To: sniffer@SortMonster.com Subject: Re: [sniffer] Smartermail Hi Steve, You wrote: We are going to be moving to another mail package (you know why)... I would very much like to hear your comments about Imail and any difficulties you've encountered and why you feel the need to switch. You can write to me offline if you'd prefer. Thank you, Michael Stein Computer House [EMAIL PROTECTED] www.computerhouse.com This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Smartermail
Whew man, that pretty much sums it up. It has always annoyed me that we spent almost $900.00 per year for what amounts to patch access. Functionally IMail has barely changed through the years and we have been using it since version 3.0. I really wonder what the heck is going on with Ipswitch. They didn't used to behave like this. Someone is clearly on an ego bender and I think that so much damage has already been done that even if they decided to rethink things it wouldn't matter to all the loyal customers they once had. William Van Hefner wrote: I think that for most of us it is because Ipswitch announced that they will no longer be selling Imail as a stand-alone product, and instead are trying to force us to upgrade to a product that costs thousands of dollars to upgrade to, hundreds of dollars each year more to license and is really nothing more than Imail and a couple of third-party software products that do not integrate whatsoever, and can be bought elsewhere separately for cheaper. Like they thought that we wouldn't notice! Their product suite was voted worst of breed in a recent magazine comparison of competing products, and the fact that one of their marketing directors told the entire Imail user base via its support mailing list that if they didn't like it, they should go elsewhere, was the last straw for many. Myself included. Why would I want to do business with a company that has does not care about its users opinions and tells them to go elsewhere? Oh, yeah, their support SUCKS as well. I can't remember how many times I have asked them to send me my PAID upgrade download code via e-mail, and they simply never answer. I pay hundreds of dollars a year, just so I can download the latest upgraded version, and they can't even manage to get that right. For $500 a year, I can't even get them to return a simple e-mail. For a company that is supposedly in the e-mail business, that speaks volumes. Bite me, Ipswitch! William Van Hefner President Vantek Communications, Inc. 555 H Street, Suite C Eureka, CA 95501 707.476.0833 ph 800.331.4638 fx -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Computer House Support Sent: Tuesday, March 15, 2005 8:20 AM To: sniffer@SortMonster.com Subject: Re: [sniffer] Smartermail Hi Steve, You wrote: We are going to be moving to another mail package (you know why)... I would very much like to hear your comments about Imail and any difficulties you've encountered and why you feel the need to switch. You can write to me offline if you'd prefer. Thank you, Michael Stein Computer House [EMAIL PROTECTED] www.computerhouse.com This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] mail to individuals within domain
On Tuesday, March 15, 2005, 1:36:31 PM, Rick wrote: RH All of a sudden today Sniffer has started taking emails sent between users RH within a single domain and putting them in our hold system. Any ideas why RH this might happen and also how I can add a rule so that does not become a RH problem on snifer for other domains? RH Thank you for the help in advance. RH Rick Hogue We will need to know the rule ID(s) that are causing the problem so that we can make an adjustment. Also, once you've identified the rule ID by matching the message to it's log entry (or entries) in the sniffer log you can enter the rule ID into your .cfg file as a rule-panic entry. This will immediately turn off that rule for your system while we track down the rule and make adjustments to your rulebase. What you are looking for here is the rule panic procedure: http://www.sortmonster.com/MessageSniffer/Help/FalsePositivesHelp.html#RulePanic Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Smartermail
Reading this from Ipswitch's site explains quite a bit, I think: Alex Neihaus Vice President, Marketing Alex Neihaus joined Ipswitch in April 2004 and brought with him a solid marketing background in collaboration, design and application software that aligns perfectly with the Ipswitch product lines. Neihaus joined Ipswitch from AccuRev, Inc., a software configuration management vendor, where as Vice President of Marketing he used integrated and focused marketing campaigns to differentiate the company from established competitors. Immediately prior, Neihaus led marketing efforts for Revit Technology, an architectural design software business, through its acquisition by Autodesk, Inc. He has also held management positions at IBM Corporation and Lotus Development Corp. Neihaus leads Ipswitchs global marketing efforts as the company expands its reach from small and mid-sized business to small enterprises. He is responsible for corporate communications as well as product marketing and Web-related marketing activities for the Ipswitch IMail Server, Ipswitch WhatsUp and Ipswitch WS_FTP product lines. Through his marketing leadership, Alex will ensure that businesses and individuals not currently using our software will discover the benefits we provide - practical, easy to use solutions that are powerful, yet comprehensible, and solve real-world problems. sniffer wrote: Whew man, that pretty much sums it up. It has always annoyed me that we spent almost $900.00 per year for what amounts to patch access. Functionally IMail has barely changed through the years and we have been using it since version 3.0. I really wonder what the heck is going on with Ipswitch. They didn't used to behave like this. Someone is clearly on an ego bender and I think that so much damage has already been done that even if they decided to rethink things it wouldn't matter to all the loyal customers they once had. William Van Hefner wrote: I think that for most of us it is because Ipswitch announced that they will no longer be selling Imail as a stand-alone product, and instead are trying to force us to upgrade to a product that costs thousands of dollars to upgrade to, hundreds of dollars each year more to license and is really nothing more than Imail and a couple of third-party software products that do not integrate whatsoever, and can be bought elsewhere separately for cheaper. Like they thought that we wouldn't notice! Their product suite was voted worst of breed in a recent magazine comparison of competing products, and the fact that one of their marketing directors told the entire Imail user base via its support mailing list that if they didn't like it, they should go elsewhere, was the last straw for many. Myself included. Why would I want to do business with a company that has does not care about its users opinions and tells them to go elsewhere? Oh, yeah, their support SUCKS as well. I can't remember how many times I have asked them to send me my PAID upgrade download code via e-mail, and they simply never answer. I pay hundreds of dollars a year, just so I can download the latest upgraded version, and they can't even manage to get that right. For $500 a year, I can't even get them to return a simple e-mail. For a company that is supposedly in the e-mail business, that speaks volumes. Bite me, Ipswitch! William Van Hefner President Vantek Communications, Inc. 555 H Street, Suite C Eureka, CA 95501 707.476.0833 ph 800.331.4638 fx -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Computer House Support Sent: Tuesday, March 15, 2005 8:20 AM To: sniffer@SortMonster.com Subject: Re: [sniffer] Smartermail Hi Steve, You wrote: We are going to be moving to another mail package (you know why)... I would very much like to hear your comments about Imail and any difficulties you've encountered and why you feel the need to switch. You can write to me offline if you'd prefer. Thank you, Michael Stein Computer House [EMAIL PROTECTED] www.computerhouse.com This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Moving Sniffer to Declude/SmarterMail
Pete OK, I now have much more information on this problem with Declude/Sniffer/SmarterMail. It seems the current version of Declude does not have an Overflow Directory for SmarterMail, which therefore allows unlimited Declude processes to be spawned at any time. At our peak we were seeing a surge of more than 1,000 declude.exe instances running at the same time! This of course flattened the server, and seems the reason why Sniffer was dropping out of its perpetual mode, unfortunately compounding the problem when the server had least resources. On speaking with Declude, thankfully they have been working on a version to control the number of processes running, and have let us have a BETA version which allows us to set the number of processes to a setting of our choice - we have it at 30 and it's working fine! One thing we did whilst in the middle of this was to move all the log and spool files to a standalone disk instead of the RAID5 array for the main server, and we have seen a real reduction in the physical disk queue lengths, which, under significant load, helps. Worth knowing. So the migration is complete with all users running as normal on SmarterMail instead of iMail. Hope some people can learn from our pain! Nick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: 14 March 2005 19:23 To: Nick Marshall Subject: Re: [sniffer] Moving Sniffer to Declude/SmarterMail On Monday, March 14, 2005, 12:47:33 PM, Nick wrote: NM Hi there NM We've just undergone a migration of a 1,000 domain iMail server to NM SmarterMail (for obvious reasons!), and using Declude and Sniffer on NM the new system. NM However, occasionally we see Sniffer jumping out of its perpetual NM mode by spawning thousands of threads which obviously make the NM server slow down considerably. Also, at this time, the Sniffer NM folder fills up with the equivalent temporary files. NM On changing the location of Sniffer in the Declude Global file and NM allowing the threads to disappear, when Sniffer is re-engaged it NM correctly goes back to perpetual mode working from the Service instance of Sniffer. NM Can any of the above be explained? This is extremely unusual and I've not heard of this kind of thing before. The closest connection I have seen is that on one very heavily loaded system (on Linux) a change in the rulebase file caused the persistent instance to pause for a few minutes while the message instances of SNF became impatient --- however in this case the system always recovered on it's own. In your case do you restart the persistent instance or does the system simply recover once you re-enable the clients? Please post the contents of your .stat file and let me know if these are typical values. Does your system have one or two CPUs? Hyperthreading? Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html -- [This e-mail was scanned for viruses by Giacom Anti-Virus] -- [This e-mail was scanned for viruses by Giacom Anti-Virus] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Moving Sniffer to Declude/SmarterMail
Thanks John - I didn't know that, but it would explain things... Nick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: 16 March 2005 14:40 To: sniffer@SortMonster.com Subject: RE: [sniffer] Moving Sniffer to Declude/SmarterMail One thing we did whilst in the middle of this was to move all the log and spool files to a standalone disk instead of the RAID5 array for the main server, and we have seen a real reduction in the physical disk queue lengths, which, under significant load, helps. Worth knowing. Nick It is a well known and published fact (on the Imail list) that RAID5 should never ever be used for the spool directory or any other directory that has a high write activity. This is basic physics. RAID5 should really only be used for high read activity only, such as databases where most of the writing is done to transaction (log) files and at spaced intervals those transactions are committed to the database. RAID1 or even RAID0+1 is best for the spool and logs. John Tolmachoff Engineer/Consultant/Owner eServices For You This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html -- [This e-mail was scanned for viruses by Giacom Anti-Virus] -- [This e-mail was scanned for viruses by Giacom Anti-Virus] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail
On Wednesday, March 16, 2005, 9:01:34 AM, Nick wrote: NM Pete NM OK, I now have much more information on this problem with NM Declude/Sniffer/SmarterMail. NM It seems the current version of Declude does not have an Overflow Directory NM for SmarterMail, which therefore allows unlimited Declude processes to be NM spawned at any time. At our peak we were seeing a surge of more than 1,000 NM declude.exe instances running at the same time! This of course flattened the NM server, and seems the reason why Sniffer was dropping out of its perpetual NM mode, unfortunately compounding the problem when the server had least NM resources. Thanks for this --- I think this proves one of my theories on the problem. This is what I think happened to SNF... A burst of 1000 or more active requests arrives which is more than the server can really handle at one time. The persistent server queues (internally) all of the jobs and begins processing them all at once. As a result, it does not report to the .stat file for an extended period. Also, due to the very large number of jobs, many of the client instances do not hear back from the server instance until their maximum wait time has expired. As a result, they abandon the wait and begin processing the messages themselves, each one now loading the rulebase. The clients loading the rulebase individually further slows the server and accelerates the problem until an insurmountable backlog is in place. Once the backlog is cleared (requiring manual intervention) the persistent instance (which has not died) is able to respond to client requests quickly enough so that they do not give up and so the system operates normally. --- If this fits the profile (and I think it does) then it would be possible to adjust SNF with an alternate fail-safe mode which would solve the problem at the expense of letting more spam through. Specifically, once a particular threshold is reached then the clients would abandon a job and fail safe rather than loading the rulebase and processing the message. This would cause spam to leak but it would also provide for a more rapid, automatic recovery. Think of it as a safety pressure valve on a boiler. It's not a great solution, but it's better than an explosion. The best answer is proper overflow control and since Declude is working on that I'm inclined to let that solution develop. Not only because it's a better solution, but also because the safety valve mechanism on SNF doesn't solve the whole problem - for example virus scanning would still potentially cause the same problem along with other things that might be running in Declude. Thanks Nick! _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Moving Sniffer to Declude/SmarterMail
John, It is a well known and published fact (on the Imail list) that RAID5 should never ever be used for the spool directory or any other directory that has a high write activity. This is basic physics. RAID5 should really only be used for high read activity only, such as databases where most of the writing is done to transaction (log) files and at spaced intervals those transactions are committed to the database. RAID1 or even RAID0+1 is best for the spool and logs. I guess this is going against what I think should be happening. In a RAID 5 array the write to the drives is broken into many smaller writes along with the data protection/CRC info and then those writes are written to different drives. It seems to me that it should be faster to do a bunch of small writes rather than 1 big write. What am I missing? Goran Jovanovic The LAN Shoppe This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] RAID level for spool
Even if you break it into smaller blocks, you still need to transfer the data to the controller, then the controller has to employ overhead to break up the block, create the parity information, determine the location for each block, etc. With RAID-1 the controller can just write through and duplicate the operation as is on the second bank. http://www.acnc.com/04_01_05.html vs. http://www.acnc.com/04_01_01.html RAID-1 has less overhead during writing. Since the spool folder probably has a 1:1 read/write ratio - it is sensitive to write performance. RAID-5 works well for write once - read many times applications, such as file and database servers. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: Goran Jovanovic Sent: Wednesday, March 16, 2005 11:26 AM I guess this is going against what I think should be happening. In a RAID 5 array the write to the drives is broken into many smaller writes along with the data protection/CRC info and then those writes are written to different drives. It seems to me that it should be faster to do a bunch of small writes rather than 1 big write. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Moving Sniffer to Declude/SmarterMail
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: 16. marts 2005 17:43 Writing data to a raid 5 takes x+y+z amount of work where y is described above and z is calculating a CRC stripe which must now also be saved to a hard drive. And from my understanding, calculating the CRC requires knowing both the data in the sector overwritten and the previous CRC data, and thus 2 reads. So thats 2 reads, and 2 writes to write a single block of data. Regards, Kaj This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail
OK that is for hardware level RAID. I had thought that you would offset the extra processing time by being able to write less to each drive. Now does anyone know how much overhead Windows 2000/2003 software RAID 1 on dynamic disks produces over hardware level RAID 1? I am assuming it would be substantial. Goran Jovanovic The LAN Shoppe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, March 16, 2005 11:43 AM To: Goran Jovanovic Subject: Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail On Wednesday, March 16, 2005, 11:25:46 AM, Goran wrote: snip/ GJ I guess this is going against what I think should be happening. In a GJ RAID 5 array the write to the drives is broken into many smaller writes GJ along with the data protection/CRC info and then those writes are GJ written to different drives. It seems to me that it should be faster to GJ do a bunch of small writes rather than 1 big write. GJ What am I missing? Writing data to a single hard drive takes x amount of work. Writing data to more than one drive takes x+y amount of work where y is breaking up the data into chunks. Writing data to a raid 5 takes x+y+z amount of work where y is described above and z is calculating a CRC stripe which must now also be saved to a hard drive. So, writing to raid5 is relatively very expensive compared to writing to a plain old hard drive, or a less complex raid (such as mirroring). IMO, the best strategy for email servers is to use an ordinary, single fast HD for all spool operations, and place mailboxes on a raid 1 or raid 10. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] RAID Levels for Spool Folder
Uh, sorry, I had thought that discussion was RAID-5 vs. RAID-1? If someone is running RAID-5, I assume that it's hardware based. If so, then that person could use the same hardware to configure a RAID-1 array instead - so why even bother with software RAID then? If the discussions is software RAID-1 vs. no-raid, then the answer is: Sure, software RAID is a cost effective solution if the system has sufficient head-room to deal with whatever possible overhead that may cause. However, if we are talking about a machine that is already taxed, then I would suggest plugging in a RAID controller instead of adding software RAID to the mix. I have several (older) systems running Windows 2000 RAID-1. At least ONE of the servers I later upgraded to Hardware RAID. I can't say that I've noticed any difference (but then again, I have not run benchmarks and the server was not really taxed before either.) From what I understand, there are many factors involved and it much depends on your systems configuration. CPU availability is critical. A server that is already CPU taxed may suffer if software RAID is added. Having the drives split on two SCSI controllers should also help with software RAID-1. Doing software RAID-1 with a master/slave ATA drive, however, may slow things down. There may not be a single answer... Best Regards Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goran Jovanovic Sent: Wednesday, March 16, 2005 02:05 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail OK that is for hardware level RAID. I had thought that you would offset the extra processing time by being able to write less to each drive. Now does anyone know how much overhead Windows 2000/2003 software RAID 1 on dynamic disks produces over hardware level RAID 1? This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail
Now does anyone know how much overhead Windows 2000/2003 software RAID 1 on dynamic disks produces over hardware level RAID 1? I am assuming it would be substantial. I have never noticed an issue, and I would only assume there would be an issue in higher end databases or where the CPU was already being tasked and near or at saturation by other processes. John Tolmachoff Engineer/Consultant/Owner eServices For You - This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] RAID Levels for Spool Folder
IMO, Software RAID is not the way to go on a busy machine. You will save a measurable amount of overhead by going with hardware based RAID of any sort since the controller should handle the processes associated with the RAID. Note that this isn't the case with inexpensive RAID controllers such as the cheaper IDE and SATA controllers which still place a fair burden on the OS/processor. True RAID cards also offer additional cache which can speed up the performance on reads, and also on writes if you are battery backed up (otherwise don't use write caching because you could lose or corrupt data during a power outage). There's also several common misconceptions about what is proper to do for a mail server. RAID 5 is the best choice under almost all conditions. The trick here is that while RAID 10 offers both redundancy in mirroring and speed in striping, most servers have a limited amount of space for disks. So a server with 6 disks will operate with the speed of 3 disks spanned in a RAID 10 configuration, but 6 disks in RAID 5 will operate as 5 disks spanned plus a little bit of overhead, though not nearly enough so that it falls short of the performance of just 3 disks in a simple span. Therefore RAID 5 should be the default choice for speed in such an environment. Another misconception is that data is always striped in RAID 0 or RAID 5. This depends on the file size and the stripe size. Most stripes are 64 KB (configurable in most setups). If you have some form of striping for your spool drive, most messages fall far under 64 KB and will only get written to one disk (CRC will also get written in RAID 5). Therefore for a spool folder, RAID 5 with 3 drives (the minimum), will perform rather closely to RAID 5 with 10 drives since most files will only land on one disk (with the other corresponding stripes containing no data). The MFT however for a drive with a lot of files will grow to be quite large and benefits from having multiple disks, and opening very large files such as logs will also benefit from having many disks. There is also an advantage to seek times when having multiple disks, especially if you keep your partitions sized small for performance. I've run a dual processor 3.06 Ghz server with both 6 Seagate 15,000 RPM drives in RAID 5 and the same with 3 Seagate 10,000 RPM drives in RAID 5 running on a less capable controller, and there was no impact on performance while the server was handling over 125,000 unique messages a day. The only noticeable difference was the time it would take to open a 500 MB log file, or the time it would take to enumerate the file names from the MFT on a partition that contained tens of thousands of files in the root. It seems quite apparent that with modern processors, even in dual processor configurations, that you will run out of CUP cycles long before you run out of disk I/O in a well managed RAID 5, 3 drive configuration on an IMail/Declude/Sniffer server. Take note that the log files for Declude, Sniffer and IMail all become massively fragmented, and if you don't have a process to remove these from active partitions on your server or defragment them, then performance will be severely impacted. I run a job hourly that copies all such logs to a different partition and combines them with older chucks from that day and then zips them nightly. The process of moving them to another logical drive removes the fragmentation and that helps to ensure that the spool or mailbox partitions/folders don't also become heavily fragmented, which is a big performance hit. Opening up a heavily fragmented 500 MB Declude log file is excruciatingly slow. If I kept the logs in my spool folder without taking action to handle the fragmentation, each Declude log file would reach over 100,000 fragments a day, and that's a lot of seek time. I would recommend just going to RAID 5 for everything, and buying an LSI or Adaptec card if doing SCSI, or one of the same including 3Ware if doing SATA or IDE. Based on my personal experience, I don't believe that you need to go over the top with anything, just the cheapest brand name card that can handle RAID 5 will do, even in a zero-channel configuration if your motherboard supports it. Ultra 160 SCSI RAID cards will also work just fine for all but the most demanding applications these days, so don't be afraid to pick one of the older models up from eBay. Also pay attention to the drives themselves, SCSI drives are made to be better and more dependable than most IDE or SATA drives, and the faster RPM's mean faster seek times as well, and different brands also require less CPU overhead. Only Western Digital seems willing to produce a server-class SATA drive, and this is because they are the only SATA drive maker that doesn't have a SCSI line that might be impacted. SCSI as a protocol also offers some things that still aren't commonly implemented in SATA that will improve performance in a RAID configuration, though that will change over time.
Re[4]: [sniffer] Moving Sniffer to Declude/SmarterMail
On Wednesday, March 16, 2005, 2:05:00 PM, Goran wrote: GJ OK that is for hardware level RAID. I had thought that you would offset GJ the extra processing time by being able to write less to each drive. GJ Now does anyone know how much overhead Windows 2000/2003 software RAID 1 GJ on dynamic disks produces over hardware level RAID 1? GJ I am assuming it would be substantial. This is difficult to quantify, but in my limited experience the difference in load between software RAID1 and hardware RAIDx is approximately the same as the difference between using IDE drives and using SCSI drives. SW RAID1 is not hard on the CPU except that it has to coordinate the write operations etc which leads to some extra queuing work/delays. With a good hardware based RAIDx the effect is that this coordination is handed off to the controller so the CPU spends more time doing actual work and less on managing the drive subsystem. This is roughly similar to the performance gain you get by going to a decent SCSI based system since SCSI systems have higher level communications protocols that generally allow the CPU to get on with other business in much the same way. In the end these choices are all about how much money you have and your performance goals. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] RAID Levels for Spool Folder
Matt, I think that you sort of answered the question that I did not really ask. I was really trying to get information on the different performance levels for of S/W vs H/W RAID for an ideal scanning only box. So let me try this out and people can comment All SCSI 15K drives with HW RAID controller 2 x 36 GB drives R1 on first channel (36 GB usable) C Windows 10 GB D IMAIL/Smartermail/Declude files/Declude filters per domain configs/banned files (5 days only) 20 GB P Page volume 3 GB 3 x 36 GB drives R5 on second channel (72 GB usable) L Logs for JM, Virus, IMAIL/SmarterMail, Sniffer, invURIBL, et al 10 GB S Storage for all daily logs 60 GB 1 x 36 GB Hot Spare drive From what we have discussed here drive L will get hit a lot. If you create a process that Matt is describing to move the active logs from L to S you should not worry about running out of space on the L drive. Now looking back I am not sure if I have crafted this well since the SPOOL files for IMAIL will end up on D. Is there a way to move them for Smartermail as there does not seem to be a way to move them in IMail? The good part of this config is that the spool files which have a lot of read/write are on a different volume/channel from the other log files. I am not sure what amount of space you should allocate to a server that would process 100,000+ messages a day? Anyone have comments on this config. Thanx Goran Jovanovic The LAN Shoppe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Wednesday, March 16, 2005 3:49 PM To: sniffer@SortMonster.com Subject: Re: [sniffer] RAID Levels for Spool Folder IMO, Software RAID is not the way to go on a busy machine. You will save a measurable amount of overhead by going with hardware based RAID of any sort since the controller should handle the processes associated with the RAID. Note that this isn't the case with inexpensive RAID controllers such as the cheaper IDE and SATA controllers which still place a fair burden on the OS/processor. True RAID cards also offer additional cache which can speed up the performance on reads, and also on writes if you are battery backed up (otherwise don't use write caching because you could lose or corrupt data during a power outage). There's also several common misconceptions about what is proper to do for a mail server. RAID 5 is the best choice under almost all conditions. The trick here is that while RAID 10 offers both redundancy in mirroring and speed in striping, most servers have a limited amount of space for disks. So a server with 6 disks will operate with the speed of 3 disks spanned in a RAID 10 configuration, but 6 disks in RAID 5 will operate as 5 disks spanned plus a little bit of overhead, though not nearly enough so that it falls short of the performance of just 3 disks in a simple span. Therefore RAID 5 should be the default choice for speed in such an environment. Another misconception is that data is always striped in RAID 0 or RAID 5. This depends on the file size and the stripe size. Most stripes are 64 KB (configurable in most setups). If you have some form of striping for your spool drive, most messages fall far under 64 KB and will only get written to one disk (CRC will also get written in RAID 5). Therefore for a spool folder, RAID 5 with 3 drives (the minimum), will perform rather closely to RAID 5 with 10 drives since most files will only land on one disk (with the other corresponding stripes containing no data). The MFT however for a drive with a lot of files will grow to be quite large and benefits from having multiple disks, and opening very large files such as logs will also benefit from having many disks. There is also an advantage to seek times when having multiple disks, especially if you keep your partitions sized small for performance. I've run a dual processor 3.06 Ghz server with both 6 Seagate 15,000 RPM drives in RAID 5 and the same with 3 Seagate 10,000 RPM drives in RAID 5 running on a less capable controller, and there was no impact on performance while the server was handling over 125,000 unique messages a day. The only noticeable difference was the time it would take to open a 500 MB log file, or the time it would take to enumerate the file names from the MFT on a partition that contained tens of thousands of files in the root. It seems quite apparent that with modern processors, even in dual processor configurations, that you will run out of CUP cycles long before you run out of disk I/O in a well managed RAID 5, 3 drive configuration on an IMail/Declude/Sniffer server. Take note that the log files for Declude, Sniffer and IMail all become massively fragmented, and if you don't have a process to remove these from active partitions on your server or defragment them, then performance will be severely impacted. I run a job hourly that copies all such logs to a different partition and combines them with older
Re: [sniffer] RAID Levels for Spool Folder
I would just RAID 5 the whole setup. With your 6 drives, you get the read performance of 4 drives on any partition in this setup, plus you have a hot spare, and the write performance of close to 4 drives as well. This is a lot better than your config with a mirrored set of drives and a RAID 5 array that reads and writes at about the capacity of two. You will definitely get more bang for your buck with it all being one RAID 5 array, and you get much better redundancy that way as well. As far as splitting things up, there are only 4 things that I feel need to be separate: 1) OS and Executables 2) Spool 3) Mail Boxes 4) Log File Archive Some may split them up further, but I don't think it would have any real effect. The reasons for splitting things up is primarily for the purpose of fragmentation. Your OS and Executables should be mostly static so long as you don't log to that partition, and it might be more advantageous to have all executables on one partition rather than two or more in terms of seek time. The fact that Windows caches frequently accessed files mitigates the effect here so that you probably won't notice the improvement of having everything all together on one partition, so you can do that to taste if you wish. The Spool will get very heavily fragmented, and it is the best place to log to since IMail can't be made to log elsewhere, by Declude and other applications can be made to log there instead of under the IMail tree. Only Sniffer can't be told to log elsewhere at this time, but thankfully the log is not as heavily fragmented as others due to it's comparatively small size. The Mail Boxes should also go on their own partition because of fragmentation, and also for personal preference of organization. They don't get heavily fragmented, but you also don't want to have the spool on the same partition contributing to the fragmentation. The Log File Archive is just simply better on it's own partition since you want to move the files from one partition to another in order to remove the fragmentation. Sizing the partitions is also very important. The outer edges of the disks will run at twice the read and write rates of the inner edges, and if all of your most frequently accessed files are closest to the outer edge there is less seek time, so having your most active partitions nearest the outer edge will improve performance. You do this by not being wasteful with the partition sizes. I put all applications, including IMail and associated programs, along with the page file and OS on the C drive and this is the first logical drive in the array. I am now sizing the primary partition at 20 GB, though you could probably get away with 10 GB. Take note of the page file's max size and the fact that the temp directory is on this drive and things like zipping and unzipping files make use of the temp directory, so you need some extra space. I make the D drive my Web drive (might not be necessary for your setup) and that is quite small. The E drive is for Mail Boxes and I gave it 5 times the actual space in use at this time for growth. The F drive is the Spool, which is 5 GB on my server, and allows for some play in the event that my log archiving mechanism goes bust without me noticing. Then I also have separate small partitions, G and H, for both viruses and held spam, primarily due to the number of files and the size of the MFT, and you don't want this mixed with things on an active partition IMO. Then I have a Log File Archive partition on I which is essentially all the left over space on the array. Here's a summary: C: OS and Executables - 10 GB to 20 GB D: Web - 1 GB E: Mail Boxes - 5 GB F: Spool + Logging - 5 GB G: Spam - 2 GB H: Viruses - 2 GB I: Log Archive - Everything that is left if you wish. I also of course have other devices for storing software and backups that aren't part of the array. With a RAID 5 + Hot spare config, assuming 36 GB drives, you can pack all of the most active stuff into the outer edges of the disks and get screaming performance. Having a large log file archive nearest the center of the platters will have virtually no impact since they would be rarely accessed. Besides the performance gains, you really must consider the redundancy. The fact that in such a setup, you could lose 1 drive and still run at full speed after a period of automatic rebuilding, and lose 2 drives and run at half speed, which would still be plenty, and it would take 3 drives failing to bring your box down...well, that's the reliability that one should want. Like I said earlier, I've done over 125,000 unique messages a day with a sizable Declude setup, Sniffer, two virus scanners, and some Declude helper apps written in VBScript on a server with 3 x 10,000 RPM drives on a zero-channel Adaptec controller with 48 MB of read cache (no write cache) and it had absolutely no issues. That server also ran MS SMTP as the primary gateway along with VamSoft's ORF doing address validation, so
Re[2]: [sniffer] RAID Levels for Spool Folder
Hello Matt, Wednesday, March 16, 2005, 11:44:08 PM, you wrote: M I would just RAID 5 the whole setup. With your 6 drives, you M get the read performance of 4 drives on any partition in this M setup, plus you have a hot spare, and the write performance of M close to 4 drives as well. This is a lot better than your config M with a mirrored set of drives and a RAID 5 array that reads and M writes at about the capacity of two. You will definitely get more M bang for your buck with it all being one RAID 5 array, and you get M much better redundancy that way as well. M As far as splitting things up, there are only 4 things that I feel need to be separate: M 1) OS and Executables M 2) Spool M 3) Mail Boxes M 4) Log File Archive I have to agree with Matt, I run a single RAID 5 array with 7, 7200 RPM SATA disks for my mail server, and I see between 250K and 325K daily messages. My main differences are, I use a 3Ware EIDE RAID card for a RAID 1 on two 80GB disks for OS and Software, the big RAID is for Spool, Mailboxes and Logs, and I delete logs after 10 days. In almost 9 years of running an ISP, I have had only a couple of instances of needing logs beyond 3 or 4 days. When you only have a 3 disk RAID 5 I can definately see that there is a write performance hit, but that is why your RAID controller has a processor and cache, a good RAID controller can minimize the hit. On a larger array, say 6 drives, your data is split into 4 data blocks and 2 parity blocks, so the same write operation is twice as fast, you have twice as many spindles, no major disadvantage to the original proposal of a 3 disk RAID 5, 2 disk RAID 1, and single store disk, but you gain an added level of redundancy. I would throw a little bit of money into RAM and forget worrying so much about a paging partition, I have 2GB of RAM and only use a total of about 250MB RAM and Paging, with a very occasional jump to 500MB when things go wrong. Most anything in the Page file will not have any critical performance impact on your system. If you don't already have the drives and controller, you can also look at the Western Digital Raptor SATA disks, they are the only 10,000 RPM SATA disks. I also like the #Ware controllers, mine is the 8000 series, but 9000 series should be out now, and have a considerable performance edge. -- Best regards, Charlesmailto:[EMAIL PROTECTED] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] RAID Levels for Spool Folder
Matt and Charles, Thank you for your insight and comments. Now I just have to go and get the money to get something that I want :) Goran Jovanovic The LAN Shoppe This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Money, drugs, and sex
http://www.sophos.com/spaminfo/articles/spamwords.html Interesting, but a pity they didn't publish a list of, say, their 1,000 most popular obfuscations. Andrew 8) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] mini-obfuscation
Wow, Pete! Wow. I didn't feel I could measure up to adding on to that thread, so I started over. Although the search space is theoretically huge (you pointed out the marketecture of large numbers), in practice, the spammers mostly use the grains quite close to the marble and use the grains over again for a while. How many times have we all been frustrated that a piece of spam ending up in *OUR* mailbox that was s close in content to spam we whacked yesterday? I thought the top n obfuscations might be interesting to look at, and perhaps a shortcut (temporary, albeit) for spam catching. I thought we might see whether, for example, broken URLs, fake comments, or high-bit ASCII character substitutions were the obfuscation technique du jour. I while back curiousity got the better of me (it was raining, and I had a few days off) and I did a few grep sweeps on a warm spam corpus. I was disappointed in my success rate for: v.?i.?a.?g.?r.?a.? and similar queries with deliberately substitutions (e.g. using a 1 for i). I started writing a grep-generating-permutation engine and decided my time was better spent on scritching my cat under his chin. Of course, I have a lot more time for my cat since I implemented Sniffer. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, March 22, 2005 4:37 PM To: Colbeck, Andrew Subject: Re: [sniffer] Money, drugs, and sex On Tuesday, March 22, 2005, 4:47:30 PM, Andrew wrote: CA http://www.sophos.com/spaminfo/articles/spamwords.html CA Interesting, but a pity they didn't publish a list of, say, their CA 1,000 most popular obfuscations. If you do the math then 1000 wouldn't even scratch it. One way to attack this ( at least one of the ways we do it in Message Sniffer ) is to apply some obfuscation algorithms to each word in the list using some generic expansion patterns -- this helps to simplify the problem a bit. For example, one obfuscation algorithm is to insert a single extra character in the word. If you take the word obfuscation and apply this expansion algorithm you get something like: o~bfuscation ob~fuscation obf~uscation ... obfuscatio~n where ~ represents any random character. Then think about adding two characters... ... ob~fusc~ation ... Then think about breaking the word with an empty anchor at any of the places where you would insert a character... ... obfusa href=http://yo-mama.it;/acation ... and so on... Of course, you can't simply apply all of the possible obfuscation algorithms, and you can't completely exercise each one that you do try... you have to pick and choose and learn as you go because otherwise you would simply never finish the job. *** If you iterate through all of the permutations and count them then the numbers become astronomical... as in viagra can be obfuscated (and detected by their fine software) more than 5,600,000,000 different ways ahem. That's market speak for look how powerful our software is -whoooah! This is similar to a lot of other AI problems too and it's probably why I'm involved since I love AI work. In most AI problems if you add up all of the possible solutions to the problem you usually come up with a number you couldn't possibly write down without writing the formula instead. That is, the number would be so large that you would probably die of old age before you actually finished writing all the digits. In the AI world we talk about this huge sea of possibilities as a solution space. If you tried to check every possible solution one by one until you found the best answer it would take you forever. This is called a brute force attack. It's also what makes the big numbers seem impressive, and what makes most encryption schemes work.### Since we don't usually have forever, we do something else in the AI world. We use algorithms to search the solution space for the best answer. That is, rather than just going through the possible solutions one at a time as we come to them (brute force) we try to figure out which ones to look at and which ones to skip. The way we make that decision is to use an algorithm that leverages special rules of thumb (heuristics) to help us search the solution space more efficiently. This effectively reduces the solution space and makes it possible to come up with an answer that is good enough+++ within the time we have. So, when they talk about recognizing more than 5 billion different obfuscated forms of the word viagra they are really just estimating how many of the permutations their heuristics are able to eliminate from the solution space. (A more accurate way to think about it might be that a single heuristic for a particular obfuscated word covers a large amount of the solution space all at once. Since it's already been covered it doesn't have to be searched -- the extra work is eliminated as compared to a brute-force attack.) For example: Suppose you have a sandbox into which someone has
RE: [sniffer] Money, drugs, and sex
You truly are a mad scientist - But we love ya! :) Matt MaxNett Ltd T.08701 624 989 F.08701 624 889 www.maxnett.co.uk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: 23 March 2005 00:37 To: Colbeck, Andrew Subject: Re: [sniffer] Money, drugs, and sex On Tuesday, March 22, 2005, 4:47:30 PM, Andrew wrote: CA http://www.sophos.com/spaminfo/articles/spamwords.html CA Interesting, but a pity they didn't publish a list of, say, their CA 1,000 most popular obfuscations. If you do the math then 1000 wouldn't even scratch it. One way to attack this ( at least one of the ways we do it in Message Sniffer ) is to apply some obfuscation algorithms to each word in the list using some generic expansion patterns -- this helps to simplify the problem a bit. For example, one obfuscation algorithm is to insert a single extra character in the word. If you take the word obfuscation and apply this expansion algorithm you get something like: o~bfuscation ob~fuscation obf~uscation ... obfuscatio~n where ~ represents any random character. Then think about adding two characters... ... ob~fusc~ation ... Then think about breaking the word with an empty anchor at any of the places where you would insert a character... ... obfusa href=http://yo-mama.it;/acation ... and so on... Of course, you can't simply apply all of the possible obfuscation algorithms, and you can't completely exercise each one that you do try... you have to pick and choose and learn as you go because otherwise you would simply never finish the job. *** If you iterate through all of the permutations and count them then the numbers become astronomical... as in viagra can be obfuscated (and detected by their fine software) more than 5,600,000,000 different ways ahem. That's market speak for look how powerful our software is -whoooah! This is similar to a lot of other AI problems too and it's probably why I'm involved since I love AI work. In most AI problems if you add up all of the possible solutions to the problem you usually come up with a number you couldn't possibly write down without writing the formula instead. That is, the number would be so large that you would probably die of old age before you actually finished writing all the digits. In the AI world we talk about this huge sea of possibilities as a solution space. If you tried to check every possible solution one by one until you found the best answer it would take you forever. This is called a brute force attack. It's also what makes the big numbers seem impressive, and what makes most encryption schemes work.### Since we don't usually have forever, we do something else in the AI world. We use algorithms to search the solution space for the best answer. That is, rather than just going through the possible solutions one at a time as we come to them (brute force) we try to figure out which ones to look at and which ones to skip. The way we make that decision is to use an algorithm that leverages special rules of thumb (heuristics) to help us search the solution space more efficiently. This effectively reduces the solution space and makes it possible to come up with an answer that is good enough+++ within the time we have. So, when they talk about recognizing more than 5 billion different obfuscated forms of the word viagra they are really just estimating how many of the permutations their heuristics are able to eliminate from the solution space. (A more accurate way to think about it might be that a single heuristic for a particular obfuscated word covers a large amount of the solution space all at once. Since it's already been covered it doesn't have to be searched -- the extra work is eliminated as compared to a brute-force attack.) For example: Suppose you have a sandbox into which someone has thrown a marble. If you have to find the marble then you could estimate all of the grains of sand you would have to examine in order to find it. Let's see... for a sandbox that is 3 meters on a side and 10 cm deep that would be... (scratches head, punches on calculator, looks at watch, gives up...) a Sagan of sand grains. (I fondly remember Dr. Carl Sagan talking about astronomical numbers like this when talking about the cosmos.) So, to find the marble in the sandbox without individually picking up each grain of sand then we'll need some tools (algorithms) to help us reduce the problem. We could also use a heuristic to help us reduce the problem further... Let's do this: 1) Get a bucket, a screen with holes smaller than a marble but larger than a few grains of sand, and a shovel. 2) Use a stick to draw lines on the sandbox and divide it into a grid where each square is about the size of our bucket. 3) Skipping all of the squares where the sand is smooth and undisturbed do the following: 4) Shovel all of the sand from a disturbed square into the bucket, then sift the bucket of sand back into its' square using the screen. 5)
Re: [sniffer] mini-obfuscation
On Tuesday, March 22, 2005, 8:31:07 PM, Andrew wrote: snip/ CA How many times have we all been frustrated that a piece of spam ending CA up in *OUR* mailbox that was s close in content to spam we whacked CA yesterday? CA I thought the top n obfuscations might be interesting to look at, and CA perhaps a shortcut (temporary, albeit) for spam catching. I thought we CA might see whether, for example, broken URLs, fake comments, or high-bit CA ASCII character substitutions were the obfuscation technique du jour. Here you hit it IMHO. The reality appears to be, from my experience, that small domains of obfuscation patterns rise and fall like swells on the ocean. That is, stability tends to arise in one domain of message characteristics and then fall to rise in another domain. Sometimes the domain is well understood and sometimes it is entirely new and forces us to think differently about what a feature really is. By domain I mean things like message structure, word obfuscation techniques, phrase based swapping, html exploitation, etc... The du jour part of your statement is a key element to the problem. Defining and re-defining the conceptual framework that describes feature domains in the spam is the other key element. Put more simply - knowing what to look for is a basic element, but it gets you nowhere on it's own. Knowing (recognizing) when to look for the what is the key that makes the problem workable. CA I while back curiousity got the better of me (it was raining, and CA I had a few days off) and I did a few grep sweeps on a warm spam CA corpus. CA I was disappointed in my success rate for: CA v.?i.?a.?g.?r.?a.? CA and similar queries with deliberately substitutions (e.g. using a 1 CA for i). I started writing a grep-generating-permutation engine and CA decided my time was better spent on scritching my cat under his chin. That is a nifty direction that I wish I had more time for. Perhaps I will some day soon when Sniffer get's slashdotted and sales go through the roof! --- meantime, back on this planet, I suggested a very similar thing to Paul Graham at the first spam conference at MIT. As I recall he said it was ambitious - a description that I have learned has a special meaning in scientific circles. Something having to do with avian swine and snowballs that have successful careers as tour guides in hell. One of these days I think I might do it anyway, just to prove the point, but in the mean time I too prefer to spend more time with my cat. ;-) Don't get me wrong - I strongly believe it can be done this way, but it requires much more than good technology. It runs right into one of the biggest problems with AI and, perhaps more importantly, people's expectations of AI. No matter how good the pattern learning system might be it will always lack the human experience. Computers don't date or gain weight - so they have a hard time understanding what much of the spam is about simply by looking at the patterns. That's why the Message Sniffer process is designed with people tightly integrated into the system. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] mini-obfuscation
Pete,
Doesnt Sniffer have a certain level of support for regex's? I know we have
had good luck with regex's like this which catch obfuscation techniques with
viagra with Declude. We found it easier to use regex's than to list all of
the different variations.
(?:\b|\s)[_\W]{0,3}(?:\\\/|V)[_\W]{0,3}[ij1!|l\xEC\xED\xEE\xEF][_\W]{0,3}[a4
[EMAIL PROTECTED],3}[xyz]?[gj][_\W]{0,3}r[_\W]{0,[EMAIL PROTECTED],
3}x?[_\W]{0,3}(?:\b|\s)
Darrell
Check out http://www.invariantsystems.com for utilities for Declude And
Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG
Integration, and Log Parsers.
Pete McNeil writes:
On Tuesday, March 22, 2005, 8:31:07 PM, Andrew wrote:
snip/
CA How many times have we all been frustrated that a piece of spam ending
CA up in *OUR* mailbox that was s close in content to spam we whacked
CA yesterday?
CA I thought the top n obfuscations might be interesting to look at, and
CA perhaps a shortcut (temporary, albeit) for spam catching. I thought we
CA might see whether, for example, broken URLs, fake comments, or high-bit
CA ASCII character substitutions were the obfuscation technique du jour.
Here you hit it IMHO. The reality appears to be, from my experience,
that small domains of obfuscation patterns rise and fall like swells
on the ocean. That is, stability tends to arise in one domain of
message characteristics and then fall to rise in another domain.
Sometimes the domain is well understood and sometimes it is entirely
new and forces us to think differently about what a feature really
is.
By domain I mean things like message structure, word obfuscation
techniques, phrase based swapping, html exploitation, etc...
The du jour part of your statement is a key element to the problem.
Defining and re-defining the conceptual framework that describes
feature domains in the spam is the other key element.
Put more simply - knowing what to look for is a basic element, but it
gets you nowhere on it's own. Knowing (recognizing) when to look for
the what is the key that makes the problem workable.
CA I while back curiousity got the better of me (it was raining, and
CA I had a few days off) and I did a few grep sweeps on a warm spam
CA corpus.
CA I was disappointed in my success rate for:
CA v.?i.?a.?g.?r.?a.?
CA and similar queries with deliberately substitutions (e.g. using a 1
CA for i). I started writing a grep-generating-permutation engine and
CA decided my time was better spent on scritching my cat under his chin.
That is a nifty direction that I wish I had more time for. Perhaps I
will some day soon when Sniffer get's slashdotted and sales go through
the roof!
--- meantime, back on this planet, I suggested a very similar thing to
Paul Graham at the first spam conference at MIT. As I recall he said
it was ambitious - a description that I have learned has a special
meaning in scientific circles. Something having to do with avian swine
and snowballs that have successful careers as tour guides in hell.
One of these days I think I might do it anyway, just to prove the
point, but in the mean time I too prefer to spend more time with my
cat. ;-)
Don't get me wrong - I strongly believe it can be done this way, but
it requires much more than good technology. It runs right into one of
the biggest problems with AI and, perhaps more importantly, people's
expectations of AI. No matter how good the pattern learning system
might be it will always lack the human experience. Computers don't
date or gain weight - so they have a hard time understanding what much
of the spam is about simply by looking at the patterns. That's why
the Message Sniffer process is designed with people tightly integrated
into the system.
_M
This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] mini-obfuscation
On Wednesday, March 23, 2005, 6:04:10 PM, Darrell wrote:
Dsic Pete,
Dsic Doesnt Sniffer have a certain level of support for regex's? I know we
have
Dsic had good luck with regex's like this which catch obfuscation techniques
with
Dsic viagra with Declude. We found it easier to use regex's than to list all
of
Dsic the different variations.
Dsic
(?:\b|\s)[_\W]{0,3}(?:\\\/|V)[_\W]{0,3}[ij1!|l\xEC\xED\xEE\xEF][_\W]{0,3}[a4
Dsic [EMAIL PROTECTED],3}[xyz]?[gj][_\W]{0,3}r[_\W]{0,[EMAIL PROTECTED],
Dsic 3}x?[_\W]{0,3}(?:\b|\s)
The compiler and scanner we use has a limited regex capability. Some
of the features you've used here were kept out of the engine on
purpose. Later versions of the engine (under development) will have
some more of these features - eventually including all of the features
found on most regex systems, and then moving beyond them.
Slick regex patterns like the one you have here are often useful for
describing patterns, but not always as useful for rapidly developing
and modifying dynamic pattern matching schemes.
For example - the regex you have stated here will match a wide range
of permutations in a single statement. That is, after all, a strength
of regex. However in practice it is often found that most of the
possible patterns simply are never seen in the wild or that some
specific variations might be problematic... In these cases it is
better to use a small catalog of simpler patterns because they can be
implemented and understood incrementally, and they can be very easily
excluded on a one-by-one basis if needed. Adding that kind of
flexibility to the regex you have here could make it even more
difficult to understand and correctly encode --- since we have a very
small staff creating and modifying hundreds of rules per day seconds
count. I have to admit that it would take me a few minutes to
completely understand what the above regex really does - and chances
are that if I modified it I would be much more likely to introduce an
error than I would using our more simplified coding scheme.
That's not to say that we won't be introducing more complex pattern
matching capabilities - we certainly will. However, the syntax for
these rules will be less concerned with an economy of keystrokes and
more concerned with reliable, rapid generation and modification.
For example, the coding system we have planned will be able to break
down the pattern you've represented into a number of functional units
that can be mixed and re-used in a hierarchical structure. This will
allow both the robots and the humans to understand and manipulate the
patterns very easily.
Regex (as written) is a good way to represent some patterns
efficiently - but it has the down side that the syntax can be
arbitrarily difficult and that does not naturally represent conceptual
structures that might be found in the patterns to be matched and
readily reused.
Best,
_M
This E-Mail came from the Message Sniffer mailing list. For information and
(un)subscription instructions go to
http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Spam Submissions - same spam
A question: If I have the same spam sent to multiple recipients, should I be submitting more than one copy to [EMAIL PROTECTED]?
Re: [sniffer] Spam Submissions - same spam
On Thursday, March 24, 2005, 11:00:56 AM, Scott wrote: SF A question: SF SF If I have the same spam sent to multiple recipients, should SF I be submitting more than one copy to [EMAIL PROTECTED] If you mean there are multiple recipients in the SMTP envelope then we only need one copy. If there are separate envelopes then chances are there will be subtle changes that we can use - so please send each one. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Porn Spam again
Anyway that sniffer could trigger on this type of stuff? Blonde Tit Licked By Black Guy On Backseat blonde whore screws three guys Adorable Blond Teen Hardcore Blowjob Dark Haierd Abbes Suck Big Black Dick 3some Movies Pornstar Brandi Lyons Hardcore On Couch Movies -- Cordially, Heimir Eidskrem i360, Inc. 2825 Wilcrest, Suite 675 Houston, TX 77042 Ph: 713-981-4900 Fax: 832-242-6632 [EMAIL PROTECTED] www.i360.net www.i360hosting.com www.realister.com Houston's Leading Internet Consulting Company This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Porn Spam again
On Monday, March 28, 2005, 2:09:52 PM, Heimir wrote: HE Anyway that sniffer could trigger on this type of stuff? snip/ Yes. The bad news is that this stuff is highly variable and so more of it gets through than we would like. The good news is that we are developing filters to deal with it by capturing small fragments and phrases so that they cannot be reused. For example, I created 7 new rules based on the note use sent - each containing 2-5 word phrases and fragments. The hard part is to avoid blocking legitimate messages - so we can't generally code on single words. For example hardcore and it's variations has a high porn spam score, but it is also widely used in current language. The word suck by itself is not a workable solo and neither is that random combination of hardcore an suck (though you might be tempted)... A quick look at any extreme sports article readily yields many of these words. You could opt to create some black rules that contain simple combinations or even single words like these if you have a sufficiently narrow demographic on your system. In the mean time we will continue to aggressively create rules for the safe combinations we can spot and/or predict. Of course, we always capture URI in these cases when available. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Porn Spam again
Just an FYI from my perspective. As things stand, Sniffer false positives on dirty language is one of the top 5 types of FP's that I see with Sniffer. It's not a huge problem, but I definitely wouldn't want to see any more of it. While some companies do not have an issue with blocking dirty language even if legitimate, this is not wise to do in a global sense. Thankfully Pete does allow for rulebase customization so that customers that want this type of blocking can have it. Due to the variability of the messages, it is also generally better to tag the URL or another pattern rather than the phrases that might be used. I'm generally happy with how Sniffer picks up new URL's and updates rulebases to block this stuff, but they will get through on occasion no matter what you do because as soon as you start tagging word patterns, the spammer changes those patterns or obfuscates in some other way. No matter what however, every piece of spam needs a payload, which is generally a link, E-mail address or phone number. Matt Pete McNeil wrote: On Monday, March 28, 2005, 2:09:52 PM, Heimir wrote: HE Anyway that sniffer could trigger on this type of stuff? snip/ Yes. The bad news is that this stuff is highly variable and so more of it gets through than we would like. The good news is that we are developing filters to deal with it by capturing small fragments and phrases so that they cannot be reused. For example, I created 7 new rules based on the note use sent - each containing 2-5 word phrases and fragments. The hard part is to avoid blocking legitimate messages - so we can't generally code on single words. For example hardcore and it's variations has a high porn spam score, but it is also widely used in current language. The word suck by itself is not a workable solo and neither is that random combination of hardcore an suck (though you might be tempted)... A quick look at any extreme sports article readily yields many of these words. You could opt to create some black rules that contain simple combinations or even single words like these if you have a sufficiently narrow demographic on your system. In the mean time we will continue to aggressively create rules for the safe combinations we can spot and/or predict. Of course, we always capture URI in these cases when available. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] SmarterMail
Anybody out there using SmarterMail with multiple IP's (like 50 or more) bound to one or more NIC's? -- Best Regards, Steve Oren President ServerSide, Inc. 317-596-5000 voice 317-596-5010 fax 888-682-2544 toll free www.serverside.net This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Persistent Sniffer
I noticed in the archives about a .cfg file one can configure for use when running Persistent sniffer. How do you download it or obtain it? Thanks for the aid. Keith This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Persistent Sniffer
On Wednesday, March 30, 2005, 4:08:35 PM, Keith wrote: KJ I noticed in the archives about a .cfg file one can configure for use KJ when running Persistent sniffer. How do you download it or obtain it? KJ Thanks for the aid. You can find a sample .cfg file in the latest distribution. If you don't already have a .cfg then chances are your .exe file won't understand it anyway ;-) You can always find the latest distribution on this page: http://www.sortmonster.com/MessageSniffer/Try-It.html Best, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Persistent Sniffer
On Wednesday, March 30, 2005, 10:50:36 PM, Keith wrote: KJ Pete, KJThanks for the follow-up. I was monitoring the KJ filename.persistent.stat file that yields stats as messages are KJ processed. Is it normal for it to every now and then flash [File KJ is Empty], thus no stats at all. Usually within a few seconds KJ stats would appear again. Thanks again, This usually means that you were reading the file just as it was being written. When the file is output it is opened with O_TRUNC to truncate the file so it can be replaced. If you read it at that moment you will see nothing so this is normal. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Persistent Sniffer
On Friday, April 1, 2005, 8:04:27 AM, Keith wrote: KJ I have read forum results that this behavior is the reverse of KJ what should happen, I should get a reduction in CPU. I did this KJ around 11pm last night, usually during peak times this server KJ would stay at 65% load. Is there anything I can tweak to install KJ the Sniffer persistent server and achieve desired results? Thanks KJ for the aid. Can you share more about your server's configuration and can you also post the .stat file that was produced? Server OS? Server CPU(s)? Drive System(s)? Mail Server SW? _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] Persistent Sniffer
Pete, Thanks for the reply. Running on an IBM Xseries 225 Dual Xeon 2.4Ghz w/ 1GB RAM - running IBM's ServerRAID 5i in IBM's RAID 10 config (4 73GB 10K drives) - O/S is Windows 2000 Standard Server SP4 Running Imail 8.15HF1 with Declude JM/Virus 1.82 - BIND DNS Server is 1 hop away (on switch backbone). I had to drop back to the non-persistent mode, thus the .stat file disappeared. I will run it again tonight and copy the file away and post it here tonight. Thanks again for the time and aid. Keith Johnson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, April 01, 2005 11:17 AM To: Keith Johnson Subject: Re[2]: [sniffer] Persistent Sniffer On Friday, April 1, 2005, 8:04:27 AM, Keith wrote: KJ I have read forum results that this behavior is the reverse of what KJ should happen, I should get a reduction in CPU. I did this around KJ 11pm last night, usually during peak times this server would stay at KJ 65% load. Is there anything I can tweak to install the Sniffer KJ persistent server and achieve desired results? Thanks for the aid. Can you share more about your server's configuration and can you also post the .stat file that was produced? Server OS? Server CPU(s)? Drive System(s)? Mail Server SW? _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[4]: [sniffer] Persistent Sniffer
On Friday, April 1, 2005, 11:44:07 AM, Keith wrote: KJ Pete, KJ Thanks for the reply. KJ Running on an IBM Xseries 225 Dual Xeon 2.4Ghz w/ 1GB RAM - KJ running IBM's ServerRAID 5i in IBM's RAID 10 config (4 73GB 10K drives) KJ - O/S is Windows 2000 Standard Server SP4 KJ Running Imail 8.15HF1 with Declude JM/Virus 1.82 - BIND DNS KJ Server is 1 hop away (on switch backbone). I had to drop back to the KJ non-persistent mode, thus the .stat file disappeared. I will run it KJ again tonight and copy the file away and post it here tonight. KJ Thanks again for the time and aid. I don't see any problems with this setup. Your description sounds like your server is fairly heavily loaded (35-55% cpu in peer-server mode), though I would expect more from the hardware you've described. I suspect that you may have run into the far side of the power curve when you went to persistent server mode. In peer-server mode the failure mode for overload conditions is much softer than with the persistent peer server mode. Up to the failure point in the power curve the persistent server mode will provide a significant savings over peer-server, however once that point is reached the persistent server mode tends to degrade much more quickly and requires a significant drop in load before recovery occurs. I'm working on some strategies to soften that curve a bit, but in the mean time let's explore these options to get the best performance from your server and reduce it's load. The we can see if the persistent server engine will give you even more headroom: 1. I recommend running AVAFTERJM - are you doing this? Typically 80% or more of email traffic is spam and so there is no good reason to attempt a virus scan on these messages. If you hold messages and occasionally re-insert them into the queue then they will not be scanned, however there are ways to work around this when needed - and it is very likely you would not re-insert a message that contained a virus anyway. 2. Consider running bind as a dns resolver on your mail server and pointing the server to itself via the loopback address (127.0.0.1) for DNS services. This tends to speed up processing significantly which also reduces the number of message processes that are running at any given time. YMMV, but I have seen this work consistently to improve performance. --- when trying persistent mode (minor adjustments really) --- A. Set the Persistence value in your snflicid.cfg file to 3600. - no need to check for a new rulebase every 10 minutes usually. These loop events tear down the server momentarily which can perturb an otherwise smooth running system when under heavy loads - thus minimizing the frequency of these events may help. B. Set LogFormat in your snflicid.cfg file to SingleLine. This provides sufficient data for our purposes (most of the time) and should significantly reduce the size of your log file. C. Be sure to keep any unnecessary files out of the SNF working directory - in particular you should clean out any orphaned files that might still be lurking from previous crashes. --- General --- Be sure your drives are regularly defragmented. Hope this helps, _M PS: I just had another random thought really --- Could it be that the high CPU value was appropriate? If you had built up a queue of messages to be processed then once the persistent server was put in place and the system started processing messages again the CPU would probably be much higher for a period of time until all of the backlog had been eliminated. The persistent server would do its best to nail up at least one of the CPUs until this was accomplished, so looking at the CPU load during that period might not be the best way to understand the situation. The CPU load would not drop back down again until the backlog had be eliminated. In comparison to the persistent server mode, the peer-server mode imposes a greater restriction on message throughput and puts a higher load on IO due to repeatedly loading the rulebase file. This can have the effect of reducing the overall CPU load at the expense of raw throughput under some circumstances. This, in fact, explains why the peer-server mode has a softer performance failure curve than the persistent server mode (in theory). Put another way, sometimes the peer-server mode prevents the CPU from getting out of it's own way to scan the messages - so the CPU load looks lower because it spends more time waiting. In these cases putting the persistent server in place has the effect of removing the obstacles so the CPU works harder and the messages go through faster. A better way to judge might be to check the overflow queue... the rate at which it is being emptied (or slowness at which it grows) would indicate a better throughput and that is probably the better goal. -- just a random thought. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to
RE: Re[4]: [sniffer] Persistent Sniffer
Pete, Wow, thank you for the explanation. I did let the persistent server run for 30 min after I restarted the services. However, I did stop the services, then started Sniffer service, then restart Imail services. I could have gotten a backlog of retries at that moment that pegged the CPU as you stated. We have batted around running BIND for NT/2000 on the local machine, but my fear was overhead of another major process running. I don't have any good stats on how much CPU/Memory BIND on an Imail Server requires, thus, we have a SUN/BIND box local to the switch. Are you aware of any stats on this? We don't run the AVAFTERJM switch. This is done in part due to so many of our customers still look at their spam email from time to time. We heavily use the ROUTETO and MAILBOX command, thus, if I let a virus go through to their to mailbox, they could potentially open a virus spam email and hurt themselves. We defrag each partition every night using Diskeeper and it works great. I regularly look at the Sniffer directory to ensure no left over .fin files and others that could cause server load. I will retry it again tonight and see what type of results I get and post them here. It could be as you say, I am on the far side :) Thanks again, Keith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, April 01, 2005 2:16 PM To: Keith Johnson Subject: Re[4]: [sniffer] Persistent Sniffer On Friday, April 1, 2005, 11:44:07 AM, Keith wrote: KJ Pete, KJ Thanks for the reply. KJ Running on an IBM Xseries 225 Dual Xeon 2.4Ghz w/ 1GB RAM - KJ running IBM's ServerRAID 5i in IBM's RAID 10 config (4 73GB 10K KJ drives) KJ - O/S is Windows 2000 Standard Server SP4 KJ Running Imail 8.15HF1 with Declude JM/Virus 1.82 - BIND DNS KJ Server is 1 hop away (on switch backbone). I had to drop back to KJ the non-persistent mode, thus the .stat file disappeared. I will KJ run it again tonight and copy the file away and post it here tonight. KJ Thanks again for the time and aid. I don't see any problems with this setup. Your description sounds like your server is fairly heavily loaded (35-55% cpu in peer-server mode), though I would expect more from the hardware you've described. I suspect that you may have run into the far side of the power curve when you went to persistent server mode. In peer-server mode the failure mode for overload conditions is much softer than with the persistent peer server mode. Up to the failure point in the power curve the persistent server mode will provide a significant savings over peer-server, however once that point is reached the persistent server mode tends to degrade much more quickly and requires a significant drop in load before recovery occurs. I'm working on some strategies to soften that curve a bit, but in the mean time let's explore these options to get the best performance from your server and reduce it's load. The we can see if the persistent server engine will give you even more headroom: 1. I recommend running AVAFTERJM - are you doing this? Typically 80% or more of email traffic is spam and so there is no good reason to attempt a virus scan on these messages. If you hold messages and occasionally re-insert them into the queue then they will not be scanned, however there are ways to work around this when needed - and it is very likely you would not re-insert a message that contained a virus anyway. 2. Consider running bind as a dns resolver on your mail server and pointing the server to itself via the loopback address (127.0.0.1) for DNS services. This tends to speed up processing significantly which also reduces the number of message processes that are running at any given time. YMMV, but I have seen this work consistently to improve performance. --- when trying persistent mode (minor adjustments really) --- A. Set the Persistence value in your snflicid.cfg file to 3600. - no need to check for a new rulebase every 10 minutes usually. These loop events tear down the server momentarily which can perturb an otherwise smooth running system when under heavy loads - thus minimizing the frequency of these events may help. B. Set LogFormat in your snflicid.cfg file to SingleLine. This provides sufficient data for our purposes (most of the time) and should significantly reduce the size of your log file. C. Be sure to keep any unnecessary files out of the SNF working directory - in particular you should clean out any orphaned files that might still be lurking from previous crashes. --- General --- Be sure your drives are regularly defragmented. Hope this helps, _M PS: I just had another random thought really --- Could it be that the high CPU value was appropriate? If you had built up a queue of messages to be processed then once the persistent server was put in place and the system started processing messages again the CPU would
Re: [sniffer] Persistent Sniffer
Keith, Windows DNS service will handle over a million lookups a day without blinking. There should be no reason to switch to a different DNS server. It hardly even registers any CPU load on my boxes. The biggest CPU hog is the virus scanners, and choosing your virus scanners carefully will have a great benefit. F-Prot is the champ followed by ClamAV in daemon mode (the non-daemon is a hog), followed by McAfee at a distant third, though there are many others that are far worse. The AVAFTERJM switch will stop most messages from being virus scanned and hence the magic there, however if you don't delete any messages with JunkMail there is no real advantage. I'm not clear on whether or not the ROUTETO will bypass scanning, but you could create some filters using VBScript to tag messages with attachments associated with viruses and handle them differently. Personally, I haven't found a huge impact from running Sniffer in persistent mode, but it does have a slightly measurable effect on my server. If you are hurting for disk I/O or memory, this could help immensely. If you are running into an issue with disk I/O, it could back things up significantly. Also, if you have any domains where the addresses aren't validated (nobody aliases or gateway domains), this could easy be attacked in such a way so that it overwhelmed your server. We are presently only validating for about 2/3 of our customer base and this morning the address validation software/service failed an automatic restart and it allowed everything through to IMail/Declude and it pegged our server at 100% until it was turned back on. Normally at that time of day, our server runs at an average of about 25% (and it will get better when the other 1/3 becomes validated). BODY and ANYWHERE filters in Declude can also be huge hogs if you don't limit them to a reasonable level. I probably have about 1,500 lines of BODY filters and that isn't causing me any real issues but I am also using SKIPIFWEIGHT and other methods of skipping such filters when it isn't beneficial to run them. Managing my Declude filtering better definitely helped me steal back some CPU. Placing Sniffer in persistent mode definitely shouldn't cause things to slow down unless maybe it was configured improperly. I use the same SERVANY setup that you said that you are using and it has worked flawlessly for me since the day that Pete released that functionality. I am thinking that you might want to scrutinize your setup. Hope that this helps. Matt Keith Johnson wrote: Pete, Wow, thank you for the explanation. I did let the persistent server run for 30 min after I restarted the services. However, I did stop the services, then started Sniffer service, then restart Imail services. I could have gotten a backlog of retries at that moment that pegged the CPU as you stated. We have batted around running BIND for NT/2000 on the local machine, but my fear was overhead of another major process running. I don't have any good stats on how much CPU/Memory BIND on an Imail Server requires, thus, we have a SUN/BIND box local to the switch. Are you aware of any stats on this? We don't run the AVAFTERJM switch. This is done in part due to so many of our customers still look at their spam email from time to time. We heavily use the ROUTETO and MAILBOX command, thus, if I let a virus go through to their to mailbox, they could potentially open a virus spam email and hurt themselves. We defrag each partition every night using Diskeeper and it works great. I regularly look at the Sniffer directory to ensure no left over .fin files and others that could cause server load. I will retry it again tonight and see what type of results I get and post them here. It could be as you say, I am on the far side :) Thanks again, Keith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, April 01, 2005 2:16 PM To: Keith Johnson Subject: Re[4]: [sniffer] Persistent Sniffer On Friday, April 1, 2005, 11:44:07 AM, Keith wrote: KJ Pete, KJ Thanks for the reply. KJ Running on an IBM Xseries 225 Dual Xeon 2.4Ghz w/ 1GB RAM - KJ running IBM's ServerRAID 5i in IBM's RAID 10 config (4 73GB 10K KJ drives) KJ - O/S is Windows 2000 Standard Server SP4 KJ Running Imail 8.15HF1 with Declude JM/Virus 1.82 - BIND DNS KJ Server is 1 hop away (on switch backbone). I had to drop back to KJ the non-persistent mode, thus the .stat file disappeared. I will KJ run it again tonight and copy the file away and post it here tonight. KJ Thanks again for the time and aid. I don't see any problems with this setup. Your description sounds like your server is fairly heavily loaded (35-55% cpu in peer-server mode), though I would expect more from the hardware you've described. I suspect that you may have run into the far side of the power curve when you went to
Re[6]: [sniffer] Persistent Sniffer
On Friday, April 1, 2005, 3:37:33 PM, Keith wrote: snip/ KJ pegged the CPU as you stated. We have batted around running BIND KJ for NT/2000 on the local machine, but my fear was overhead of KJ another major process running. I don't have any good stats on how KJ much CPU/Memory BIND on an Imail Server requires, thus, we have a KJ SUN/BIND box local to the switch. Are you aware of any stats on KJ this? No hard data on hand, however a back of the envelope calculation suggests that you probably have a good chunk of ram left - and that this will probably expand if you can retire messages more quickly -- that has a tendency to speed up everything since everything has more room etc. I've never heard a bad experience with this approach, and I have proven it several times on otherwise overwhelmed machines. Paradoxically, for example, my woefully underpowered P2/450 will choke if I don't run bind locally - even if the DNS server it points at is on the a hot, dedicated box on the same switch. The minute I put bind on the same box as the server it recovers nicely. KJ We don't run the AVAFTERJM switch. This is done in part due to KJ so many of our customers still look at their spam email from time to KJ time. We heavily use the ROUTETO and MAILBOX command, thus, if I let a KJ virus go through to their to mailbox, they could potentially open a KJ virus spam email and hurt themselves. Understood. What about prescan? KJ We defrag each partition every night using Diskeeper and it KJ works great. I regularly look at the Sniffer directory to ensure no KJ left over .fin files and others that could cause server load. Sounds good - I like Diskeeper too - won't run a Winx box without it. KJ I will KJ retry it again tonight and see what type of results I get and post them KJ here. It could be as you say, I am on the far side :) Thanks Good Luck, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[8]: [sniffer] Persistent Sniffer
Pete, Yes the file is changing every few seconds or sooner. Sorry, I just did a 'grab' of it and posted. The 307 is due to me stopping it after 30 min or so and altering the few changes to the .conf file. I will continue to monitor it over the weekend. However, so far so good. Thanks again for taking the time to help out. Keith -Original Message- From: [EMAIL PROTECTED] on behalf of Pete McNeil Sent: Fri 4/1/2005 10:18 PM To: Keith Johnson Cc: Subject: Re[8]: [sniffer] Persistent Sniffer On Friday, April 1, 2005, 9:36:05 PM, Keith wrote: KJ Pete/Matt/Andrew, KJ Thanks for all your wonderful input. Maybe I didn't KJ give it a fair shake or time enough as mentioned by Pete earlier. KJ I turned it on again about 30 min ago and have seen my system KJ stable, currently it is: KJTicToc: 1112391330 KJ Loop: 264 KJ Poll: 445 KJ Jobs: 290 KJ Secs: 307 KJ Msg/Min: 56.6775 KJ Current-Load: 21.4724 KJ Average-Load: 22.4706 KJ These numbers were up around 120 Msg/Min and Current KJ Load at 90+CPU is aver. about 17% right now. However, could KJ be skewed a bit since it is Friday night. I will continue to KJ watch it over the weekend and see how it goes. Still considering KJ running Win DNS local or BIND 9.3 for NT/2000/2003. Have a great KJ weekend. Hrmmm Something here doesn't add up. Is the .stat file changing every second or so? If not then the persistent engine has stopped. In fact, 307 seconds is scarcely 5 minutes - not 30. It appears that at the time you sampled the file your system was happily humming along at about 1 msg/sec... which is a lul for you. Remember that your average would be about 1.7 messages per second. I also note that the load and poll time indicated a good deal of dead air so the system was definitely not working hard at the time. Take a look at it again and make sure that the .stat file changes every 1-4 seconds or so. If not then the persistent server has stopped - at least the client instances will see it that way. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html winmail.dat
Re[10]: [sniffer] Persistent Sniffer
On Saturday, April 2, 2005, 1:07:56 PM, Andrew wrote: CA Pete, your metaphors are wonderful. :-) snip/ CA If I remember correctly, the MaxPollTime was originally much lower. I CA now use the full 4 seconds, but I don't know how often that's needed. I CA easily see Declude processes taking longer than this, sometimes at 100% CA of my CPU (with Task Manager update speed set to High) In persistent mode the max poll time does not matter. It would only matter if the system fell back into peer-server mode. With persistent mode the client instances coordinate their timing with the server instance based on the data in the .stat file. CA I also set Lifetime to 0 (because I don't expect the service to need CA stopping), and Persistence to 12 hours. I'm hedging my bet with CA Persistence, because I normally expect a twice daily rulebase update, CA and my update mechanism should initiate a reload. This seems fine given that you issue reload with your updates. However, you should know that udpates are generally much more frequent than every 12 hours. More in the range of every 5 hours or so at this time. Best, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] MDLP Tests
Hello - I am reviewing your MDLP report at http://www.sortmonster.com/MDLP/MDLP-Example-Long.html, and find some tests that are seemingly quite effective that I'm not familiar with. If anyone has any informaiton about these tests, please let me know: - FABEL (is this the same as FABELSOURCES at http://www.declude.com/Articles.asp?ID=97Redirected=Y?) - MXRATE-* - UCEPROTEC* Also, perhaps I am misunderstanding the data, but SNIFFER has a SQ of .802 - isn't that relatively bad ? Thanks! - Jay Sudowski // Handy Networks LLC Director of Technical Operations Providing Shared, Reseller, Semi Managed and Fully Managed Windows 2003 Hosting Solutions Tel: 877-70 HANDY x882 | Fax: 888-300-2FAX www.handynetworks.com http://www.handynetworks.com/ This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] MDLP Tests
On Saturday, April 2, 2005, 4:09:31 PM, Jay wrote: JSHNL Hello - JSHNL I am reviewing your MDLP report at JSHNL http://www.sortmonster.com/MDLP/MDLP-Example-Long.html, and find some JSHNL tests that are seemingly quite effective that I'm not familiar with. If JSHNL anyone has any informaiton about these tests, please let me know: JSHNL - FABEL (is this the same as FABELSOURCES at JSHNL http://www.declude.com/Articles.asp?ID=97Redirected=Y?) FABEL ip4rspamsources.fabel.dk127.0.0.2 JSHNL - MXRATE-* MXRATE-BLACKip4rpub.mxrate.net 127.0.0.2 MXRATE-WHITEip4rpub.mxrate.net 127.0.0.3 MXRATE-SUSP ip4rpub.mxrate.net 127.0.0.4 JSHNL - UCEPROTEC* UCEPROTECRDOip4rdnsbl-1.uceprotect.net 127.0.0.2 UCEPROTECCMUL ip4rdnsbl-2.uceprotect.net 127.0.0.2 UCEPROTECCVIR ip4rdnsbl-3.uceprotect.net 127.0.0.2 JSHNL Also, perhaps I am misunderstanding the data, but SNIFFER has a SQ of JSHNL .802 - isn't that relatively bad ? Actually, that's the hyper-accuracy penalty at work. I wrote a bunch about that on the MDLP page. What's going on is that SNF frequently catches spam that virtually no other tests are catching yet and as a result the total weight never reaches the threshold. Every one of those events shows up counting against it. We research these periodically (we used to look at them constantly) and with very rare exceptions we find that these are not false positives. In fact, on our systems last year SNF had fewer than 10 FP. (several of those were messages from customers that actually contained examples of spam, malware, or logs with spammy URI). Of course, our numbers are a more than bit skewed because the vast majority of traffic on our system is spam... so we can't use that to calculate a false positive rate that has any real meaning. The closest we can really get to an indication of false positive rates from SNF is to point at our FP rate page: http://www.sortmonster.com/MessageSniffer/Performance/FalseReportsRates.jsp This page shows counts of all false positives reported to us on a daily basis for all of our customers. At least two of these systems are service providers with 10 or more licenses which submit false positives automatically as they are reported from their customers. So anyway, the short answer is that the SA and SQ values on the SNIFFER tests are skewed by the hyper-accuracy penalty inherent in how MDLP develops these scores. The true accuracy values are very much higher and this is regularly confirmed by both hard reviews of the data and anecdotal evidence from our customers. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] MDLP Tests
Ahh, that makes more sense now. ham is just what does not pass the spam threshold. In this light, if Sniffer is hyper accurate and catches more real spam than all others, it will appear less accurate overall because of the deficienes in the other tests. For some reason, I was thinking that ham was being calculated differently. Thanks for the tests, as well. -Jay PS - I did read your stuff about hyper-accuracy, but everything wasn't meshing for me, hence my question :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Saturday, April 02, 2005 4:43 PM To: Jay Sudowski - Handy Networks LLC Subject: Re: [sniffer] MDLP Tests On Saturday, April 2, 2005, 4:09:31 PM, Jay wrote: JSHNL Hello - JSHNL I am reviewing your MDLP report at JSHNL http://www.sortmonster.com/MDLP/MDLP-Example-Long.html, and find JSHNL some tests that are seemingly quite effective that I'm not JSHNL familiar with. If anyone has any informaiton about these tests, please let me know: JSHNL - FABEL (is this the same as FABELSOURCES at JSHNL http://www.declude.com/Articles.asp?ID=97Redirected=Y?) FABEL ip4rspamsources.fabel.dk127.0.0.2 JSHNL - MXRATE-* MXRATE-BLACKip4rpub.mxrate.net 127.0.0.2 MXRATE-WHITEip4rpub.mxrate.net 127.0.0.3 MXRATE-SUSP ip4rpub.mxrate.net 127.0.0.4 JSHNL - UCEPROTEC* UCEPROTECRDOip4rdnsbl-1.uceprotect.net 127.0.0.2 UCEPROTECCMUL ip4rdnsbl-2.uceprotect.net 127.0.0.2 UCEPROTECCVIR ip4rdnsbl-3.uceprotect.net 127.0.0.2 JSHNL Also, perhaps I am misunderstanding the data, but SNIFFER has a JSHNL SQ of JSHNL .802 - isn't that relatively bad ? Actually, that's the hyper-accuracy penalty at work. I wrote a bunch about that on the MDLP page. What's going on is that SNF frequently catches spam that virtually no other tests are catching yet and as a result the total weight never reaches the threshold. Every one of those events shows up counting against it. We research these periodically (we used to look at them constantly) and with very rare exceptions we find that these are not false positives. In fact, on our systems last year SNF had fewer than 10 FP. (several of those were messages from customers that actually contained examples of spam, malware, or logs with spammy URI). Of course, our numbers are a more than bit skewed because the vast majority of traffic on our system is spam... so we can't use that to calculate a false positive rate that has any real meaning. The closest we can really get to an indication of false positive rates from SNF is to point at our FP rate page: http://www.sortmonster.com/MessageSniffer/Performance/FalseReportsRates. jsp This page shows counts of all false positives reported to us on a daily basis for all of our customers. At least two of these systems are service providers with 10 or more licenses which submit false positives automatically as they are reported from their customers. So anyway, the short answer is that the SA and SQ values on the SNIFFER tests are skewed by the hyper-accuracy penalty inherent in how MDLP develops these scores. The true accuracy values are very much higher and this is regularly confirmed by both hard reviews of the data and anecdotal evidence from our customers. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] MDLP Tests
Jay, here's more web information on the mxrate tests: http://www.mxrate.com/lookup/dns.htm Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Saturday, April 02, 2005 1:43 PM To: Jay Sudowski - Handy Networks LLC Subject: Re: [sniffer] MDLP Tests On Saturday, April 2, 2005, 4:09:31 PM, Jay wrote: JSHNL Hello - JSHNL I am reviewing your MDLP report at JSHNL http://www.sortmonster.com/MDLP/MDLP-Example-Long.html, and find JSHNL some tests that are seemingly quite effective that I'm not JSHNL familiar with. If anyone has any informaiton about these tests, JSHNL please let me know: JSHNL - FABEL (is this the same as FABELSOURCES at JSHNL http://www.declude.com/Articles.asp?ID=97Redirected=Y?) FABEL ip4rspamsources.fabel.dk127.0.0.2 JSHNL - MXRATE-* MXRATE-BLACKip4rpub.mxrate.net 127.0.0.2 MXRATE-WHITEip4rpub.mxrate.net 127.0.0.3 MXRATE-SUSP ip4rpub.mxrate.net 127.0.0.4 JSHNL - UCEPROTEC* UCEPROTECRDOip4rdnsbl-1.uceprotect.net 127.0.0.2 UCEPROTECCMUL ip4rdnsbl-2.uceprotect.net 127.0.0.2 UCEPROTECCVIR ip4rdnsbl-3.uceprotect.net 127.0.0.2 JSHNL Also, perhaps I am misunderstanding the data, but SNIFFER has a JSHNL SQ of .802 - isn't that relatively bad ? Actually, that's the hyper-accuracy penalty at work. I wrote a bunch about that on the MDLP page. What's going on is that SNF frequently catches spam that virtually no other tests are catching yet and as a result the total weight never reaches the threshold. Every one of those events shows up counting against it. We research these periodically (we used to look at them constantly) and with very rare exceptions we find that these are not false positives. In fact, on our systems last year SNF had fewer than 10 FP. (several of those were messages from customers that actually contained examples of spam, malware, or logs with spammy URI). Of course, our numbers are a more than bit skewed because the vast majority of traffic on our system is spam... so we can't use that to calculate a false positive rate that has any real meaning. The closest we can really get to an indication of false positive rates from SNF is to point at our FP rate page: http://www.sortmonster.com/MessageSniffer/Performance/FalseReportsRates. jsp This page shows counts of all false positives reported to us on a daily basis for all of our customers. At least two of these systems are service providers with 10 or more licenses which submit false positives automatically as they are reported from their customers. So anyway, the short answer is that the SA and SQ values on the SNIFFER tests are skewed by the hyper-accuracy penalty inherent in how MDLP develops these scores. The true accuracy values are very much higher and this is regularly confirmed by both hard reviews of the data and anecdotal evidence from our customers. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Notice: Potential outages tonight...
I have not had any messages from the list since the 3rd of March. What is happening on the list? Rick Hogue Intent.Net - Web Hosting 3802 Handley Avenue Louisville, KY 40218 1-502-459-3100 1-800-866-2983 Toll Free New Books Available Prosperity Or Better Times Ten Hot Slot Secrets The Incredible Inman's Louisville Trivia Challenge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, March 03, 2005 2:30 PM To: sniffer@sortmonster.com Subject: [sniffer] Notice: Potential outages tonight... Hello Sniffer Folks, There will be some work on the core router system tonight. This may result in short, intermittent outages. We do not expect any major interruptions. Since Message Sniffer runs locally on your system you should not be effected. However, you may have trouble reaching our web site, uploading logs or downloading rulebases if this happens during one of these short outages. We apologize in advance for any inconvenience. Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Notice: Potential outages tonight...
On Saturday, April 9, 2005, 1:27:51 PM, Rick wrote: RH I have not had any messages from the list since the 3rd of March. What is RH happening on the list? The list has been very quiet. I got your message twice - once from you directly and once from the list. This seems correct based on your headers ;-) _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[4]: [sniffer] Notice: Potential outages tonight...
On Saturday, April 9, 2005, 1:58:45 PM, Rick wrote: RH Yes but that really seems strange when I was getting 4 to 10 messages every RH day. Now I did not get any since the 3rd of March right after you announced RH that there would be the outage? You may want to check into this closer. I'm very sure that's not related... The router switch was a note from our colo provider where we run the web server. However, the mail server(s) are on entirely different systems so they would not have been effected. A quick look at the archives shows that we definitely have some messages since Mar 3. I have no other reports of problems with the list. I'm not sure what else to look for on this end - the messages would not have made it into the archives if there were anything generally wrong here. You might check your logs against some of the recent messages in the archives to see if you can spot anything. If you discover anything please let me know. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Latest medication campaign
I am seeing a lot of these get through John T eServices For You This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Latest medication campaign
On the weekend and since, I saw a lot of them get through but Sniffer was dutifully catching them, unfortunately, they also served to highlight Sniffer hyperaccuracy because those messages just weren't reaching my HOLD weight. Check out the Message Sniffer change rates for the last few days: http://www.sortmonster.com/MessageSniffer/Performance/ChangeRates.jsp Something is definitely going on. On Sunday, the blue line was almost the entire New Rule group. It started me thinking about making Sniffer my hold weight, and then only applying counterweights. Meanwhile, I've added SURBL-ish testing with a tiny Declude weight, but with a combo of the new test and any Sniffer hit, that seems to have made the difference. I've only seen 1 undeliverable end up in the postmaster box, and I've fixed why that happened (I set my skipweight for various Declude filter text tests too low, so they weren't getting run when the weight was close to my HOLD weight). So now it's back to the server room for me. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Wednesday, April 13, 2005 10:16 AM To: sniffer@SortMonster.com Subject: [sniffer] Latest medication campaign I am seeing a lot of these get through John T eServices For You This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Latest medication campaign
I noticed a significantly higher amount of spam get through in the last few days. A few of them got tagged but didn't reach my delete weight. I didn't notice if the majority were pharmaceuticals. I forwarded them all to Sniffer, then . . . DELETE. G.Z. - Original Message - From: Colbeck, Andrew [EMAIL PROTECTED] To: sniffer@SortMonster.com Sent: Wednesday, April 13, 2005 12:36 PM Subject: RE: [sniffer] Latest medication campaign On the weekend and since, I saw a lot of them get through but Sniffer was dutifully catching them, unfortunately, they also served to highlight Sniffer hyperaccuracy because those messages just weren't reaching my HOLD weight. Check out the Message Sniffer change rates for the last few days: http://www.sortmonster.com/MessageSniffer/Performance/ChangeRates.jsp Something is definitely going on. On Sunday, the blue line was almost the entire New Rule group. It started me thinking about making Sniffer my hold weight, and then only applying counterweights. Meanwhile, I've added SURBL-ish testing with a tiny Declude weight, but with a combo of the new test and any Sniffer hit, that seems to have made the difference. I've only seen 1 undeliverable end up in the postmaster box, and I've fixed why that happened (I set my skipweight for various Declude filter text tests too low, so they weren't getting run when the weight was close to my HOLD weight). So now it's back to the server room for me. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Wednesday, April 13, 2005 10:16 AM To: sniffer@SortMonster.com Subject: [sniffer] Latest medication campaign I am seeing a lot of these get through John T eServices For You This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Latest medication campaign
On Wednesday, April 13, 2005, 1:16:29 PM, John wrote: JTL I am seeing a lot of these get through Can you be specific about these ? Please send me a sipped plaintext or message file. (to [EMAIL PROTECTED]) Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Latest medication campaign
Something I noticed about these. They are all using RE: or FW: and in the body they have the original message line. SpamCheck had a line the CheckWords giving negative 25 to that line. As such, SpamCheck was giving an overall weight of -19 which was taking away from everything else the message was failing. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Wednesday, April 13, 2005 10:36 AM To: sniffer@SortMonster.com Subject: RE: [sniffer] Latest medication campaign On the weekend and since, I saw a lot of them get through but Sniffer was dutifully catching them, unfortunately, they also served to highlight Sniffer hyperaccuracy because those messages just weren't reaching my HOLD weight. Check out the Message Sniffer change rates for the last few days: http://www.sortmonster.com/MessageSniffer/Performance/ChangeRates.jsp Something is definitely going on. On Sunday, the blue line was almost the entire New Rule group. It started me thinking about making Sniffer my hold weight, and then only applying counterweights. Meanwhile, I've added SURBL-ish testing with a tiny Declude weight, but with a combo of the new test and any Sniffer hit, that seems to have made the difference. I've only seen 1 undeliverable end up in the postmaster box, and I've fixed why that happened (I set my skipweight for various Declude filter text tests too low, so they weren't getting run when the weight was close to my HOLD weight). So now it's back to the server room for me. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Wednesday, April 13, 2005 10:16 AM To: sniffer@SortMonster.com Subject: [sniffer] Latest medication campaign I am seeing a lot of these get through John T eServices For You This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Latest medication campaign
Attached is something that I coded up last night for this guy. It's designed to be not totally dependant on one pattern so that it might have some longevity. His forging of a Microsoft format is quite good, but he does make mistakes and does leave patterns, some of which can be tagged with a standard Declude filter, but VBScript could do it even better and even less specifically. Nevertheless, this filter hits 100% of the time right now, levies very heavy points despite being variable, and I haven't seen a false positive yet due to the way that it was designed to operate. Note, the scores are based on a system that holds at a score of 10. Matt --- Global.cfg --- FORGEDPILLSPAMMERfilter C:\IMail\Declude\Filters\ForgedPillSpammer.txtx50 -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = # FORGEDPILLSPAMMER v1.0.0 SKIPIFWEIGHT40 MINWEIGHTTOFAIL 5 # Disable when it comes from an IP that is in the MX record just for safety since this targets zombies. TESTSFAILED END NOTCONTAINS IPNOTINMX # Prerequisites for spam pattern. Note that the spammer is near perfect for the headers. HEADERS END NOTCONTAINS X-MimeOLE: Produced By Microsoft MimeOLE V HEADERS END NOTCONTAINS To: HEADERS END NOTCONTAINS From: BODYEND NOTCONTAINS !DOCTYPE BODYEND NOTCONTAINS This is a multi-part message in MIME format. # X-Unsent header is not something that you see in E-mail after it leaves Outlook. HEADERS 1 CONTAINSX-Unsent: 1 # Microsoft should insert a double line break before the end of the text and the start of the boundary. BODY3 CONTAINS. --=_NextPart_ # Start of boundary is always the same recently. BODY3 CONTAINSNextPart_000_0008_01C53DE2. # Original Message within a tag. BODY1 CONTAINS- Original Message - # Dead giveaway for Pharmacy spam (non-obfuscated part). BODY3 CONTAINSyByMail BODY3 CONTAINSBy-Mail # This line is too long for Outlook in quoted-printable format. BODY3 CONTAINSMETA http-equiv=3DContent-Type content=3Dtext/html; charset=3Dus-ascii META content # Uses tables for obfuscation. BODY3 CONTAINSTDFONT face=3DArial size=3D4/FONT/TD TD rowSpan=3D2FONT face=3DArial size=3D4 # Subject is always Re:. HEADERS 1 CONTAINSSubject: Re: # Body does text/html as us-ascii. BODY1 CONTAINSContent-Type: text/html; charset=us-ascii # Body contains empty Style tags. BODY1 CONTAINSSTYLE/STYLE
Re: [sniffer] Latest medication campaign
Quick update. I found a few false positives (about 1 in 50,000 messages) and as a result I modified things a little and added a few more checks for supposedly rather unique patterns. The new version is attached. Unless there is a problem I probably won't update it any more, but I felt that it was a good idea to share the update to prevent the possibility of problems. The new version is attached. Matt Matt wrote: Attached is something that I coded up last night for this guy. It's designed to be not totally dependant on one pattern so that it might have some longevity. His forging of a Microsoft format is quite good, but he does make mistakes and does leave patterns, some of which can be tagged with a standard Declude filter, but VBScript could do it even better and even less specifically. Nevertheless, this filter hits 100% of the time right now, levies very heavy points despite being variable, and I haven't seen a false positive yet due to the way that it was designed to operate. Note, the scores are based on a system that holds at a score of 10. Matt --- Global.cfg --- FORGEDPILLSPAMMERfilter C:\IMail\Declude\Filters\ForgedPillSpammer.txtx50 -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = # FORGEDPILLSPAMMER v1.0.1 SKIPIFWEIGHT40 MINWEIGHTTOFAIL 5 # Disable when it comes from an IP that is in the MX record just for safety since this targets zombies. TESTSFAILED END NOTCONTAINS IPNOTINMX # Prerequisites for spam pattern. Note that the spammer is near perfect for the headers. HEADERS END NOTCONTAINS X-MimeOLE: Produced By Microsoft MimeOLE V HEADERS END NOTCONTAINS To: HEADERS END NOTCONTAINS From: BODYEND NOTCONTAINS !DOCTYPE BODYEND NOTCONTAINS This is a multi-part message in MIME format. # X-Unsent header is not something that you see in E-mail after it leaves Outlook. HEADERS 1 CONTAINSX-Unsent: 1 # Microsoft should insert a double line break before the end of the text and the start of the boundary. BODY1 CONTAINS. --=_NextPart_ BODY2 CONTAINSday. --=_NextPart_ # Start of boundary is always the same recently. BODY3 CONTAINSNextPart_000_0008_01C53DE2. BODY3 CONTAINSNextPart_000_0008_01C54072 # Original Message within a tag. BODY1 CONTAINS DIV style=3DFONT: 10pt arial- Original Message - # Dead giveaway for Pharmacy spam (non-obfuscated part). BODY3 CONTAINSyByMail BODY3 CONTAINSBy-Mail BODY3 CONTAINSByMAlL BODY1 CONTAINSBy MAIL S # This line is too long for Outlook in quoted-printable format. BODY3 CONTAINSMETA http-equiv=3DContent-Type content=3Dtext/html; charset=3Dus-ascii META content # Uses tables for obfuscation. BODY3 CONTAINSTDFONT face=3DArial size=3D4/FONT/TD TD rowSpan=3D2FONT face=3DArial size=3D4 # Subject is always Re:. HEADERS 1 CONTAINSSubject: Re: # Body does text/html as us-ascii. BODY1 CONTAINSContent-Type: text/html; charset=us-ascii # Quoted-printable line ended too early in body BODY3 CONTAINS DIVFONT face=3DArialHello, = Would # Text or code patterns uncommon in Outlook generated E-mails BODY1 CONTAINSsave up to BODY1 CONTAINSon the Net! BODY1 CONTAINSsize=3D4nbsp;C/FONT/TD BODY1 CONTAINSnbsp;andnbsp;manynbsp; BODY1 CONTAINSBLOCKQUOTE dir=3Dltr=20 style=3DPADDING-RIGHT:
[sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo
Hello Sniffer folks, For those of you who are MDaemon users and may not know, we have developed a plugin version of Message Sniffer that works on the latest version of MDaemon (v8). The folks on the MDaemon beta list have had access to it for a while now and it has been working well. There are no known bugs at this time :-). You can find the plugin on the MDaemon installation page of our site: http://www.sortmonster.com/MessageSniffer/Installation/MDaemon.html The plugin is VERY, VERY fast and much easier to use than the command line utility. If you are still using the command line utility I highly recommend that you switch to the plugin version right away :-) Now that version 8 of MDaemon is out, it is time to finish testing this new version and to get the word out. To help with testing, we have been providing a fully updated rulebase to our beta testers. To help with this next phase of testing we are making this fully updated license public for MDaemon users who want to try the new plugin!! :-) This will only last until the end of April though ;-) Please help us to get the word out about this -- tell all your MDaemon friends what they have been missing. Most of our customers come from your recommendations and we really appreciate that. Remember to tell your friends to let us know about your help when they purchase Message Sniffer so that we can give you your free month! Every new user makes Message Sniffer more powerful! Thanks for all your help! Best, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo
Wow - inline Virus scanning - and if I read the flow chart correctly, their heuristic engine actually sounds like a scoring system for DNSBL and various other indicators and reject a message during connection. Now that's the kind of SMTP engine I've been wanting all along. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, April 18, 2005 06:57 PM To: sniffer@sortmonster.com Subject: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo Hello Sniffer folks, For those of you who are MDaemon users and may not know, we have developed a plugin version of Message Sniffer that works on the latest version of MDaemon (v8). The folks on the MDaemon beta list have had access to it for a while now and it has been working well. There are no known bugs at this time :-). You can find the plugin on the MDaemon installation page of our site: http://www.sortmonster.com/MessageSniffer/Installation/MDaemon.html The plugin is VERY, VERY fast and much easier to use than the command line utility. If you are still using the command line utility I highly recommend that you switch to the plugin version right away :-) Now that version 8 of MDaemon is out, it is time to finish testing this new version and to get the word out. To help with testing, we have been providing a fully updated rulebase to our beta testers. To help with this next phase of testing we are making this fully updated license public for MDaemon users who want to try the new plugin!! :-) This will only last until the end of April though ;-) Please help us to get the word out about this -- tell all your MDaemon friends what they have been missing. Most of our customers come from your recommendations and we really appreciate that. Remember to tell your friends to let us know about your help when they purchase Message Sniffer so that we can give you your free month! Every new user makes Message Sniffer more powerful! Thanks for all your help! Best, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo
Yes, you read it correctly... Mdaemon is capable of blocking spam by sending 'User Unknown' replies during SMTP, which might actively do something against spammers who clean up their lists when these reponses are received. Dunno if they're bright enough to do that tho... Michiel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: dinsdag 19 april 2005 5:22 To: sniffer@SortMonster.com Subject: RE: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo Wow - inline Virus scanning - and if I read the flow chart correctly, their heuristic engine actually sounds like a scoring system for DNSBL and various other indicators and reject a message during connection. Now that's the kind of SMTP engine I've been wanting all along. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, April 18, 2005 06:57 PM To: sniffer@sortmonster.com Subject: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo Hello Sniffer folks, For those of you who are MDaemon users and may not know, we have developed a plugin version of Message Sniffer that works on the latest version of MDaemon (v8). The folks on the MDaemon beta list have had access to it for a while now and it has been working well. There are no known bugs at this time :-). You can find the plugin on the MDaemon installation page of our site: http://www.sortmonster.com/MessageSniffer/Installation/MDaemon.html The plugin is VERY, VERY fast and much easier to use than the command line utility. If you are still using the command line utility I highly recommend that you switch to the plugin version right away :-) Now that version 8 of MDaemon is out, it is time to finish testing this new version and to get the word out. To help with testing, we have been providing a fully updated rulebase to our beta testers. To help with this next phase of testing we are making this fully updated license public for MDaemon users who want to try the new plugin!! :-) This will only last until the end of April though ;-) Please help us to get the word out about this -- tell all your MDaemon friends what they have been missing. Most of our customers come from your recommendations and we really appreciate that. Remember to tell your friends to let us know about your help when they purchase Message Sniffer so that we can give you your free month! Every new user makes Message Sniffer more powerful! Thanks for all your help! Best, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo
Pete, Should we change the license info in the plugin.cfg file to match our license info or should we wait to do so until the release version comes out? Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] - Original Message - From: Pete McNeil [EMAIL PROTECTED] To: sniffer@sortmonster.com Sent: Monday, April 18, 2005 3:57 PM Subject: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta Promo Hello Sniffer folks, For those of you who are MDaemon users and may not know, we have developed a plugin version of Message Sniffer that works on the latest version of MDaemon (v8). The folks on the MDaemon beta list have had access to it for a while now and it has been working well. There are no known bugs at this time :-). You can find the plugin on the MDaemon installation page of our site: http://www.sortmonster.com/MessageSniffer/Installation/MDaemon.html The plugin is VERY, VERY fast and much easier to use than the command line utility. If you are still using the command line utility I highly recommend that you switch to the plugin version right away :-) Now that version 8 of MDaemon is out, it is time to finish testing this new version and to get the word out. To help with testing, we have been providing a fully updated rulebase to our beta testers. To help with this next phase of testing we are making this fully updated license public for MDaemon users who want to try the new plugin!! :-) This will only last until the end of April though ;-) Please help us to get the word out about this -- tell all your MDaemon friends what they have been missing. Most of our customers come from your recommendations and we really appreciate that. Remember to tell your friends to let us know about your help when they purchase Message Sniffer so that we can give you your free month! Every new user makes Message Sniffer more powerful! Thanks for all your help! Best, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
