Mail sent to users not in active directory (recipient filtering and tar pitting)

Background:

We have windows server 2003 SP1 running exchange server 2003 SP2, and
we have Sunbelt Ninja configured to use the RBL (zen.spamhaus.org) and
SPF (don't allow result hard fail, allow results pass, neutral, no
rule, soft fail, unknown rule, and unknown mechanism). We receive a
lot of e-mails directed to usernames that don't exist on our exchange
server. We would like to block those at the SMTP connection step,
rather than accept the SMTP connection and then issue NDR's to the
supposed (usually faked if the e-mail was spam) return address.

Questions:

Is it currently accepted practice to enable recipient filtering and
tar pitting as described in the articles below?

If someone sends an e-mail to 10 usernames at our domain, and 9 of
them exist in active directory but 1 of them doesn't exist in active
directory, then will the 9 e-mails be delivered but the 1 e-mail will
be blocked at the SMTP step such that the sender's SMTP server
will/should notify the sender that the 1 e-mail could not be
delivered?

Besides SMTP connections that are trying to deliver e-mails that are
directed to usernames that don't exist in active directory, what other
types of SMTP connections will be delayed by enabling tar pitting
(particularly SMTP connections that are not trying to send spam)?

The MS article KB842851 says that if you enable the tar pit feature,
you should carefully monitor the performance of your SMTP server, and
you should analyze the traffic patterns on the server to make sure
that tar pitting is not disrupting or delaying ordinary traffic. How
does one do those things?

Anything else we might need to know before implementing these
solutions?

Recipient Filtering (Filter recipients who are not in the directory)
http://support.microsoft.com/default.aspx/kb/823866

SMTP tar pit feature for Microsoft Windows Server 2003
http://support.microsoft.com/kb/842851

The Hidden Power of Sender and Recipient Filtering
http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html

Windows-based SMTP Tar Pitting Explained
http://www.msexchange.org/tutorials/Windows-based-SMTP-Tar-Pitting-Explained.html

SMTP Session Tar Pitting for Windows 2003 and Exchange
http://msexchangeteam.com/archive/2004/12/06/275851.aspx

Bharat
Tue Feb 06 11:36:19 CST 2007

Responses inline

--
Bharat Suneja
MVP - Exchange
www.zenprise.com
NEW blog location:
exchangepedia.com/blog
----------------------------------------------


"admin35" <admin35@verizon.net> wrote in message
news:nrdhs2hfg79g4n0anah4sanqe6ie21jm39@4ax.com...
> Background:
>
> We have windows server 2003 SP1 running exchange server 2003 SP2, and
> we have Sunbelt Ninja configured to use the RBL (zen.spamhaus.org) and
> SPF (don't allow result hard fail, allow results pass, neutral, no
> rule, soft fail, unknown rule, and unknown mechanism). We receive a
> lot of e-mails directed to usernames that don't exist on our exchange
> server. We would like to block those at the SMTP connection step,
> rather than accept the SMTP connection and then issue NDR's to the
> supposed (usually faked if the e-mail was spam) return address.
>
> Questions:
>
> Is it currently accepted practice to enable recipient filtering and
> tar pitting as described in the articles below?

Yes, it is. Recipient filtering is essential - it drops a lot of spam for
users that don't exist in your org. Tarpitting is equally essential, imo,
when used with mechanisms like Recipient Filtering - to avoid address
harvesting/directory harvesting. Exchange Server 2007 ReceiveConnectors have
tarpitting enabled by default.
http://www.exchangepedia.com/blog/2007/01/enabled-by-default-smtp-tarpit-in.html

>
> If someone sends an e-mail to 10 usernames at our domain, and 9 of
> them exist in active directory but 1 of them doesn't exist in active
> directory, then will the 9 e-mails be delivered but the 1 e-mail will
> be blocked at the SMTP step such that the sender's SMTP server
> will/should notify the sender that the 1 e-mail could not be
> delivered?

Depends. Tarpitting is a delay inserted after RCPT TO command is received.
When sending server sends message to multiple recipients, if any of them
don't exist, your server will delay the "550 5.1.1 User unknown" response by
a few seconds. Depending on the length of delay you've configured, the
sending server will either "wait" for the response - in which case it
finally gets a response and moves on with sending the data, or it
disconnects - in which case none of the users will get that message.

The sender's server should notify the sender.

