Although they are very similar, because the Edge Transport and Hub Transport servers were designed specifically for the role that they play, they have different default settings. For example, the Edge Transport role is configured by default to accept Internet mail, whereas the Hub Transport role is configured to be as secure as possible and does not accept mail from unauthenticated (un-trusted) sources. Because of this, we often get asked if there are options for the customer that cannot or chooses not to run an Edge Transport server.
A brief word about putting an Exchange server directly on the Internet
Historically, Exchange servers should not be directly on the Internet – in no small part because Exchange needs direct access to Active Directory. In the case of the Client Access Server (CAS) protocols (HTTPS, IMAP, POP), the recommendation is for the server to sit behind a reverse proxy/port forwarding firewall like ISA server (now known as ForeFront Threat Management Gateway) that can detect and block attacks. In the case of SMTP, the suggested solution is the Edge Transport role, because it has all the functionality of Exchange (unlike other active SMTP filtering solutions) but still has the isolation options of being completely disjoined from the rest of the Active Directory forest. Whether you chose the Edge Transport or Hub Transport role to receive Internet mail, the server can and should be placed behind a firewall, though active SMTP filtering is not required.
For the customers with only one server, it is suggested to consider a hygiene service such as Exchange Hosted Services (now known as ForeFront Online Protection for Exchange) or perhaps the ISP can offer such a service.
That said, a common configuration for a single Exchange server is to have Exchange sitting directly behind a NAT firewall or reverse proxy like ISA. There is obviously a certain amount of additional risk associated with this approach, but for many smaller customers, the risk is acceptable.
For more information on this topic and the various options available, see “How to Configure Connectors for Internet Mail Flow“.
What features will I be missing by doing this?
The five main feature sets that will be missing are:
- Deploy in Perimeter: Edge can be deployed in a perimeter network; specifically, it does not need to be domain-joined (but it can be), which provides greater security. Hub transport requires a connection to Active Directory.
- Isolation: In particular, the SMTP stream from the Internet tends to be full of spam – over 70% of traffic in most cases. By separating this from your internal traffic, you can insure that internal servers are not busy processing and filtering spam. Internal servers are then free to perform routing, compliance, and other mailbox to mailbox operations. This is particularly important if internal email is mission critical.
- Edge Transport rules agent: Instead you get the Hub Transport rules agent. Hub Transport rules are largely for compliance whereas Edge Transport rules are largely for hygiene. For more information about this topic, see “Overview of Transport Rules” (for Exchange 2010, see Understanding Transport Rules).
- Attachment Filtering agent: The hub transport rules do have some attachment options, but the ability to scan the incoming MIME stream for malicious attachment types and reject at the protocol layer is not one of those features; this agent is not installed or supported on Hub Transport servers. However, anti-virus products like Microsoft Forefront Protection for Exchange often provide this functionality.
- Address Rewriting agents: Address rewriting is generally used by larger corporations that will have Edge Transport servers and/or additional software that can perform this functionality.
Receive connector configuration
While there are seemingly limitless ways to configure your receive connectors, I am suggesting the route that involves the least number of steps and can be done completely within the Exchange Management Console (EMC). For more information, check out Receive Connectors (or for Exchange 2010).
To find receive connectors in the EMC, navigate to Server Configuration -> Hub Transport. Then select your server and you’ll see the Receive Connectors tab below.
The “Default” receive connector on a Hub is configured for other Exchange servers to authenticate, but it doesn’t accept anonymous email by default. The easiest way to address this is to add the Anonymous users permissions group to this connector:
Note: In Exchange Server 2007 Beta 2, this step had to be performed from the Exchange Management Shell.
If you fail to do this step, people that send you email will probably get an NDR with the error 530 5.7.1 Client was not authenticated.
By default, your new Exchange 2007 servers will only accept email destined to the Windows domain that the server was a member of. In order to accept email destined to your external SMTP domain (in scenarios where different domains are used for Active Directory and Internet mail), you will probably need to create a new accepted domain. This is done in the EMC under Organization Configuration -> Hub Transport, then select Accepted Domains.
If you fail to perform this step, people who send email directly to you will probably get an NDR with the error 550 5.7.1 Unable to relay.
Send connector configuration
In order to send email, you need to configure a send connector. This is done in the Exchange Management Console under Organization Configuration -> Hub Transport, then select Send Connectors.
The simplest method is to create one of type “Internet”:
If you’ve installed Exchange 2007 into an existing environment with 2003, then you probably already have a Send Connector (SMTP Connector) and you just need to verify the settings. If the connector is on your 2003 server, you can only view the settings from the Exchange 2007 Management Console. All changes will need to be made through from the Exchange 2003 System Manager (look for “SMTP Connectors”). For example, if you only have a connector on the 2003 machine, then all outbound mail will go through the 2003 server. If you have one on the 2003 and one on the 2007 server, then mail will go through the closest connector. If you delete the one on 2003 and have one on the 2007 server, then all outgoing mail will pass through the 2007 server.
In order for all outbound mail to pass through the connector, the address space of the connector should be * (type “smtp”):
The network tab allows you to specify whether you’ll use a smart host (perhaps an SMTP server at your ISP) to relay your messages, or if you’ll handle the delivery yourself (using DNS).
The source server specifies which Exchange server or servers in your organization will be responsible for sending Internet email.
Setting up an SPF record for your domain is also a good idea, especially if you relay messages off of your ISP.
Because Hub Transport servers only need to perform anti-spam functions when there is no Edge Transport server to perform this function, this is another feature that is not enabled by default. Adding this functionality to your Hub Transport servers is a pretty simple process. First, launch the Exchange Management Shell. In the Scripts folder that was created, you will find a PowerShell script to install the Anti-spam agents. After you run this command, you will need to restart your transport service, and restart the Exchange Management Console.
Once you complete these steps, you will see the Anti-spam tab enabled in the Exchange Management Console.
Please note that if you previously had any Exchange 2003 settings for anti-spam, you will need to migrate your settings over to Exchange 2007.
Because your server is sitting directly on the Internet, you may want to change the advertised FQDN that is sent in HELO/EHLO commands in SMTP. The UI for both send and receive connectors allows you to configure this.
Because you will not be using Edge Server, you have no need for the Microsoft Exchange EdgeSync service. You can set this service to disabled to prevent it from starting and using system resources.
The final step is to 1) make sure that your MX record is correct and 2) that your firewall is letting the connection inbound to port 25. I can’t tell you exactly what to do, but usually the easiest method if you already have a mail server is to either reuse that server’s IP, or update the firewall rule to point to the new Exchange 2007 server’s internal IP.
Use the Mail Flow Analyzer to assist you with troubleshooting issues that may arise. Additionally, there are at least two web sites that can help you diagnose DNS and SMTP receive problems: