Thanks Sandy - very kool!
On a block is any message returned to the sending mta - like a 550 or?
Configurable would be nice but I will not go as far as ask for it to be
a feature - however on the other hand :
For a feature - I need to be able to wild card a domain.
Currently maybe 5-10% of my domains are 'open' - and I work daily with
the owners to give me valid recip lists so these will go away - but then
I pick up 10 more and say ~2 of those are open and I need to work to
close those, etc - sooo the reality is its hard to have a 100% valid
recip list at all times. All or none is - in my environment difficult
to maintain. If this could be implemented - domain wild carding - I
would eliminate ORF from doing this...
Nice work!
-Nick
Sanford Whiteman wrote:
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 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.
