If you want even tighter control over who can access the relay virtual server—although in most environments, such control is probably unnecessary—you can use IP restrictions to limit which systems can open a connection. For example, if you have a subnet that remote-access or VPN-connected machines use and only these systems need to relay, you can limit SMTP Relay Virtual Server access to the machines on this subnet. You might also use IP restrictions to prevent connections to the virtual server if the physical server is IP accessible from a network beyond which you have direct control—for example, the Internet (ideally, you're protected by a firewall) or a subnet that another division or business unit uses. To configure access, click the Connection button on the SMTP Relay Virtual Server's Access tab. In the Connection dialog box, you can add individual IP addresses, a subnet (group of computers), or domain definitions, using the conventions and considerations that Table 1 provides. The difference between these settings and the relay-restricting settings is that these definitions control which systems can open an SMTP connection to the virtual server on port 25 and have no real impact on a client's ability to relay.
Finally, select the Delivery tab and click Advanced. In the Masquerade domain field, enter the DNS name (e.g., smtp-relay.neulan.net) that you assigned to the virtual server's IP address. The Masquerade domain setting controls the name of the server returned in the connection banner when an SMTP connection is opened. If you don't set the Masquerade domain setting, the connection banner will have the name of the physical server that hosts the SMTP virtual server. Click OK twice to close the virtual server's Properties pages. Right-click the virtual server in ESM, select Stop, then click Start to restart the virtual server and put the configuration settings into effect.
Confirming the Configuration
If you want to confirm that your server is rejecting relays but still accepting mail for your local recipients, you should try to relay mail through the two virtual servers. Test with accounts that are in the SMTP-APPROVED list and a few that aren't. If you elected to configure connection filtering, try connecting from authorized and unauthorized IP ranges. You should find that the original virtual server won't relay mail and that the new SMTP-relay virtual server will relay only when authenticated via credentials or identified via IP address. You'll probably want to use a client such as Outlook Express, but you can also use Telnet to open an SMTP session. I prefer the Telnet approach because I can test the connection fairly easily from just about any system without the hassle of loading or configuring a full mail client. In my next article, I'll describe how to use Telnet to test authenticated relaying.
Best practice mandates that you take steps to ensure that no Exchange server capable of hosting SMTP connections can be overtaken by others who want to use the server to relay email—particularly spam or a virus. You now know how to provide relay capabilities to clients while also protecting your servers against illegal relays.