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
