Transparency of the proxies and built-in MTA

A FortiMail unit ‘s built-in MTA and proxies are not necessarily fully transparent, even if the FortiMail unit is operating in transparent mode.

If you want the FortiMail unit to behave truly transparently, you must:

• select the Hide this box from the mail server option in each session profile
• select Hide the transparent box in each protected domain

Otherwise, the source IP address of connection initiations, the destination IP address of reply traffic, and the SMTP greeting (HELO/EHLO) will contain either:

• the management IP address (for connections occurring through bridged network interfaces), or
• the network interface’s IP address (for connections through out-of-bridge network interfaces)

In addition to preserving the original IP addresses and domain names, for connections to unprotected domains, to be hidden with regards to authentication, the FortiMail unit must pass SMTP AUTH commands through to the SMTP server instead of applying an authentication profile. To do this, you must enable Use client-specified SMTP server to send email in order to use the outgoing proxy instead of the built-in MTA. The outgoing proxy will transmit SMTP AUTH commands to the server, instead of applying the IP-based policy’s authentication profile on behalf of the server.

Avoiding scanning email twice

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” on page 385). 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.

Example 1

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 49 on page 419 shows the configuration options that result in correct mail routing for this desired scenario. Figure 168 on page 419 shows the mail routing that would result from this configuration, in this topology.

Figure 168:Avoiding scanning email twice: Example 1 topology

Table 49:Avoiding scanning email twice: Example 1 configuration

Setting	Value
MUAs’ SMTP server/MTA	the virtual IP on the FortiGate unit, or other public IP address, that routes to 192.168.0.1 (the internal mail relays)
each protected domain’s SMTP server	192.168.0.1
each protected domain’s Use this domain’s SMTP server to deliver the mail	enabled
Use client-specified SMTP server to send email	enabled
port1’s Incoming connections	Pass through or Drop
port1’s Outgoing connections	Pass through
port2’s Incoming connections	Proxy proxy
port2’s Outgoing connections	Pass through or Drop

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.

Example 2

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 50 on page 420 shows the configuration options that result in correct mail routing for this desired scenario. Figure 169 on page 420 shows the mail routing that would result from this configuration, in this topology.

Figure 169:Avoiding scanning email twice: Example 2 topology

Table 50:Avoiding scanning email twice: Example 2 configuration

Setting	Value
MUAs’ SMTP server/MTA	the virtual IP on the FortiGate unit, or other public IP address, that routes to 192.168.0.2 (the internal mail server, not the internal mail relays)
each protected domain’s SMTP server	192.168.0.1
each protected domain’s Use this domain’s SMTP server to deliver the mail	disabled
Use client-specified SMTP server to send email	disabled

Table 50:Avoiding scanning email twice: Example 2 configuration

port1’s Incoming connections	Pass through
port1’s Outgoing connections	Proxy
port2’s Incoming connections	Proxy
port2’s Outgoing connections	Proxy
Relay Server section	not configured
MX record for each protected domain on the internal DNS server	domain name resolving to 192.168.0.1 (the internal mail relays)

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.

Relaying using FortiMail’s built-in MTA versus unprotected SMTP servers

When not proxying, FortiMail units can use their own built-in SMTP relay to deliver email.

If an email user at the branch office, behind a FortiMail unit, specifies the unprotected SMTP server 10.0.0.1 as the outgoing SMTP server, you can either let the email user send email using that specified unprotected SMTP server, or ignore the client’s specification and insist that the FortiMail unit send the email message itself. (See Figure 167 on page 417.)

• If you permit the client to specify an unprotected SMTP server, the FortiMail unit will allow the email client to connect to it, and will not act as a formal relay. If the client’s attempt fails, the outgoing proxy will simply drop the connection and will not queue the email or retry.
• If you insist that the client relay email using the FortiMail unit’s built-in MTA rather than the client-specified relay, the FortiMail unit will act as an MTA, queuing email for temporary delivery failures and sending error messages back to the email senders for permanent delivery failures. It may also reroute the connection through another relay server, or by performing an MX lookup of the recipient’s domain, and delivering the email directly to that mail gateway instead.

Enabling the FortiMail unit to allow clients to connect to unprotected SMTP servers may be useful if, for example, you are an Internet service provider (ISP) and allow customers to use the SMTP servers of their own choice, but do not want to spend resources to maintain SMTP connections and queues to external SMTP servers.

Unlike the outgoing proxy, the incoming proxy does queue and retry. In this way, it is similar to the built-in MTA.

For information on configuring use of the incoming proxy or outgoing proxy instead of using the built-in MTA, see “Use client-specified SMTP server to send email” on page 422 (for outgoing connections) and “Use this domain’s SMTP server to deliver the mail” on page 389 (for incoming connections containing outgoing email messages).

Use client-specified SMTP server to send email

In FortiMail transparent mode, go to Mail Settings > Proxies to enable this feature to use the outgoing proxy instead of the built-in MTA for outgoing SMTP connections. This allows the client to send email using the SMTP server that they specify, rather than enforcing the use of the FortiMail unit’s own built-in MTA. The outgoing proxy refuses the connection if the client’s destination SMTP server is not available. In addition, it will not queue email from the SMTP client, and if the client does not successfully complete the connection, the outgoing proxy will simply drop the connection, and will not retry.

Since authentication profiles may not successfully complete, the outgoing proxy will also ignore any authentication profiles that may be configured in the IP-based policy. The built-in MTA would normally apply authentication on behalf of the SMTP server, but the outgoing proxy will instead pass any authentication attempts through to the SMTP server, allowing it to perform its own authentication.

Disable to relay email using the built-in MTA to either the SMTP relay defined in “Configuring SMTP relay hosts” on page 373, if any, or directly to the MTA that is the mail exchanger (MX) for the recipient email address’s (RCPT TO:) domain. The email may not actually travel through the unprotected SMTP server, even though it was the relay originally specified by the SMTP client. For details, see “When FortiMail uses the proxies instead of the built-in MTA” on page 415.

If this option is disabled, and an SMTP client is configured to authenticate, you must configure and apply an authentication profile. Without the profile, authentication with the built-in MTA will fail. Also, the mail server must be explicitly configured to allow relay from the built-in MTA in this case.

If this option is enabled, you cannot use IP pools. For more information, see “Configuring IP pools” on page 598.

For security reasons, this option does not apply if there is no session profile selected in the applicable IP-based policy. For more information on IP policies, see “Controlling email based on IP addresses” on page 475.