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

Comments (9)
  1. Scott says:

    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?

  2. Tonino Bruno says:

    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

  3. Konstantin Ryvkin says:

    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.

  4. Scott says:

    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.

  5. Twan Grotenhuis says:

    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.

  6. Jeffrey Rosen says:

    Because SenderID is based on the RFC2822 Mail From.

    (Which it will not have until the End of Data)

    ;-)

  7. Jeffrey Rosen says:

    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!

  8. tom says:

    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?

  9. Alex Nikolayev says:

    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.

Comments are closed.