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).