If you would like to read the other parts in this article series please go to:
Outbound E-Mail Flow
Send Connectors are used to control the flow of outbound e-mails to the receiving server and are configured on Mailbox servers running the Transport service. These are commonly used to send outbound e-mails to a smart host or directly to the Internet.
With the changes made to the Transport Pipeline in Exchange 2013, send connectors now behave slightly differently. For example, as we saw in the Exchange 2013 Mail Flow article, they can be configured on a Mailbox server (Transport service) to route outbound e-mail through a CAS server (Front End Transport service) in the local AD site, by using the FrontEndProxyEnabled parameter. This is useful to simplify and consolidate e-mail flow, especially in environments with a large number of Exchange servers.
When using send connectors to send e-mails out to the Internet, administrators have two choices to resolve the recipients’ domains:
- Using smart hosts to relay e-mails out to the Internet;
- Using DNS MX records in order to resolve Internet addresses directly on the Exchange servers.
A common misconception is that outbound traffic can be load balanced simply by creating two send connectors with the same cost, with each one using DNS to route e-mails directly to the Internet or through different smart hosts. However, when two send connectors have the same cost and their source servers are the same or in the same site, Exchange will just choose the one with the alphanumerically lower name. It will not load balance outgoing e-mails across both connections.
In order to effectively load balance outgoing traffic, you should create a single send connector with multiple smart hosts. At the same time, by using this method we are also achieving high availability: if one smart host fails, Exchange will simply use the other one.
Inbound E-Mail Flow
Receive Connectors control the flow of inbound e-mails into an Exchange organization by acting as an inbound connection point that administrators set up to accept connections from servers or clients limited to certain, or any, IP addresses and port numbers. In Exchange 2013, these can be configured on CAS servers (Front End service) or Mailbox servers (Transport service), but one receive connector can only be associated with one server.
By default, the required receive connectors for internal e-mail flow are created automatically when a Mailbox or CAS server is installed. In most cases, creating an explicitly receive connector to receive e-mails from the Internet is not required as a receive connector to accept mail from the Internet (named “Default Frontend <server_name>”) is automatically created upon installation of Exchange.
Usually, the default receive connectors are sufficient to meet the needs of the messaging infrastructure. However, there are cases where additional receive connectors might be desired or even required. The two most common cases are probably to turn off authentication for specific clients (printers, line of business [LOB] applications, etc.) and to allow relaying of e-mails from specific clients.
While Exchange automatically load balances intra-organization e-mail traffic between servers, this does not happen for e-mails received from non-Exchange sources such as LOB applications, printers, external mail servers, POP and IMAP-based clients, etc. In these scenarios, organizations typically chose to load balance this particular type of traffic using a unified SMTP namespace (such as smtp.domain.com) in order to distribute e-mails across the transport servers within the organization and to prevent a server failure from causing these applications and devices from being able to send e-mails. DNS Round Robin, Windows NLB or a hardware/software load balancing solution are the usual choices to achieve this.
The question now is “which method should I chose?”. This depends on two main factors: the organization’s requirements and available budget. A proper load balancer is still the best option as it will guarantee the highest level of availability when compared to all other options.
Below is a table that summarizes the key differences between each method, together with their advantages and disadvantages:
| Method | Advantages | Disadvantages |
| Windows NLB |
|
|
| DNS Round Robin |
|
|
| Load Balancer |
|
|
Table 1
Non-Exchange E-mails
When planning to load balance SMTP traffic, a separate receive connector for this purpose should always be created and configured to use an additional IP address on the receiving server. Additionally, Exchange Server authentication should be disabled to make sure Exchange traffic is not routed through this receive connector.
A common scenario is when devices or applications do not support authenticated SMTP, in which case administrators enable the Anonymous users permissions on the receive connector.
A problem with some load balancing configurations is that the receiving Exchange server is only aware of the IP address of the load balancer, not the IP address of the actual application or printer. For example, a printer is configured to send e-mails to smtp.letsexchange.com which resolves to a load balancer VIP. However, because the load balancer terminates the connection from the printer and establishes a new one between itself and an Exchange server, the Exchange server “sees” the connection as coming from the load balancer, not the original IP address. This is problematic as the scoping settings on the receive connector, specifically the Receive mail from servers that have these remote IP addresses option will be rendered useless and everyone that knows the SMTP VIP will be able to send e-mails through this receive connector, possibly in a non-authenticated way. This also means that protocol logging and message tracking logs will not have complete information regarding the sender.
As such, it is crucial that the source IP address is passed on to the Exchange server so it can validate if that particular IP address is authorized to use the Receive connector or not, giving the control and security administrators are used to.
Conclusion
In this fourth article we started exploring how to achieve high availability for inbound and outbound e-mail flow. In the fifth and last article of this series, we will continue and finish with inbound e-mail flow.
If you would like to read the other parts in this article series please go to:
