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 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 > > > > > > > > > > -- > ===================================================== > 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
