Back to Blog

Does Your Environment Need an Exchange 2013 Edge Transport Server?

Image of Jeff Guillet MVP, MCSM
Jeff Guillet MVP, MCSM

Microsoft first introduced the Edge Transport role as one of the five Exchange roles in Exchange 2007 and offered it again in Exchange 2010. The purpose of the Edge server role is to provide a solution for customers who require inbound SMTP connections to terminate in the perimeter network (DMZ), rather than in the internal network. Since most inbound SMTP connections are unauthenticated, some security departments are uneasy at allowing these connections directly to internal resources (your Exchange servers). Edge transport servers allow these customers to deploy Exchange without having to buy an SMTP gateway appliance.

For further security, computers running the Edge Transport role are not joined to the internal Exchange organization’s domain and cannot run any other Exchange roles. It is possible to join Edge servers to a separate DMZ domain for group policy configuration and common security configuration, but this is rare since most customers do not deploy Active Directory in their perimeter network.

As the SMTP ingress point for the organization, Edge servers can act as your first line of defense for SMTP malware and denials of service. The Edge Transport role works with internal Exchange servers using an Edge subscription. An Edge subscription provides a mutually authenticated and encrypted connection between the Edge Transport servers and the internal Exchange servers.  The Edge Transport role provides additional security benefits, such as:

  • Most Edge Transport configurations are performed on the internal Exchange servers and this configuration is synchronized to the Edge servers using a process called EdgeSync. If an Edge server somehow becomes compromised, the Edge Transport configuration cannot be changed.
  • Enhanced anti-malware capabilities using Recipient Filtering. Which I will explain a bit later.
  • The reduction of harvest attacks using tarpitting. Tarpitting is a method where the Edge Transport delays responses to invalid commands or recipients for a specified amount of time (default 5 seconds). This behavior drastically reduces the effectiveness of denial of service attacks and directory harvest attacks.
  • All EdgeSync communications are authenticated and encrypted using self-signed Exchange certificates.
  • All SMTP communications between Edge and internal Exchange servers occurs using TLS encryption.

When Exchange 2013 RTM was announced on October 11, 2012, it shipped without the Edge Transport role. Customers who required their SMTP connections to terminate in the perimeter network were told they could still use Edge Transport 2007 or 2010 servers as an SMTP front-end to Exchange 2013. Since Edge Transport servers are not domain-joined it was a simple matter to subscribe these existing legacy Edge Transports servers to the Exchange 2013 front-end transport on the CAS role.

Exchange 2013 SP1 reintroduced the new 2013 Edge Transport role. Customers can continue to use legacy Edge servers with Exchange 2013 SP1+ or they can redeploy new Edge 2013 SP1 servers. By upgrading to Edge 2013 servers customers can enjoy the same cumulative update servicing schedule and support offered to their internal Exchange 2013 servers.

This Edge transport functions essentially the same as legacy versions, but it lacks an administrative interface.  Edge 2013 is managed entirely using the Exchange Management Shell (EMS). This further hardens Edge 2013 servers since the IIS role does not need to be deployed. As a matter of fact, the only prerequisite software to install is the Microsoft .NET Framework 4.5 and the AD LDS role. I recommend installing Exchange 2013 SP1 on Windows Server 2012 R2 servers for the best features and security, but it can also be installed on Windows Server 2012.

Both the legacy versions and the new Exchange 2013 Edge servers include basic anti-malware protection capabilities, but with Exchange 2010 Edge servers you have the added advantage of installing Forefront Protection for Exchange 2010. That’s of questionable benefit though, since Microsoft has discontinued FPE. I have seen a marked increase in spam getting through since it was announced that FPE was being discontinued. Microsoft now recommends using the Exchange Online Protection hosted email filtering service as your primary malware solution. EOP can then forward your inbound emails to the Edge Transport servers or directly to your internal Exchange 2013 servers using TLS connections.

Exchange 2013 Mailbox servers automatically include basic anti-malware protection, but Edge Transport servers offer Recipient Filtering. The Recipient Filter agent on Edge servers processes all inbound non-authenticated messages from the Internet and treats them as external messages. This allows the Edge server to perform the following functions:

  • Recipient Blocking allows administrators with the Organization Management or Hygiene Management roles to block specific SMTP senders or sender domains.
  • Recipient Filtering can be used to only allow emails to valid SMTP addresses, reducing the amount of spam that gets passed to the internal network. Subscribed Edge servers can do this because they hold a small subset of internal email objects in an Active Directory Lightweight Directory Services (AD LDS) instance. The EdgeSync process keeps this AD LDS instance up to date.
  • Key mailboxes can be filtered to never receive emails from the Internet, such as the organization’s Helpdesk.
  • Edge Transport can block inbound emails addressed to distribution lists that are configured to only accept emails from internal users.

Note that while Recipient Filtering is also installed on Exchange 2013 mailbox servers, you should not configure it. Mailbox servers are unable to distinguish external messages and will block the entire message if a single bad address is detected in a message.

So when does it make sense to deploy Exchange 2013 Edge Transport servers in your organization? You may want to consider Edge servers if:

  • Your company’s security policy requires that all non-authenticated SMTP traffic terminate in the perimeter network.
  • Your company does not use a hosted anti-malware solution, like Exchange Online Protection.
  • Your company needs enhanced recipient filtering capabilities that your hosted email filtering service does not provide.
  • You are planning an Office 365 hybrid deployment and need to terminate SMTP traffic in the perimeter network. Edge Transport servers are the only supported way to do this.

As always, you should review your organization’s email policies and requirements. Often, a security policy written years ago does not apply to today’s much more secure and hardened servers.


Exchange Monitoring

[Exchange Monitoring]: Introduction to Managed Availability (Part 3)

Image of Dominik Hoefling MVP
Dominik Hoefling MVP

Now that you’ve finished Part I and Part II of my three-part Managed Availability blog series, I...

Read more
Exchange Monitoring

Exchange Monitoring: Managed Availability Part 2

Image of Dominik Hoefling MVP
Dominik Hoefling MVP

How to check, recover, and maintain your Exchange organization

Now that you’ve finished Part I of...

Read more