>
> Besides SMTP connections that are trying to deliver e-mails that are
> directed to usernames that don't exist in active directory, what other
> types of SMTP connections will be delayed by enabling tar pitting
> (particularly SMTP connections that are not trying to send spam)?

"Inappropriate smtp behaviour"

>
> The MS article KB842851 says that if you enable the tar pit feature,
> you should carefully monitor the performance of your SMTP server, and
> you should analyze the traffic patterns on the server to make sure
> that tar pitting is not disrupting or delaying ordinary traffic. How
> does one do those things?

Fire up perfmon and watch the counter, helps if you have a baseline of
number of connections open (average, maximum... over a period of time). The
direct result of tarpitting, particularly on servers with very high
message/connection volume, is an increase in number of open smtp
connections, which do consume resources. The trick is to to tweak the tarpit
time just enough so spammers will abandon the connection and move on to
spamming someone else.

Having said that, I haven't come across a situation or a deployment where
tarpitting has been a cause of severe performance degradation. In most
cases, it is insignificant and barely noticable.


>
> Anything else we might need to know before implementing these
> solutions?
>
> Recipient Filtering (Filter recipients who are not in the directory)
> http://support.microsoft.com/default.aspx/kb/823866
>
> SMTP tar pit feature for Microsoft Windows Server 2003
> http://support.microsoft.com/kb/842851
>
> The Hidden Power of Sender and Recipient Filtering
> http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html
>
> Windows-based SMTP Tar Pitting Explained
> http://www.msexchange.org/tutorials/Windows-based-SMTP-Tar-Pitting-Explained.html
>
> SMTP Session Tar Pitting for Windows 2003 and Exchange
> http://msexchangeteam.com/archive/2004/12/06/275851.aspx
>

Alexander
Tue Feb 06 11:52:54 CST 2007

> Anything else we might need to know before implementing these
> solutions?

If you feel like reading another article, here you go :))
http://www.exchangeinbox.com/articles/020/dirharvest.htm

--
Alexander Zammit
WinDeveloper Software
IMF Tune - Unleash the Full Intelligent Message Filter Power
http://www.windeveloper.com/imftune/


"admin35" <admin35@verizon.net> wrote in message
news:nrdhs2hfg79g4n0anah4sanqe6ie21jm39@4ax.com...
> Background:
>
> We have windows server 2003 SP1 running exchange server 2003 SP2, and
> we have Sunbelt Ninja configured to use the RBL (zen.spamhaus.org) and
> SPF (don't allow result hard fail, allow results pass, neutral, no
> rule, soft fail, unknown rule, and unknown mechanism). We receive a
> lot of e-mails directed to usernames that don't exist on our exchange
> server. We would like to block those at the SMTP connection step,
> rather than accept the SMTP connection and then issue NDR's to the
> supposed (usually faked if the e-mail was spam) return address.
>
> Questions:
>
> Is it currently accepted practice to enable recipient filtering and
> tar pitting as described in the articles below?
>
> If someone sends an e-mail to 10 usernames at our domain, and 9 of
> them exist in active directory but 1 of them doesn't exist in active
> directory, then will the 9 e-mails be delivered but the 1 e-mail will
> be blocked at the SMTP step such that the sender's SMTP server
> will/should notify the sender that the 1 e-mail could not be
> delivered?
>
> Besides SMTP connections that are trying to deliver e-mails that are
> directed to usernames that don't exist in active directory, what other
> types of SMTP connections will be delayed by enabling tar pitting
> (particularly SMTP connections that are not trying to send spam)?
>
> The MS article KB842851 says that if you enable the tar pit feature,
> you should carefully monitor the performance of your SMTP server, and
> you should analyze the traffic patterns on the server to make sure
> that tar pitting is not disrupting or delaying ordinary traffic. How
> does one do those things?
>
> Anything else we might need to know before implementing these
> solutions?
>
> Recipient Filtering (Filter recipients who are not in the directory)
> http://support.microsoft.com/default.aspx/kb/823866
>
> SMTP tar pit feature for Microsoft Windows Server 2003
> http://support.microsoft.com/kb/842851
>
> The Hidden Power of Sender and Recipient Filtering
> http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html
>
> Windows-based SMTP Tar Pitting Explained
> http://www.msexchange.org/tutorials/Windows-based-SMTP-Tar-Pitting-Explained.html
>
> SMTP Session Tar Pitting for Windows 2003 and Exchange
> http://msexchangeteam.com/archive/2004/12/06/275851.aspx
>