Depending on your network topology, in transparent mode, you may need to verify that the FortiMail unit is not scanning the same email twice.

Redundant scanning can result if all origins of outgoing email are not physically located on the same network as the protected domain’s mail relay (“SMTP server”). This is especially true if your internal relays and mail servers are physically located on separate servers, and those servers are not located on the same network. Due to mail routing, an email could travel through the FortiMail unit multiple times in order to reach its final destination. As a result, if you have selected Proxy more than once in System > Network > Interface, it is possible that an email could be scanned more than once, decreasing the performance of your email system and unnecessarily increasing delivery time.

There are some topologies, however, when it is correct to select Proxy for multiple network interfaces, or even for both incoming and outgoing connections on the same network interface. It is important to understand the impact of the relevant configuration options in order to configure transparent mode proxy/relay pick-up correctly.

The following two examples demonstrate correct configurations for their topology, and illustrate the resulting mail routing.

All email must be routed through the internal mail relays. Internal mail servers, internal MUAs, and remote MUAs all send mail through the mail relays, whether the recipient is a member of the protected domain or not. Because of this, the FortiMail unit is deployed directly in front of the internal mail relays, which are physically located on a network separate from the mail servers that store email for retrieval by email users. For each protected domain, “SMTP server” is configured with the IP address of an internal mail relay.

Table 45 shows the configuration options that result in correct mail routing for this desired scenario.

Because the FortiMail unit is deployed directly in front of the relays, which are not on the same network as either the remote MUAs or the internal mail servers, if proxy/relay pick-up is not configured correctly, outgoing email could be scanned twice: once as it travels from port2 to port1, and again as it travels from port1 to port2. In addition, if proxying is not configured correctly, email would be picked up by the built-in MTA instead of the proxy, and might never reach the internal mail relays.

To solve this, do not configure the FortiMail unit to use its built-in MTA to intercept incoming connections and deliver email messages. Instead, it should proxy the incoming connections, allowing them to reach the internal mail relays. Because all email was already scanned during the incoming connection, when the internal mail relay initiates the outgoing connection to either an external MTA or to the internal mail server, the FortiMail unit does not need to scan the email again. In addition, because the internal mail relays maintain the queues, the FortiMail unit does not need to maintain queues for outgoing connections. It can instead use its outgoing proxy, which does not queue, and will not reroute email. Finally, there should be no incoming connections on port1, nor outgoing connections on port2; so, configure them either as Pass through or Drop.

All incoming email must be routed through the internal mail relays. The internal mail server also routes outgoing email through the relays. Because of this, the FortiMail unit is deployed directly in front of the internal mail relays, which are physically located on the same network as the mail servers that store email for retrieval by email users. For each protected domain, “SMTP server” is configured with the IP address of an internal mail relay.

Remote MUAs’ outgoing email must not be routed through the internal mail relays.

Table 46 shows the configuration options that result in correct mail routing for this desired scenario.

Unlike external MTAs making incoming connections to the relays, remote MUAs instead make outgoing connections through port2: their destination is the internal mail server, whose IP address is not configured in the protected domain. (The protected domain’s “SMTP server” field is instead configured with the IP address of the internal mail relay.) As a result, you can configure pick-up for these connections separately from those of external MTAs — they pass through the same port, but are distinct in their directionality.

In this case, we want to intercept connections for both external MTAs and remote MUAs. To solve this, we select Proxy for both “Incoming connections” from external MTAs and “Outgoing connections” (from remote MUAs) on port 2. (If we wanted to block remote MUAs only, we could simply select Drop for “Outgoing connections” on port2.)

However, the remote MUAs’ configuration also means that the directionality of remote MUAs’ connections coincides with that of the internal relays’ connections to external relays: both are outgoing. Therefore if you configure the FortiMail unit to proxy outgoing connections instead of using the built-in MTA by enabling “Use client-specified SMTP server to send email”, both outgoing connections are proxied.

Remote MUAs’ connections would all travel through the internal mail server, regardless of whether the recipient has an account on that mail server or not. Outgoing email would then need to be forwarded to the internal mail relay, and back out through the FortiMail unit. The result? Outgoing email from remote MUAs would travel extra mail hops. This would burden the internal network with traffic destined for an external network, and needlessly increases points of potential failure.

Additionally, because the FortiMail unit is deployed directly in front of both the relays and the mail server, which is not on the same network as remote MUAs, remote MUAs’ outgoing email could be scanned twice: once as it travels from port2 to port1, and again as it travels from port1 to port2. This is resource-inefficient.

To solve this, the FortiMail unit should not be configured to use its proxy to intercept outgoing connections. Instead, it should use its built-in MTA. The built-in MTA forms its own separate connections based on the MX lookup of the recipient’s domain, rerouting email if necessary. Notice that as a result of this lookup, although remote MUAs are configured to connect to the internal mail server, connections for incoming email are actually diverted by the built-in MTA through the internal mail relays. This has the benefit of providing a common relay point for all internal email.

Rerouting also prevents outgoing email from passing through the FortiMail unit multiple times, receiving redundant scans. This prevents externally-destined email from burdening the internal mail relays and internal mail servers.

Finally, there should be no incoming connections on port1, so it can be configured either as Pass through or Drop.