Does anyone know of a similar solution that allows wild cards (allow anything at domain name). We still have some customers using catch-all accounts.
Paul Fuhrmeister [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman Sent: Saturday, December 03, 2005 6:29 AM To: Declude.JunkMail@declude.com; IMail_Forum@list.ipswitch.com; Declude.Virus@declude.com; sniffer@SortMonster.com Subject: [sniffer] ANN: Availability of 5xxSink 0.5.00, IIS SMTP event sink for text-file recipient validation All, I've posted 5XXSINK, an IIS SMTP event sink (freeware) that allows you to block unknown recipients at your IIS 5.0 or 6.0 MX by populating a barebones textfile. Those who use the powerful IIS SMTP engine as an MX have no built-in method of preventing brute-force spam runs from overwhelming their internal content scanning and mailbox servers with wasted message processing and double-bounce generation. Several commercial anti-abuse products can add this functionality, but they can add undue cost to a large server farm, and seem like overkill when a well-tuned content scanning engine (IMail's, Declude's, etc.) already exists internally, save for the fact that it sees messages that should never get that far. While it is debatable whether having envelope recipient validation at your MXs will reduce the number of spammers making initial connections to you, it cannot be denied that having such validation will save your hardware and bandwidth resources beyond the first part of the SMTP conversation. Recipient validation at the MX can make the difference between a workable anti-spam content scanner and one that fails because it's overwhelmed by messages it should never see. 5XXSINK is designed to do one thing, do it well, and do it for free: to look up full e-mail addresses in a locally stored text file and reject all RCPT TO commands that do match a line in the file. That's it. 5XXSINK is NOT designed to do any of the following: connection throttling, tarpitting, greylisting, sender validation, HELO interpretation, or DNSBL lookups. It expects that a robust content scanning solution exists behind, or perhaps on, the IIS SMTP server (although commercial IIS SMTP integrations solutions usually duplicate 5XXSINK's recipient validation functionality -- and then some). Again, the sole function is to keep messages that absolutely, positively do not need to be scanned out of the scanning path. There are no false positives with recipient validation, so it's an obvious first step in an anti-abuse chain. 5XXSINK is multithreaded and likely performs its very particular function as fast as practically possible. * * * Download: http://www.imprimia.com/products/software/freeutils/5xxsink/download/release Be sure to go over the README in-depth. That's where it's at. Support: Through the IMail and Declude support lists, as the communities primarily served by the product. Please post support questions as [OT] to create a public archive and to encourage knowledge sharing. --Sandy 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 message is sent to you because you are subscribed to the mailing list <sniffer@sortmonster.com>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
