During today’s session, Konstantin directed our attention to SMTP Virtual Server Myths Exposed a particularly useful and classic post from the Exchange product team blog, You Had Me At EHLO (you are reading that , right?). We used that post as a launching point for a good discussion about having multiple SMTP virtual servers on Exchange. Since I hear a lot of misunderstanding about some of the points we raised during the discussion, I wanted to add a couple of new myths that were distilled down from today’s session.
- Additional Myth #1: Virtual Servers are bound to a specific IP address
- This is only partly true, and not in the way many people think. A virtual server must be able to bind to a unique IP address/TCP port combination so that it can listen for incoming connections. That’s the only reason you need each VS to have a unique combination: you can only have one process bind to a particular combination of IP address and TCP port. By default, SMTP uses port 25 and changing that will get you in a world of hurt except in certain specific situations, so in practice this means that each VS must have its own unique IP address. Again, that’s just for accepting inbound connections; Exchange will, like any other application on a multi-homed machine, select the most appropriate source IP address based on the Windows routing table when it initiates an outbound connection. This helps explain why the answers to original myths 1 and 2 are the way they are; they assume that you understand the underlying routing structure.
- Additional Myth #2: You need to enable packet forwarding if you have multiple Virtual Servers on the same machine
- I cannot stress strongly enough how false this is. Never, never, never enable packet forwarding unless your machine requires it (and if you’re using software like ISA or RRAS, they’ll enable it for you). You’re doing application-level routing of SMTP messages, not IP routing. This also amplifies original myth 1; any connection restrictions you apply will apply to other VS instances, so make sure you’re allowing connections from the proper IP addresses (depending on your routing scenario).
For the rest of the week, I’m in the Securing Microsoft Exchange Server 2003: Defense in Depth class taught by Microsoft’s Konstantin Ryvkin. Konstantin is another extremely knowledgeable member of the Microsoft IT team and is again giving us a unique and valuable look into the principles he is teaching by showing us how Microsoft has implemented them in their production Exchange environment.
For all of the power that Exchange 2003 brings to the table, there are always limitations that can make life really annoying. One such limitation is found when you try to restrict incoming connections to an SMTP virtual server. Exchange gives you two methods for such restrictions: source IP address or SMTP authentication. A common scenario is that you have a set of hosts you wish to be able to connect to your SMTP VS anonymously (such as from trusted business partners) but require authentication before allowing mail submission from anyone else (allowing your roaming users to use your server when outside the network). Out of the box, you can’t do this with a single SMTP VS. If you enable both restriction types, Exchange uses a logical AND to evaluate them The results: only authenticated users from the trusted hosts can connect.
The workaround involves a lot of pain and usually requires a second virtual server or machine. Both of these scenarios can cause their own problems and complications; quoting from Chapter 6 of the Exchange Server 2003 Routing and Transport Guide:
If you use multiple SMTP virtual servers on a single Exchange server, be careful when you configure them. By default, multiple virtual servers cannot communicate with one another. For proper mail flow, you need to configure them appropriately so that mail can be routed between them. Additionally, each SMTP virtual server must be configured with a unique Internet Protocol (IP) address and port combination. Generally, all SMTP virtual servers require port 25 so you must assign unique IP addresses to them.
Thanks to Konstantin, I learned that there is a little-known IIS 6.0 metabase parameter that can be quite useful for this situation (yet another reason to deploy Exchange 2003 on Windows 2003). The SMTPIPRestrictionFlag property (PropID 37031) controls the logic that Exchange uses. In the default setting of 0, Exchange uses the logical AND, resulting in the out-of-the-box behavior. You can set this to an alternate value (I’m guessing 1, but I don’t know for sure because the only documentation for the property is rather sparse) to trigger the use of the logical OR. The end result? Exchange will allow anonymous connections from trusted IP addresses and authenticated connection from any address. Exactly what we wanted!
I’m sure I’ll have spare time in the lab tomorrow, so I’ll ask for more details and trying playing with it to cobble together a usable example for you. Stay tuned.
Update 0920 PDT 05 May 2005: Konstantin has confirmed that you want to set SMTPIPRestrictionFlag to a value of 1 in order to enable the logcial-OR behavior. Even though this property has been minimally documented for a while, it’s only been last week that they’ve been allowed to start talking about use of this property. Breaking news from Ecubed!