Explaining the order in which the Exchange 2003 (SP2) Connection Filters are applied

Introduction

Exchange Server 2003, especially now that Exchange 2003 Service Pack 2 is out, includes several connection filters. I therefore thought it would be a good idea to write an article explaining in which order the connection filters are applied during an SMTP session between an external SMTP server and the Internet-facing Exchange 2003 server in your organization.

Connection Filters

Exchange 2003 with Service Pack 2 applied includes several connection filters, I have listed each of these filters below.

  • Connection control filter (per SMTP virtual server)
  • Connection filtering 
  • Recipient filtering
  • Sender filtering
  • Sender ID filtering
  • Intelligent message filtering

All of these connection filters, except the first one listed (which instead is to be found on the Property page of the SMTP virtual server) can be found by taking Properties of the Message Delivery object in the Exchange System Manager (see Figure 1 below).


Figure 1: Property page of the Message Delivery object in the System Manager

You probably already know the purpose of each connection filter, and you’re most likely using several of them in your own messaging environment. But did you ever wonder in which order they are applied during a SMTP session? You probably did, perhaps in a troubleshooting situation where inbound messages from one or more external organizations never arrived to one or more recipients in your organization.

When an external SMTP server attempts to connect to your Exchange 2003 SMTP Gateway (or more specifically the SMTP virtual server), which typically is the Internet-facing server(s) in your organization, the first thing the server does is to check the external SMTP server’s (the one trying to deliver a message to your server by establishing an anonymous SMTP session) IP address against the list of IP addresses specified under the connection control filter of the SMTP virtual server (shown in Figure 2 below).


Figure 2: Blocked IP addresses under the SMTP Virtual Server

If the IP address of the connecting server is specified here, the SMTP session is dropped, if not the connection is accepted and the connecting server issues an EHLO or HELO command (depending on the type, version and configuration of the server). The response to an EHLO command looks similar to Figure 3 below.


Figure 3: Issued EHLO command

After the EHLO (or HELO) command the connecting server sends a MAIL FROM: [email protected]. Now the IP address of the SMTP server is checked against the Global Accept list located under the Connection Filtering tab as shown in Figure 4 and 5 below.


Figure 4: Connection Filtering tab


Figure 5: Accept List

If the IP address of the connected SMTP server is listed here, the e-mail is accepted and proceeds to the Sender ID filter. If the IP address isn’t on the accept list, the next thing that happens is the IP address is checked against the Global deny list, which is to be found in the same place as the Accept list (as shown back in Figure 4).

If the IP address of the connected SMTP server is listed on the Global deny list, the connection is dropped immediately. If not it proceeds on to the next filter which is the Sender filter.

The Sender filter checks the e-mail address specified in the MAIL FROM: command, which we already talked about earlier on in this article. These addresses are checked against the blocked senders list shown in Figure 6.


Figure 6: Sender filtering

If the e-mail address specified in the MAIL FROM: command is for some reason listed here, the connection is either dropped (if the Drop connection if address matches filter is enabled) or accepted (if the Accept messages without notifying sender of filtering is enabled). If the connection is accepted the session continues, but the e-mail message will be sent directly to the BadMail folder and not to the intended recipient. If the e-mail address is not listed, the SMTP virtual server issues an OK command, like the one in Figure 7.


Figure 7: 250 2.1.0 Sender OK

Now the connected SMTP server issues a RCPT TO: command (see Figure 8).


Figure 8: 250 2.1.5

After the RCPT TO: command has been issued, the next step in the SMTP session is to check the IP address of the connected SMTP server against any Block List Service providers specified under the Connection Filtering tab as shown in Figure 9 below.


Figure 9: Block List Service Configuration

If the IP address of the connected SMTP server is specified on the Global Accept list, the session bypasses this step. The session also continues if the IP address isn’t listed in any of the specified block list service providers lists, but should the IP address be listed on just one of the specified lists the server will send an error code, as well as the specified error message back to the sender.

Next the connection filter checks whether the sender/e-mail address is listed on the connection filtering exception list shown in Figure 10 below.


Figure 10: Connection Filtering Exception list

If the sender/e-mail address is listed the message is accepted and proceeds to issue a DATA command, if not, it is checked against the recipient list configured under the Recipient Filter shown in Figure 11 below.


Figure 11: Blocked Recipients under the Recipient Filtering tab

If the recipient of the e-mail message is listed on the recipient list, the SMTP virtual server returns an invalid recipient error to the sending server. If the recipient isn’t listed, the session continues as expected.

If the recipient isn’t on the blocked recipients list, the Active Directory is checked in order to ensure that the recipient indeed exists in Active Directory. If the recipient doesn’t exist in Active Directory, the SMTP virtual server returns an invalid recipient error. If the recipient exists the session continues.

The connected SMTP server now issues a DATA: command similar to the one below.

DATA
To: Michella Kruse
From: [email protected] <Henrik Walther>
Subject: Descriptive subject

Now the Sender filter checks the From address, in order to make sure it doesn’t match a sender listed on the blocked senders list. If the sender specified in the DATA command is a blocked sender,  the connection is either dropped (a 5.1.0 “Sender denied” error is returned) or the message is accepted but sent directly to the BadMail folder instead of being delivered to the intended recipient. If the sender is not on the blocked senders list, the message is accepted and queued for delivery.

Depending on whether you have enabled Sender ID and/or Intelligent Message filtering, it doesn’t end here. If you have the Sender ID filter enabled it will check whether an SPF record exists for the sending domain, and depending on which of the three possible actions you have chosen (see Figure 12, the message will either be accepted (with the Sender ID status attached), Deleted (accepted and deleted without sending an NDR to the sender) or be rejected (not accepted)). 


Figure 12: Sender ID Filtering

There are also other things the Sender ID filter depends on, for further details I recommend you check this article here on MSExchange.org.

If the message gets past the Sender ID filter, the next border is the Intelligent Message Filter (IMF). Again depending on how this particular filter is configured, the message will either be accepted or caught as spam. If the message is caught as spam, it will, depending on what’s specified in the When blocking messages, either be accepted, deleted or archived.


Figure 13: Intelligent Message Filter

For detailed information on how the Intelligent Message Filter handles incoming messages, I recommend you check this article here on MSExchange.org.
That’s all for this time, I hope you learned something new from this article. See you soon!

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top