An Exchange Server message routing myth forever being propagated (including by me!):
If 2 SMTP Connectors (or Send Connectors in case of Exchange Server 2007) exist, one with a more specific address space, like exchangepedia.com, and one for a more generic address space like *, messages are always routed over the Connector with the more specific address space.
Now, generally that rule of thumb works for most purposes, until you consider restrictions on Connectors. These include:
Connector Scope: (Entire) Organization, or the Routing Group (to which the Connector belongs or is homed to)
Message Size restrictions: To prevent messages over a certain size from being routed over a Connector
Delivery Restrictions: To allow/prevent messages from particular senders from being routed over a Connector (Exchange Server 2003/2000)
Figure 1: Content Restrictions on a SMTP Connector, including message size limit
Scenario:
You want to prevent users from sending messages over 100 Kb to exchangepedia.com.
– Connector1 for address space exchangepedia.com, message size restriction of 100Kb.
– Connector2 for address space *, no message size restrictions.
Result:
– Messages for exchangepedia.com recipients with a message size that is under the 100kb limit are routed over Connector1.
– Messages for exchangepedia.com recipients with a message size of over 100kb are routed over Connector2 with the generic address space of *. Connector1 with more specific address space of exchangepedia.com is never considered.
If you want to limit messages sent to exchangepedia.com to only 100kb, you cannot do it using the configuration in the above scenario.
From Exchange Server 2007 documentation:
Routing to External Domains -> Selecting the Routing Path to an External Recipient):
If more than one Send connector is configured to have an address space that meets the routing requirements for an external recipient, Exchange 2007 routing will select a single connector through which to route the message. The selected connector must meet the message size constraints. After Exchange 2007 has eliminated all connectors that have prohibitive message size restrictions, routing applies the following criteria to determine to which connector it will route:
From the list of all Send connectors and foreign connectors that are configured in the Exchange organization, it narrows the list to connectors that satisfy all the following criteria:
– In the scope for the local server
– Enabled
– With an address space that matches the recipient’s e-mail domainFrom the resulting list, select the connector with the most specific address space match. No matching connectors may be found.
Maybe an Exchange Server 2007 change, you wonder. Not quiet – Exchange Server 2003 behaves similarly.
From Exchange Server 2003 documentation:
Exchange Server 2003 Message Routing -> Routing Path Selection Process
It determines all connectors to the message destination in the organization topology, and then analyzes message characteristics and connector restrictions to exclude all those connectors that must not be used to transfer the message.
In a nutshell: Connector selection happens after restrictions are checked.
Which Connector? Determining the Send Connector used in Exchange Server 2007 is quiet easy – if using different fqdns on a Send Connector, you can simply check the Received headers; or you can look at the SMTP logs (read previous post “Exchange Server 2007: Logging SMTP Protocol Activity“). In Exchange Server 2003, you can bump up the diagnostics logging on MSExchangeTransport -> Routing Engine/Service. Exchange logs Event ID 984, which provides details about message routing, including the Connector selected.
In the following screenshots, we see 2 different SMTP Connectors being selected for 2 messages to the same destination – the smaller message uses the Connector with the specific address space – exchangepedia.com, which routes the message to a smarthost. The larger message that exceeds that Connector’s message size limit is routed using the Connector for address space *, which routes the message using DNS to lookup the MX record(s) for exchangepedia.com.
Figure 2: With Diagnostics Logging enabled, Exchange Server 2003 logs Event ID 984, which shows Connector selected (for a small message under 100kb in this case). The message is delivered to the Smarthost specified in the Connector.
Figure 3: Event ID 984 shows the Connector for generic address space * selected for a larger message (over 100kb in this case). Message is delivered using DNS lookup.
Unintended consequences? The implications aren’t pretty, specially when you consider scenarios where one uses a SMTP Connector for a particular address space to enforce TLS (perhaps one of the biggest reasons why messages should never be routed over a Connector with a generic address space if a Connector for a specific address space exists). If I enforce message size restrictions on my Connector with TLS enabled, larger messages can and will be transmitted using the generic Connector that does not use TLS. Now we have the larger message(s) traveling over potentially unsecured SMTP sessions.
What about Delivery Restrictions? For Exchange Server 2003, the same is true for Delivery Restrictions. If the Connector for exchangepedia.com has Delivery Restrictions to prevent Joe Adams from sending messages to Exchangepedia, the message routes over the generic Connector for * – effectively flushing such restrictions down the tube. Restrictions on Connectors with more generic address space are a different story – if Joe has Delivery Restrictions on the * Connector, he cannot send internet mail.
The first task of the Routing Engine/transport should be to check if Connectors with more specific address spaces are available. If it finds any, there is no reason to exclude these from the routing decision. Any restrictions on that Connector exist for a purpose – to restrict message sizes, or to prevent certain users from sending to particular domains using Delivery Restrictions. By excluding Connectors with restrictions from the routing calculation, we’re sayin
g routing the message is more important than enforcing those restrictions. As a result, by routing the message over generic Connectors, other requirements for mail delivery to that address space, such as those mentioned above and other available Connector settings, may not be applied.
Related Posts:
– HOW TO: Prevent a user from sending and receiving internet mail
– Exchange Server 2007: Setting Message Size Limits
– Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain
{ 6 comments… read them below or add one }
Crap. I’ve been saying this forever as well. Thanks for the clarification, Bharat.
How stupid, so alternatives for those of us who need to actually control the routing of SMTP messages?
Hello,
Please, can somebody explain how an exchange 2003 installation can send out
external email to "all" domains when the SMTP Connector i created uses an
address space of e.g. "testdomain.com"?
Are "all" outbound emails to different domains than "testdomain.com" sent
out by the virtual smtp service?
r4i kort
Bharat,
so is there any way to block some some domains for some users ?
i have tried it ,
1)SMTP Connector Default
2)SMTP Connector with address space of some Specific domains and add restrictions for some users m but email going through from default . . .
is there any way to worked it out ?
i need simply block some domains for only few users ,
Bharat – this is a great explanation! I've pointed to your article numerous times in my postings at http://forums.msexchange.org.
In response to Anonymous – you can still control the routing, you just may need to think in a slightly different way.
Responding to Balal Ahmad – I believe I just responded to your post at: http://forums.msexchange.org/SMTP_Connecter_with_(*)_and_specific_address_space/m_1800513346/tm.htm
In short, you want to use the "Accept messages from" restriction for a blocked users list. When you use the "Reject messages from" restriction instead, you are telling Exchange to look for a different connector to use. As Bharat says in his article, Exchange looks at the restrictions before the Address Space.
Think of it this way. Your user (blocked sender) comes to a room with two doors (routing engine). Behind the first door (connector) is someone that decides whether he will forward a message to a specific place (blocked domain). However, when your user knocks on the door, he is asked for his name and not where the message goes. Being on the rejected user list means he is turned away without ever getting to mention the recipient. Having nowhere else to go he goes to the other door where that person accepts all messages from everyone and sends it on its way.