The Edge Server Arguably, the biggest difference between Microsoft Exchange 2003’s and Exchange 2007’s message hygiene functionality is the introduction of a server role that exists solely for message hygiene. The Edge Transport server (or just “Edge”) role is a separate Exchange role that must be installed on a server that doesn’t include any other server roles; the Edge role was designed to provide a separate bastion host for processing inbound email. This strategy makes excellent sense, given that the Edge role was expressly designed to have a minimal attack surface and to be directly exposed to Internet traffic.
Whereas Microsoft recommended against installing Exchange 2003 front-end servers in a network’s perimeter or demilitarized zone (DMZ), with Exchange 2007, Microsoft now explicitly recommends that Edge servers be positioned in just that configuration. Microsoft’s reasoning is that Exchange 2003 front-end servers require several additional ports to be open to the back-end servers, but the Edge server is altogether a different beast. It doesn’t have to be a domain member server (in fact, you can’t install it in a forest that has non-Edge Exchange servers in it), meaning that an attacker who compromises an Edge server can’t easily leverage that compromise into a domain attack. In addition, Exchange 2007 includes an extension to the Windows Security Configuration Wizard (SCW) that automates the process of hardening an Edge server to make it safe for use when directly exposed to the Internet.
The question then arises of how the Edge server can get information about recipients from Active Directory (AD), a necessary step to make filtering based on recipient information work. The answer lies in Active Directory Application Mode (ADAM), a little-used service that lets a server keep a partial replica of an AD Global Catalog (GC) for a forest to which the server doesn’t belong. In this case, the Edge server runs ADAM in conjunction with the new EdgeSync tool, which runs on a Hub Transport server inside the network perimeter. EdgeSync provides a one-way sync of connector data, recipient and sender filtering information, and accepted domains from the hub transport to the Edge role; consequently, you must open three TCP ports (TCP port 25 for SMTP, TCP port 50389 for plain LDAP, and TCP port 50636 for secure LDAP). Interestingly, synchronization happens per AD site, not per server, so you’re not tied to a single Hub Transport server as a bridgehead.
You don’t have to use an Edge server if you don’t want to. The Hub Transport server role can provide some of the same message hygiene capabilities that the Edge server role does.