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: [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@SortMons
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
