Welcome to Exchange Team Blog Sign in | Join | Help

Syndication

This Blog

Exchange Server 2003 Service Pack 2 (SP2) anti-spam features - order of execution

By this time, you all must be already aware of new anti-spam features provided in Exchange Server 2003 SP2.

Alexander Nikolayev discusses all the anti-spam features of Exchange server 2003 SP2 in his article at: http://blogs.technet.com/exchange/archive/2005/07/18/407838.aspx

These anti-spam features execute at different stages during SMTP session. You can now deploy Exchange Server 2003 SP2 server behind the perimeter and still benefit by using the Connection filtering.

Depending on position of Exchange Server 2003 in your environment - on perimeter vs. behind perimeter - the order of execution for anti-spam features could differ. I want to take this opportunity and provide a global view of the order of execution for anti-spam features in both the scenarios of Exchange Server 2003 SP2 deployment.

The Sender ID implementation in Exchange Server 2003 SP2 and deployment of Exchange Server 2003 SP2 behind perimeter with Connection filtering enabled, requires you to first define the list of IP addresses that are in your control (refer to the screen shot below). The examples are: perimeter server's IP addresses, internal IP range etc.

Following screenshot is from Exchange Sever 2003 SP2 environment, under Global Settings ' Message Delivery.

Following diagram links different Exchange Server 2003 SP2 anti-spam features to different stages of SMTP session, in both the scenarios:

1. Exchange Server 2003 SP2 implemented on perimeter
In this scenario, the IP address of connecting server is NOT listed in the local IP list

2. Exchange Server 2003 SP2 implemented behind perimeter
In this scenario, the IP address of connecting server is listed in the local IP list

Note:
RBL Connection Filtering is executed immediately after the connection is established, but the results are presented after RCPT TO: command.  This is done to accommodate the exceptions to the block list service rules.

- Omesh Desai

Published Wednesday, August 24, 2005 9:49 AM by Exchange
Filed Under: , ,

Comments

 

Scott said:

Where would a third party spam filtering solution (i.e. Brightmail) fit into this? If you've installed a third party solution on the Exchange server, are all messages scanned by both spam filters, or does one of them somehow take precedence?
August 24, 2005 2:15 PM
 

Tonino Bruno said:

I believe brightmail links up to the PRECAT queue while IMF links up to the POSTCAT queue..

So brightmail would scan the message first..

Sincerely,
Tonino Bruno
August 24, 2005 3:40 PM
 

Konstantin Ryvkin said:

IMF is a *protocol* event sink. As pictured above it hooks up to the _End_of_Data command. (CRLF.CRLF). After the messages passes the above stages they are submitted to the Exchange's advance queuing system.
Brightmail is a *transport* event sink, which is inside advance queuing.
So if installed on the same server IMF (along with the above filtering methods) will be engaged prior to Brightmail for messages comming through SMTP.
August 24, 2005 4:01 PM
 

Scott said:

When we first added the IMF, we set it to "No Action" because we wanted to just watch the performance monitor counters to see how it was doing. Once we did that, though, we got absolutely killed with spam. When we then enabled the IMF blocking, the spam dropped down to a more reasonable level. That led us to believe that the IMF was somehow interfering Brightmail because there was a drastic increase of missed spam with IMF (no action) + Brightmail that we had with Brightmail alone.

Is there any case where the IMF will effectively bypass a third party spam filter?

Since we've had the IMF and Brightmail enabled, many of our users swear that they're getting more spam than they did before when it was just Brightmail. It would be nice to be able to reassure them that both filters work nicely with each other, but so far I haven't been able to get a definitive answer on that.
August 25, 2005 2:46 PM
 

Twan Grotenhuis said:

Why is sender-id hooked up to the End_of_Data command?
For as far as i know everything you need for sender-id (apart from looking up the DNS record) is already provided by the sender.

It's something i've been wondering ever since techEd Amsterdam.
August 26, 2005 2:48 PM
 

Jeffrey Rosen said:

Because SenderID is based on the RFC2822 Mail From.
(Which it will not have until the End of Data)
;-)
August 28, 2005 5:22 PM
 

Jeffrey Rosen said:

I stand corrected (and detail is important)

Sender_ID is based on PRA which is determined from RFC2822 headers (Resent-Sender, Resent-From Sender, From)

There is no “MAIL FROM” in RFC 2822, there is FROM, which the outlook user sees.

Thanks Konstantin for the answer!
August 28, 2005 9:48 PM
 

Windows Server Clustering said:

September 13, 2005 8:55 PM
 

Tom said:

We have our own edge services running just fine, as it seems MS is about 2 years behind the curve in their "innovations". My question is, given that we have a successful exchange implementation by not exposing it to the edge at all, will all the default SP settings be a transparent install?

September 19, 2005 2:17 PM
 

Alex Nikolayev said:

Tom, Exchange 2003 SP2 upgrade will not make any changes to the implementation you have in place (you will need to uninstall the IMFv1 if you have it installed on the upgrading server). In order to take advantage of the new features you must manually enable them, out of the box they are not enabled.
September 19, 2005 3:40 PM
New Comments to this post are disabled

News


This blog and its contents are provided "AS IS" with no warranties, and they confer no rights. Use of any included script samples are subject to the terms specified in the Terms of Use.
New! Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.

Exchange Server 2010 - Get the Release Candidate



Poll:

Other Exchange Blogs from MSFT