I've always wondered why Declude can't use IIS SMTP as its MTA? Seems like a pretty big market for the people who want a gateway only system -- or even Exchange.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sanford Whiteman > Sent: Saturday, December 03, 2005 7:29 AM > To: [email protected]; > [email protected]; [email protected]; > [email protected] > Subject: [Declude.JunkMail] 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/do > wnload/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 was scanned for viruses by Declude EVA www.declude.com] > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be > found at http://www.mail-archive.com. > --- [This E-mail was scanned for viruses by Declude EVA www.declude.com] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
