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.
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
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 recipients that 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'll block off my Imail/Declude server altogether and use two 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 currently does 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@SortMo
RE: [sniffer] IIS SMTP Integration
Title: Message 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 recipients that 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'll block off my Imail/Declude server altogether and use two 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 currently does that. But I think it's important that protocol is offered as one choice. Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Friday, February 18, 2005 10:33 PMTo: sniffer@SortMonster.comSubject: Re: [sniffer] IIS SMTP IntegrationI 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.MattAndy 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
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, bu
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: 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/MessageS
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
Oh, crap. Did I just put words in Matt's mouth? Now we'll never hear the end of it. Have a good weekend, guys. Especially you, Sandy. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 5: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
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
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 at M> least work with one in order to prevent ongoing issues with brute force M> spam floods. I'm not sure that Peter from VamSoft understands the large M> market out there for non-Exchange based setups, or even for going the M> extra mile that is necessary for this stuff, though that might be an M> 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
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
Re[4]: [sniffer] IIS SMTP Integration
> (a) other work . . . for example, the 80 GB of Exchange data that a client lost today and which I will spend my "weekend" recovering. This is why the rate of publishing our scripts for Declude/IMail has dropped off as well. The hits have kept on coming in 2005. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [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[3]: [sniffer] IIS SMTP Integration
> Well, yes, and I'd love to put it out there. Perhaps I'm missing > something obvious but there doesn't seem to be a place do download > this, and the site is incomplete. True indeed. Andy's just trying to get me moving on this -- we had a talk about it last month and mentioned why I stalled before any kind of commercial/public release: (a) other work (b) other work (c) other work There just isn't time for me to make a more public version of this that I'd be proud of. The current version has no installer, no up-to-date GUI, and must be configured using IIS scripting and direct Registry editing. It's not ready to be out there on anyone else's network; I don't have the time to support it, nor make it self-supporting. 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). --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [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[2]: [sniffer] IIS SMTP Integration
On Friday, February 18, 2005, 1:55:00 PM, Andy wrote: AS> Hi, AS> You know of this one: AS> http://www.mailmage.com/products/software/freeutils/MilterSink/webhelp/milte AS> rsink_help.htm ? Well, yes, and I'd love to put it out there. Perhaps I'm missing something obvious but there doesn't seem to be a place do download this, and the site is incomplete. I would really love to see it all get done and I'd like to have it to play with too - after all, I'm going to get a lot of questions about how it works and how it gets set up etc... plus I will want to make adjustments to sniffer to support it better (such as rewriting the message file etc...). AS> Exchange server is NOT required to test SMTP sinks - just standard Windows AS> with IIS SMTP (you can probably even test it on XP Pro - although I have not AS> tried). True ... Exchange is not strictly required, but I'm going to get support questions that will probably require that I have a simulation in the lab. I hate to do things half way. Even so, I'd be happy with a workable solution and a place to send users for help when they need it. AS> Yes, there ARE "_EOD" sinks in the field. ORF from VamSoft uses them to AS> support RegEx checks against the MIME content. In fact, ORF would be a great AS> partner for Sniffer (if only they could be convinced). That's worth a shot. AS> I'm in the process of deploying IIS/SMTP with ORF and a custom sink as a AS> gateway for Imail - and would LOVE to get Sniffer in there as well. Maybe we can team up to make this work. _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] IIS SMTP Integration
Pete, maybe a talk with this guy, who produces a decent free Windows 200x and Exchange 200x filter product would be fruitful: http://martijnjongen.com/Default.aspx?tabid=27 It doesn't look like he has so far considered calling other external applications as plugins, but his development efforts look driven by feedback. And of course, there's the commercial offering that is similar: www.vamsoft.com/orf/ Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 10:41 AM To: Andy Schmidt Subject: Re: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 1:15:36 PM, Andy wrote: AS> Hi, AS> I read this and this sounds like it could an _EOD InboundCommand AS> sink that hopefully would allow us to simulate a protocol error and AS> drop connection? If so, I can save myself the money of having it AS> custom-developed for me. Is this truly in the works: AS> http://www.sortmonster.com/MessageSniffer/Help/FAQ.html#Exchange Yes and no. I've had reports from a number of developers that they have code that works... but when pressed, nobody will show me code. We do not have an Exchange server here to test, nor the extended environment that would also be required to do a good job - so we're not likely to tackle this one in house any time soon. At the time that was written I had hired a developer to work on it and they assured me that it would be as easy as you have just suggested - which is what I suggested to them. Unfortunately that project went badly and took a lot of time and resources with it. It seems that most folks who ask about this either disappear quickly, or resolve to put a server in front of their Exchange box for a number of reasons - including to run SNF and virus scanners etc... The project to create a native SNF hook into Exchange is currently parked as a result. I will modify that QA until things changes. At some point we may create a connector for Exchange, and we would be happy (as always) to provide technical support for anyone wishing to do this. If anyone knows of such a beast (I almost can't believe it doesn't exist somewhere) then please let us know how we can get our hands on it. 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
Hi, You know of this one: http://www.mailmage.com/products/software/freeutils/MilterSink/webhelp/milte rsink_help.htm ? Exchange server is NOT required to test SMTP sinks - just standard Windows with IIS SMTP (you can probably even test it on XP Pro - although I have not tried). Yes, there ARE "_EOD" sinks in the field. ORF from VamSoft uses them to support RegEx checks against the MIME content. In fact, ORF would be a great partner for Sniffer (if only they could be convinced). I'm in the process of deploying IIS/SMTP with ORF and a custom sink as a gateway for Imail - and would LOVE to get Sniffer in there as well. Best Regards Andy Schmidt H&M 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:41 PM To: Andy Schmidt Subject: Re: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 1:15:36 PM, Andy wrote: AS> Hi, AS> I read this and this sounds like it could an _EOD InboundCommand AS> sink that hopefully would allow us to simulate a protocol error and AS> drop connection? If so, I can save myself the money of having it AS> custom-developed for me. Is this truly in the works: AS> http://www.sortmonster.com/MessageSniffer/Help/FAQ.html#Exchange Yes and no. I've had reports from a number of developers that they have code that works... but when pressed, nobody will show me code. We do not have an Exchange server here to test, nor the extended environment that would also be required to do a good job - so we're not likely to tackle this one in house any time soon. At the time that was written I had hired a developer to work on it and they assured me that it would be as easy as you have just suggested - which is what I suggested to them. Unfortunately that project went badly and took a lot of time and resources with it. It seems that most folks who ask about this either disappear quickly, or resolve to put a server in front of their Exchange box for a number of reasons - including to run SNF and virus scanners etc... The project to create a native SNF hook into Exchange is currently parked as a result. I will modify that QA until things changes. At some point we may create a connector for Exchange, and we would be happy (as always) to provide technical support for anyone wishing to do this. If anyone knows of such a beast (I almost can't believe it doesn't exist somewhere) then please let us know how we can get our hands on it. 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
On Friday, February 18, 2005, 1:15:36 PM, Andy wrote: AS> Hi, AS> I read this and this sounds like it could an _EOD AS> InboundCommand sink that hopefully would allow us to simulate a AS> protocol error and drop connection? AS> If so, I can save myself the money of having it custom-developed for me. AS> Is this truly in the works: AS> http://www.sortmonster.com/MessageSniffer/Help/FAQ.html#Exchange Yes and no. I've had reports from a number of developers that they have code that works... but when pressed, nobody will show me code. We do not have an Exchange server here to test, nor the extended environment that would also be required to do a good job - so we're not likely to tackle this one in house any time soon. At the time that was written I had hired a developer to work on it and they assured me that it would be as easy as you have just suggested - which is what I suggested to them. Unfortunately that project went badly and took a lot of time and resources with it. It seems that most folks who ask about this either disappear quickly, or resolve to put a server in front of their Exchange box for a number of reasons - including to run SNF and virus scanners etc... The project to create a native SNF hook into Exchange is currently parked as a result. I will modify that QA until things changes. At some point we may create a connector for Exchange, and we would be happy (as always) to provide technical support for anyone wishing to do this. If anyone knows of such a beast (I almost can't believe it doesn't exist somewhere) then please let us know how we can get our hands on it. 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 H&M 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
[sniffer] IIS SMTP Integration
Title: Message Hi, I read this and this sounds like it could an _EOD InboundCommand sink that hopefully would allow us to simulate a protocol error and drop connection? If so, I can save myself the money of having it custom-developed for me. Is this truly in the works:http://www.sortmonster.com/MessageSniffer/Help/FAQ.html#Exchange Best RegardsAndy SchmidtH&M Systems Software, Inc.600 East Crescent Avenue, Suite 203Upper Saddle River, NJ 07458-1846Phone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206http://www.HM-Software.com/ <>
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
[sniffer] Interesting Article
Hi Sniffer Folks, Here's an interesting article: http://www.technewsworld.com/story/39578.html Michael Stein Computer House www.computerhouse.com
RE: [sniffer] Changes - Heavy lifting is complete...
Pete, You are good on my end. Thanks for the clean job and better bandwidth. John- John W. Enyart EAI, Inc. [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, February 17, 2005 3:07 PM To: sniffer@sortmonster.com Subject: [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 --- [Scanned for viruses by the ESPAN WebCenter] 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
