Transparent mode deployment

The following procedures and examples show you how to deploy the FortiMail unit in transparent mode.

Configuring DNS records
Example 1: FortiMail unit in front of an email server
Example 2: FortiMail unit in front of an email hub
Example 3: FortiMail unit for an ISP or carrier

Configuring DNS records

If the FortiMail unit is operating in transparent mode, in most cases, configuring DNS records for protected domain names is not required. Proper DNS records for your protected domain names are usually already in place. However, you must configure public DNS records for the FortiMail unit itself.

If you are unfamiliar with configuring DNS and related MX and A records, first read DNS role in email delivery.

For performance reasons, and to support some configuration options, you may also want to provide a private DNS server for exclusive use by the FortiMail unit.

This section includes the following:

Configuring DNS records for the FortiMail unit itself
Configuring a private DNS server

Configuring DNS records for the FortiMail unit itself

In addition to that of protected domains, the FortiMail unit must be able to receive web connections, and send and receive email, for its own domain name. Dependent features include:

delivery status notification (DSN) email
spam reports
email users’ access to their per-recipient quarantined mail
FortiMail administrators’ access to the web UI by domain name
alert email
report generation notification email

For this reason, you should also configure public DNS records for the FortiMail unit itself.

Appropriate records vary by whether or not Web release host name/IP (located in Security > Quarantine > Quarantine Report in the advanced mode of the web UI) is configured:

Unless you have enabled both Hide the transparent box in each protected domain and Hide this box from the mail server in each session profile, the FortiMail unit is not fully transparent in SMTP sessions: the domain name and IP address of the FortiMail unit may be visible to SMTP servers, and they might perform reverse lookups. For this reason, public DNS records for the FortiMail unit usually should include reverse DNS (RDNS) records.

Case 1: Web release host name/IP is empty/default

When Web release host name/IP is not configured (the default), the web release/delete links that appear in spam reports use the fully qualified domain name (FQDN) of the FortiMail unit.

For example, if the FortiMail unit’s host name is fortimail, and its local domain name is example.net, resulting in the FQDN fortimail.example.net, a spam report’s default web release link might look like (FQDN highlighted in bold):

https://fortimail.example.net/releasecontrol?release=0%3Auser2%40example.com%3AMTIyMDUzOTQzOC43NDJfNjc0MzE1LkZvcnRpTWFpbC00MDAsI0YjUyM2NTkjRSxVMzoyLA%3D%3D%3Abf3db63dab53a291ab53a291ab53a291

In the DNS configuration to support this and the other DNS-dependent features, you would configure the following three records:

example.net IN MX 10 fortimail.example.net

fortimail IN A 10.10.10.1

1 IN PTR fortimail.example.net.

where:

example.net is the local domain name to which the FortiMail unit belongs; in the MX record, it is the local domain for which the FortiMail is the mail gateway
fortimail.example.net is the FQDN of the FortiMail unit
fortimail is the host name of the FortiMail unit; in the A record of the zone file for example.net, it resolves to the IP address of the FortiMail unit for the purpose of administrators’ access to the web UI, email users’ access to their per-recipient quarantines, to resolve the FQDN referenced in the MX record when email users send Bayesian and quarantine control email to the FortiMail unit, and to resolve to the IP address of the FortiMail unit for the purpose of the web release/delete hyperlinks in the spam report
10.10.10.1 is the public IP address of the FortiMail unit

Case 2: Web release host name/IP is configured

You could configure Web release host name/IP to use an alternative fully qualified domain name (FQDN) such as webrelease.example.info instead of the configured FQDN, resulting in the following web release link (web release FQDN highlighted in bold):

https://webrelease.example.info/releasecontrol?release=0%3Auser2%40example.com%3AMTIyMDUzOTQzOC43NDJfNjc0MzE1LkZvcnRpTWFpbC00MDAsI0YjUyM2NTkjRSxVMzoyLA%3D%3D%3Abf3db63dab53a291ab53a291ab53a291

Then, in the DNS configuration to support this and the other DNS-dependent features, you would configure the following MX record, A records, and PTR record (unlike Case 1: Web Release Host Name/IP is empty/default, in this case, two A records are required; the difference is highlighted in bold):

example.net IN MX 10 fortimail.example.net

fortimail IN A 10.10.10.1

webrelease IN A 10.10.10.1

1 IN PTR fortimail.example.net.

where:

example.net is the local domain name to which the FortiMail unit belongs; in the MX record, it is the local domain for which the FortiMail is the mail gateway
fortimail.example.net is the FQDN of the FortiMail unit
fortimail is the host name of the FortiMail unit; in the A record of the zone file for example.net, it resolves to the IP address of the FortiMail unit for the purpose of administrators’ access to the web UI and to resolve the FQDN referenced in the MX record when email users send Bayesian and quarantine control email to the FortiMail unit
webrelease is the web release host name; in the A record of the zone file for example.info, it resolves to the IP address of the FortiMail unit for the purpose of the web release/delete hyperlinks in the spam report
10.10.10.1 is the public IP address of the FortiMail unit

Configuring a private DNS server

Consider providing a private DNS server on your local network to improve performance with features that use DNS queries.

Public and private DNS servers (transparent mode)

A private DNS server may be required if the following conditions are met:

You configure the FortiMail unit to use a private DNS server.
Both the FortiMail unit and the protected SMTP server reside on the internal network, with private network IP addresses.
You enable the Use MX record option.

Configure the A records on the private DNS server and public DNS server differently: the private DNS server must resolve to the domain names of the SMTP servers into private IP addresses, while the public DNS server must resolve them into public IP addresses.

For example, if both a FortiMail unit (fortimail.example.com) operating in transparent mode and the SMTP server reside on your private network behind a router or firewall as illustrated in Public and private DNS servers (gateway mode), and the Use MX record option is enabled, Transparent mode deployment illustrates differences between the public and private DNS servers for the authoritative DNS records of example.com.

Public versus private DNS records when “Use MX Record” is enabled

Private DNS server	Public DNS server
example.com IN MX 10 mail.example.com	example.com IN MX 10 mail.example.com
mail IN A 172.16.1.10	mail IN A 10.10.10.1
10 IN PTR fortimail.example.com	1 IN PTR fortimail.example.com

If you choose to add a private DNS server, to configure the FortiMail unit to use it, go to System > Network > DNS in the advanced mode of the web UI.

Example 1: FortiMail unit in front of an email server

In this example, a FortiMail unit operating in transparent mode is positioned in front of one email server.

This example assumes that the FortiMail unit is protecting a single email server. If your FortiMail unit is protecting multiple email servers and they are not on the same subnet, you must first remove some network interfaces from the bridge and configure static routes. For an example of configuring out-of-bridge network interfaces, see Removing the network interfaces from the bridge.

Transparent mode deployment to protect an email server

To deploy the FortiMail unit in front of an email server, you must complete the following:

Configuring the protected domains and session profiles
Configuring the proxies and implicit relay
Testing the installation

This example assumes you have already completed the Quick Start Wizard. For details, see Running the Quick Start Wizard.

Configuring the protected domains and session profiles

When configuring the protected domain and session profiles, you can select transparent mode options to hide the existence of the FortiMail unit.

To configure the transparent mode options of the protected domain

Go to Domain & User > Domain > Domain.
Select the domain and then click Edit.
Configure the following:

Transparent Mode Options	Description
This server is on (transparent mode only)	Select the network interface (port) to which the protected SMTP server is connected. Note: Selecting the wrong network interface will result in the FortiMail sending email traffic to the wrong network interface.
Hide the transparent box (transparent mode only)	Enable to preserve the IP address or domain name of the SMTP client for incoming email messages in: the SMTP greeting (`HELO`/`EHLO`) in the envelope and in the `Received:` message headers of email messages the IP addresses in the IP header This masks the existence of the FortiMail unit to the protected SMTP server. Disable to replace the SMTP client’s IP address or domain name with that of the FortiMail unit. For example, an external SMTP client might have the IP address 172.168.1.1, and the FortiMail unit might have the domain name fortimail.example.com. If the option is enabled, the message header would contain (difference highlighted in bold): Received: from 192.168.1.1 (EHLO 172.16.1.1) (192.168.1.1) by smtp.external.example.com with SMTP; Fri, 24 Jul 2008 07:12:40 -0800 Received: from smtpa ([172.16.1.2]) by [172.16.1.1] with SMTP id kAOFESEN001901 for <user1@external.example.com>; Fri, 24 Jul 2008 15:14:28 GMT But if the option is disabled, the message headers would contain: Received: from 192.168.1.1 (EHLO fortimail.example.com) (192.168.1.1) by smtp.external.example.com with SMTP; Fri, 24 Jul 2008 07:17:45 -0800 Received: from smtpa ([172.16.1.2]) by fortimail.example.com with SMTP id kAOFJl4j002011 for <user1@external.example.com>; Fri, 24 Jul 2008 15:19:47 GMT Note: If the protected SMTP server applies rate limiting according to IP addresses, enabling this option can improve performance. The rate limit will then be separate for each client connecting to the protected SMTP server, rather than shared among all connections handled by the FortiMail unit. Note: Unless you have enabled Take precedence over recipient based policy match in the IP-based policy, this option has precedence over the Hide this box from the mail server option in the session profile, and may prevent it from applying to incoming email messages. Note: This function does not take effect if the email is sent from protected domains to protected domains. Note: When this option is enabled, you cannot use IP pools for this protected domain, and you should specify an SMTP server other than the FortiMail unit for outgoing mail. For more information, see Use client-specified SMTP server to send email.
Use this domain’s SMTP server to deliver the mail (transparent mode only)	Enable to allow SMTP clients to send outgoing email directly through the protected SMTP server. Disable to, instead of allowing a direct connection, proxy the connection using the incoming proxy, which queues email messages that are not immediately deliverable.

Transparent Mode Options

Description

This server is on

(transparent mode only)

Select the network interface (port) to which the protected SMTP server is connected.

Note: Selecting the wrong network interface will result in the FortiMail sending email traffic to the wrong network interface.

Hide the transparent box

(transparent mode only)

Enable to preserve the IP address or domain name of the SMTP client for incoming email messages in:

the SMTP greeting (HELO/EHLO) in the envelope and in the Received: message headers of email messages
the IP addresses in the IP header

This masks the existence of the FortiMail unit to the protected SMTP server.

Disable to replace the SMTP client’s IP address or domain name with that of the FortiMail unit.

For example, an external SMTP client might have the IP address 172.168.1.1, and the FortiMail unit might have the domain name fortimail.example.com. If the option is enabled, the message header would contain (difference highlighted in bold):

Received: from 192.168.1.1 (EHLO 172.16.1.1) (192.168.1.1) by smtp.external.example.com with SMTP; Fri, 24 Jul 2008 07:12:40 -0800

Received: from smtpa ([172.16.1.2]) by [172.16.1.1] with SMTP id kAOFESEN001901 for <user1@external.example.com>; Fri, 24 Jul 2008 15:14:28 GMT

But if the option is disabled, the message headers would contain:

Received: from 192.168.1.1 (EHLO fortimail.example.com) (192.168.1.1) by smtp.external.example.com with SMTP; Fri, 24 Jul 2008 07:17:45 -0800

Received: from smtpa ([172.16.1.2]) by fortimail.example.com with SMTP id kAOFJl4j002011 for <user1@external.example.com>; Fri, 24 Jul 2008 15:19:47 GMT

Note: If the protected SMTP server applies rate limiting according to IP addresses, enabling this option can improve performance. The rate limit will then be separate for each client connecting to the protected SMTP server, rather than shared among all connections handled by the FortiMail unit.

Note: Unless you have enabled Take precedence over recipient based policy match in the IP-based policy, this option has precedence over the Hide this box from the mail server option in the session profile, and may prevent it from applying to incoming email messages.

Note: This function does not take effect if the email is sent from protected domains to protected domains.

Note: When this option is enabled, you cannot use IP pools for this protected domain, and you should specify an SMTP server other than the FortiMail unit for outgoing mail. For more information, see Use client-specified SMTP server to send email.

Use this domain’s SMTP server to deliver the mail

(transparent mode only)

Enable to allow SMTP clients to send outgoing email directly through the protected SMTP server.

Disable to, instead of allowing a direct connection, proxy the connection using the incoming proxy, which queues email messages that are not immediately deliverable.

Select OK.

To configure the transparent mode options of the session profile

Go to Policy > IP Policy > IP Policy.
In the Session column for an IP-based policy, select the name of the session profile to edit the profile.

A dialog appears.

Configure the following:

Connection Setting
Hide this box from the mail server (transparent mode only)	Enable to preserve the IP address or domain name of the SMTP client in: the SMTP greeting (`HELO`/`EHLO`) and in the `Received:` message headers of email messages the IP addresses in the IP header This masks the existence of the FortiMail unitto the protected SMTP server. Disable to replace the SMTP client’s IP addresses or domain names with that of the FortiMail unit. Note: Unless you have enabled Take precedence over recipient based policy match in the IP-based policy, the Hide the transparent box option in the protected domain has precedence over this option, and may prevent it from applying to incoming email messages.

Connection Setting

Hide this box from the mail server

(transparent mode only)

Enable to preserve the IP address or domain name of the SMTP client in:

the SMTP greeting (HELO/EHLO) and in the Received: message headers of email messages
the IP addresses in the IP header

This masks the existence of the FortiMail unitto the protected SMTP server.

Disable to replace the SMTP client’s IP addresses or domain names with that of the FortiMail unit.

Note: Unless you have enabled Take precedence over recipient based policy match in the IP-based policy, the Hide the transparent box option in the protected domain has precedence over this option, and may prevent it from applying to incoming email messages.

Select OK.
Repeat the previous three steps for each IP-based policy.

Configuring the proxies and implicit relay

When operating in transparent mode, the FortiMail unit can use either transparent proxies or an implicit relay to inspect SMTP connections. If connection pick-up is enabled for connections on that network interface, the FortiMail unit can scan and process the connection. If not enabled, the FortiMail unit can either block or permit the connection to pass through unmodified.

Exceptions to SMTP connections that can be proxied or relayed include SMTP connections destined for the FortiMail unit itself. For those local connections, such as email messages from email users requesting deletion or release of their quarantined email, you must choose to either allow or block the connection.

You configure proxy/relay pick-up separately for incoming and outgoing connections.

For information on determining directionality, see Connection directionality versus email directionality.

In this deployment example, incoming connections arriving on port2 must be scanned before traveling to the main email server, and therefore are configured to be Proxy — that is, picked up by the implicit relay.

Outgoing connections arriving on port1 will contain email that has already been scanned once, during SMTP clients’ relay to the main email server. Scanning outgoing connections again using either the outgoing proxy or the implicit relay would waste resources. Therefore outgoing connections will be Pass through.

To configure SMTP proxy and implicit relay pick-up

Go to System > Network > Interface.
Edit SMTP Proxy settings on both Port 1 and Port 2:

Port 1
	Incoming connections	Drop
	Outgoing connections	Pass through
	Local connections	Enable
Port 2
	Incoming connections	Proxy
	Outgoing connections	Drop
	Local connections	Disable

If Use client-specified SMTP server to send email 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.

Testing the installation

Basic configuration is now complete, and the installation may be tested. For testing instructions, see Testing the installation.

Example 2: FortiMail unit in front of an email hub

In this example, a FortiMail unit operating in transparent mode is positioned between an email gateway and other internal email servers.

When sending email with external recipients, the email servers (Relay A and Relay B) in each WAN location are required to deliver through the main email server, which encrypts outgoing SMTP connections. The firewall will only allow SMTP traffic from the main email server.

Transparent mode deployment to protect an email hub

To deploy the FortiMail unit in front of one or more email servers, you must complete the following:

Configuring the protected domains and session profiles
Configuring the proxies and implicit relay
Testing the installation

This example assumes you have already completed the Quick Start Wizard. For details, see Running the Quick Start Wizard.

Configuring the protected domains and session profiles

When configuring the protected domain and session profiles, you can select transparent mode options to hide the existence of the FortiMail unit.

To configure the transparent mode options of the protected domain

Go to Domain & User > Domain > Domain.
In the row corresponding to the protected domain, select Edit.
Configure the following settings under Transparent Mode Options (transparent mode only):

GUI option	Description
This server is on (transparent mode only)	Select the network interface (port) to which the protected SMTP server is connected. Note: Selecting the wrong network interface will result in the FortiMail sending email traffic to the wrong network interface.
Hide the transparent box (transparent mode only) Note: This function does not take effect if the email is sent from protected domains to protected domains.	Enable to preserve the IP address or domain name of the SMTP client for incoming email messages in: the SMTP greeting (`HELO`/`EHLO`) in the envelope and in the `Received:` message headers of email messages the IP addresses in the IP header This masks the existence of the FortiMail unit to the protected SMTP server. Disable to replace the SMTP client’s IP address or domain name with that of the FortiMail unit. For example, an external SMTP client might have the IP address 172.168.1.1, and the FortiMail unit might have the domain name fortimail.example.com. If the option is enabled, the message header would contain (difference highlighted in bold): Received: from 192.168.1.1 (EHLO 172.16.1.1) (192.168.1.1) by smtp.external.example.com with SMTP; Fri, 24 Jul 2008 07:12:40 -0800 Received: from smtpa ([172.16.1.2]) by [172.16.1.1] with SMTP id kAOFESEN001901 for <user1@external.example.com>; Fri, 24 Jul 2008 15:14:28 GMT But if the option is disabled, the message headers would contain: Received: from 192.168.1.1 (EHLO fortimail.example.com) (192.168.1.1) by smtp.external.example.com with SMTP; Fri, 24 Jul 2008 07:17:45 -0800 Received: from smtpa ([172.16.1.2]) by fortimail.example.com with SMTP id kAOFJl4j002011 for <user1@external.example.com>; Fri, 24 Jul 2008 15:19:47 GMT Note: If the protected SMTP server applies rate limiting according to IP addresses, enabling this option can improve performance. The rate limit will then be separate for each client connecting to the protected SMTP server, rather than shared among all connections handled by the FortiMail unit. Note: Unless you have enabled Take precedence over recipient based policy match in the IP-based policy, this option has precedence over the Hide this box from the mail server option in the session profile, and may prevent it from applying to incoming email messages. Note: This function does not take effect if the email is sent from protected domains to protected domains. Note: When this option is enabled, you cannot use IP pools for this protected domain, and you should specify an SMTP server other than the FortiMail unit for outgoing mail. For more information, see Use client-specified SMTP server to send email.
Use this domain’s SMTP server to deliver the mail (transparent mode only)	Enable to allow SMTP clients to send outgoing email directly through the protected SMTP server. Disable to, instead of allowing a direct connection, proxy the connection using the incoming proxy, which queues email messages that are not immediately deliverable.

GUI option

Description

This server is on

(transparent mode only)

Select the network interface (port) to which the protected SMTP server is connected.

Note: Selecting the wrong network interface will result in the FortiMail sending email traffic to the wrong network interface.

Hide the transparent box

(transparent mode only)

Note: This function does not take effect if the email is sent from protected domains to protected domains.

Enable to preserve the IP address or domain name of the SMTP client for incoming email messages in:

the SMTP greeting (HELO/EHLO) in the envelope and in the Received: message headers of email messages
the IP addresses in the IP header

This masks the existence of the FortiMail unit to the protected SMTP server.

Disable to replace the SMTP client’s IP address or domain name with that of the FortiMail unit.

Received: from 192.168.1.1 (EHLO 172.16.1.1) (192.168.1.1) by smtp.external.example.com with SMTP; Fri, 24 Jul 2008 07:12:40 -0800

Received: from smtpa ([172.16.1.2]) by [172.16.1.1] with SMTP id kAOFESEN001901 for <user1@external.example.com>; Fri, 24 Jul 2008 15:14:28 GMT

But if the option is disabled, the message headers would contain:

Received: from 192.168.1.1 (EHLO fortimail.example.com) (192.168.1.1) by smtp.external.example.com with SMTP; Fri, 24 Jul 2008 07:17:45 -0800

Received: from smtpa ([172.16.1.2]) by fortimail.example.com with SMTP id kAOFJl4j002011 for <user1@external.example.com>; Fri, 24 Jul 2008 15:19:47 GMT

Note: If the protected SMTP server applies rate limiting according to IP addresses, enabling this option can improve performance. The rate limit will then be separate for each client connecting to the protected SMTP server, rather than shared among all connections handled by the FortiMail unit.

Note: Unless you have enabled Take precedence over recipient based policy match in the IP-based policy, this option has precedence over the Hide this box from the mail server option in the session profile, and may prevent it from applying to incoming email messages.

Note: This function does not take effect if the email is sent from protected domains to protected domains.

Note: When this option is enabled, you cannot use IP pools for this protected domain, and you should specify an SMTP server other than the FortiMail unit for outgoing mail. For more information, see Use client-specified SMTP server to send email.

Use this domain’s SMTP server to deliver the mail

(transparent mode only)

Enable to allow SMTP clients to send outgoing email directly through the protected SMTP server.

Disable to, instead of allowing a direct connection, proxy the connection using the incoming proxy, which queues email messages that are not immediately deliverable.

Select OK.

To configure the transparent mode options of the session profile

Go to Policy > IP Policy > IP Policy.
In the Session column for an IP-based policy, select the name of the session profile to edit the profile.
Configure the following:

Connection Setting
Hide this box from the mail server (transparent mode only)	Enable to preserve the IP address or domain name of the SMTP client in: the SMTP greeting (`HELO`/`EHLO`) and in the `Received:` message headers of email messages the IP addresses in the IP header This masks the existence of the FortiMail unitto the protected SMTP server. Disable to replace the SMTP client’s IP addresses or domain names with that of the FortiMail unit. Note: Unless you have enabled Take precedence over recipient based policy match in the IP-based policy, the Hide the transparent box option in the protected domain has precedence over this option, and may prevent it from applying to incoming email messages.

Connection Setting

Hide this box from the mail server

(transparent mode only)

Enable to preserve the IP address or domain name of the SMTP client in:

the SMTP greeting (HELO/EHLO) and in the Received: message headers of email messages
the IP addresses in the IP header

This masks the existence of the FortiMail unitto the protected SMTP server.

Disable to replace the SMTP client’s IP addresses or domain names with that of the FortiMail unit.

Select OK.
Repeat the previous three steps for each IP-based policy.

Configuring the proxies and implicit relay

Proxy/relay pick-up is configured separately for incoming and outgoing connections.

For information on determining directionality, see Connection directionality versus email directionality.

Outgoing connections arriving on port1 will contain email that has already been scanned once, during SMTP clients’ relay to the main email server. In addition, outgoing connections by the main mail server will be encrypted using TLS. Encrypted connections cannot be scanned. Therefore outgoing connections will be passed through, and neither proxied nor implicitly relayed.

To configure SMTP proxy and implicit relay pick-up

Go to System > Network > Interface in the advanced mode of the web UI.
Edit SMTP Proxy settings on both Port 1 and Port 2:

Port 1
	Incoming connections	Drop
	Outgoing connections	Pass through
	Local connections	Enable
Port 2
	Incoming connections	Proxy
	Outgoing connections	Drop
	Local connections	Disable

Testing the installation

Basic configuration is now complete, and the installation may be tested. For testing instructions, see Testing the installation.

Example 3: FortiMail unit for an ISP or carrier

In this example, a FortiMail unit operating in transparent mode is positioned as an offshoot from the backbone or other primary traffic flow between the internal and external network. A router uses policy-based routes to redirect only SMTP connections to the FortiMail unit, which scans the traffic before allowing legitimate connections to return the overall flow. The FortiMail unit does not receive non-SMTP traffic (this would result in unnecessary processing and resource usage).

For increased session-handling capacity, multiple FortiMail units could be clustered into a config-only HA group and deployed behind a load balancer that is attached to the router. Connections to the same source IP address would be handled by the same FortiMail unit to avoid sessions split among multiple units, and to maintain the accuracy of IP statistics. Otherwise, attach a single FortiMail unit to the router.

Service providers often fundamentally require transparent mode. Requiring subscribers to explicitly configure a mail relay can be problematic, and in the case of 3G mobile subscribers, impossible. Therefore gateway mode is not suitable. Transparent mode makes SMTP scanning possible without configuration by the subscriber.

A dual-arm attachment is used. This provides natural isolation of traffic before and after inspection, which can be useful if traffic requires further analysis such as packet traces by a sniffer (if you use a load balancer and it does not support the same session on two different ports, deploy the FortiMail unit using a single-arm attachment instead. For example, Foundry IronServer has been known to require single-arm attachment).

Transparent mode deployment at an ISP or carrier (with HA cluster)

Each network interface in the dual-arm attachment (port2 and port3) is removed from the Layer 2 bridge, and is configured with its own IP address. This reduces the possibility of Ethernet loops and improves compatibility with other filtering devices. Routes are configured between port2 and port3.

Because port1 cannot be removed from the bridge, and the management IP is accessible from any bridging network interface, port1 is reserved for direct connections from the administrator's computer (if the administrator’s computer is not directly connected but is instead part of a management LAN, a route must also be configured for port1).

Network address translation (NAT) must not occur on any device between the FortiMail unit and SMTP clients, such as subscribers and external MTAs. Antispam scans involving the SMTP client’s IP address, such as sender reputation, carrier endpoint reputation, session rate limits, and mail rate limits, require the ability to correctly identify each source of email by its unique IP address in order to operate correctly. NAT would interfere with this requirement.

Full transparency is configured. Popular email services such as Microsoft Hotmail may rate limit by an SMTP client’s IP address in order to reduce spam. If the FortiMail unit were not transparent to those mail servers, all SMTP connections from your subscribers would appear to come from the FortiMail unit. The result is that external mail servers could throttle the connections of all subscribers behind the FortiMail unit. To prevent this, each individual SMTP client’s IP address should be visible to external MTAs. NAT therefore would also interfere with the requirement of transparency.

Protected domains and access control rules (sometimes called access control lists or ACLs) are not configured. Instead, administrators will configure ACLs on their own internal or external MTAs.

You could configure ACLs to reject SMTP connections from specific IP addresses if required by your security policy. However, in this example, because no protected domains are configured, ACLs are not required. For connections to unprotected SMTP servers, the implicit ACL permits the connection if no other ACL is configured.

To prevent SMTP clients’ access to open relays, the outgoing proxy will require all connections to be authenticated using the SMTP AUTH command, but will not apply authentication profiles on behalf of the SMTP servers, as no protected domains are configured. It will also not interfere with command pipelining. However, the outgoing proxy will be configured to block TLS connections, whose encryption would prevent the FortiMail unit from being able to scan the connection.

The outgoing proxy is enabled. Unlike other transparent mode deployments, because no protected domains are defined, all connections will be considered to be outgoing — that is, destined for an SMTP server whose IP address is not configured in the SMTP server field in a protected domain. As a result, all connections will be handled by the outgoing proxy. The built-in MTA will never be implicitly used, and the incoming proxy will never be used. If a destination SMTP server is unavailable, the outgoing proxy will refuse the connection. The FortiMail unit will not queue undeliverable mail. Instead, each SMTP client will be responsible for retrying its own delivery attempts.

Unlike other FortiMail deployments, because the ISP or carrier uses a RADIUS server to authenticate and/or track the currently assigned IP addresses of subscribers, the FortiMail unit can combat spam using the carrier endpoint reputation feature.

The FortiMail unit scans SMTP connections originating from both the internal and external network.

Scanning connections from the external network protects subscribers from viruses and spam.
Scanning connections from the internal network protects subscribers’ service levels and reduces cost of operation to the ISP or carrier by preventing its public IP addresses from being added to DNS block list (DNSBL) servers.

Why should you scan email originating from the internal network?

Spammers often use a subscriber account to send spam, either by purchasing temporary Internet access or, increasingly, by infecting subscriber’s computers or phones. Infected devices become part of a botnet that can be used to infect more devices, and to send spam.

Because many mail servers use DNSBL to combat spam, if a subscriber’s IP address is added to a DNSBL, it can instantly cause email service interruption. If the subscriber’s IP address is dynamic rather than static, when the spammer’s IP address is reassigned to another subscriber, this can cause problems for an innocent subscriber. Even worse, if many subscribers on your network share a single public IP address, if that single IP address is blocklisted, all of your customers could be impacted.

Protecting the public range of IP addresses from being blocklisted is essential for service providers to be able to guarantee a service level to subscribers.

In addition to jeopardizing customer retention, spam originating from your internal network can also cost money and time. Spam consumes bandwidth and network resources. Tracking which in your block of IPs is currently blocklisted, and paying to have them de-listed, can be a significant recurring cost.

By scanning email destined for the Internet, you can thereby reduce your own costs and maximize customers’ satisfaction with your service levels.

To deploy the FortiMail unit at an ISP or carrier, you must complete the following:

Configuring the connection with the RADIUS server
Removing the network interfaces from the bridge
Configuring the session profiles
Configuring the IP-based policies
Configuring the outgoing proxy
Testing the installation

This example assumes you have already completed the Quick Start Wizard. For details, see Running the Quick Start Wizard.

Configuring the connection with the RADIUS server

FortiMail units can use your RADIUS accounting records to combat spam and viruses. This reduces spam and viruses originating from your network, and reduces the likelihood that your public IP addresses will be blocklisted.

Unlike MTAs, computers in homes and small offices and mobile devices such as laptops and cellular phones that send email may not have a static IP address. Cellular phones’ IP addresses especially may change very frequently. After a device leaves the network or changes its IP address, its dynamic IP address may be reused by another device. Because of this, a sender reputation score that is directly associated with an SMTP client’s IP address may not function well. A device sending spam could start again with a clean sender reputation score simply by rejoining the network to get another IP address, and an innocent device could be accidentally blocklisted when it receives an IP address that was previously used by a spammer.

To control spam from SMTP clients with dynamic IP addresses, you may be able to use the endpoint reputation score method instead.

The endpoint reputation score method does not directly use the IP address as the SMTP client’s unique identifier. Instead, it uses the subscriber ID, login ID, MSISDN, or other identifier (An MSISDN is the number associated with a mobile device, such as a SIM card on a cellular phone network). The IP address is only temporarily associated with this identifier while the device is joined to the network.

When a device joins the network of its service provider, such as a cellular phone carrier or DSL provider, it may use a protocol such as PPPoE or PPPoA which supports authentication. The network access server (NAS) queries the remote authentication dial-in user (RADIUS) server for authentication and access authorization. If successful, the RADIUS server then creates a record which associates the device’s MSISDN, subscriber ID, or other identifier with its current IP address.

The server, next acting as a RADIUS client, sends an accounting request with the mapping to the FortiMail unit (the FortiMail unit acts as an auxiliary accounting server if the endpoint reputation daemon is enabled). The FortiMail unit then stores the mappings, and uses them for the endpoint reputation feature.

When the device leaves the network or changes its IP address, the RADIUS server acting as a client requests that the FortiMail unit stop accounting (that is, remove its local record of the IP-to-MSISDN/subscriber ID mapping). The FortiMail unit keeps the reputation score associated with the MSISDN or subscriber ID, which will be re-mapped to the new IP address upon the next time that the mobile device joins the network.

The endpoint reputation feature can be used with traditional email, but it can also be used with MMS text messages.

The multimedia messaging service (MMS) protocol transmits graphics, animations, audio, and video between mobile phones. There are eight interfaces defined for the MMS standard, referred to as MM1 through MM8. MM3 uses SMTP to transmit text messages to and from mobile phones. Because it can be used to transmit content, spammers can also use MMS to send spam.

You can blocklist MSISDNs or subscriber IDs to reduce MMS and email spam.

In addition to manually blocklisting or exempting MSISDNs and subscriber IDs, you can configure automatic blocklisting based upon endpoint reputation scores. If a carrier end point sends email or text messages that the FortiMail unit detects as spam, the endpoint reputation score increases. You can configure session profiles to log or block, for a period of time, email and text messages from carrier end points whose endpoint reputation score exceeds the threshold during the automatic blocklisting window.

To configure your RADIUS server

On your RADIUS server, configure the FortiMail unit as an auxiliary RADIUS server, to which it will send copies when its accounting records change.
Specify that it should send the Calling-Station-Id and Framed-IP-Address attributes to the FortiMail unit.

The data type of the value of Calling-Station-Id may vary. For 3G subscribers, the RADIUS server typically uses Calling-Station-Id to contain an MSISDN. For ADSL subscribers, the RADIUS server typically uses to contain a login ID, such as an email address.

Determine whether your RADIUS server sends the Framed-IP-Address attribute’s value in network order (e.g. 192.168.1.10) or host order (e.g. 10.1.168.192).
Verify that routing and firewall policies permit RADIUS accounting records to reach the FortiMail unit.

To enable the FortiMail unit to receive RADIUS records

Connect to the CLI.

This feature cannot be configured through the web UI. For instructions on how to connect to the CLI, see Connecting to the web UI or CLI.

Enter the following command to enable the FortiMail unit to receive RADIUS records by starting the endpoint reputation daemon:

config antispam settings

set carrier-endpoint-status enable

end

Enter the following command to configure the RADIUS secret:

config antispam settings

set carrier-endpoint-acc-secret <secret_str>

end

where <secret_str> is the secret configured on the RADIUS server.

Enter the following command to configure whether to enable or disable the FortiMail unit to validate RADIUS requests using the RADIUS secret:

config antispam settings

set carrier-endpoint-acc-validate {enable | disable}

end

where {enable | disable} indicates your choice.

Enter the following command to configure whether or not the FortiMail unit will acknowledge accounting records:

config antispam settings

set carrier-endpoint-acc-response {enable | disable}

end

where {enable | disable} indicates your choice.

Enter the following command to indicate that the RADIUS server will send the value of the Framed-IP-Address attribute in network order:

config antispam settings

set carrier-endpoint-framed-ip-order {host-order | network-order}

end

where {host-order | network-order} indicates your choice (most RADIUS servers use network order).

Removing the network interfaces from the bridge

In transparent mode, by default, network interfaces are members of a Layer 2 bridge, and have no IP addresses of their own. To connect to the web UI, administrators connect to any network interface that is a member of the bridge, using the management IP.

In this deployment example, only port1 will remain a member of the bridge. Administrators will directly connect their computer to that network interface in order to access the web UI or CLI. The network interfaces through which SMTP traffic passes, port2 and port3, will have their own IP addresses, and will not act as a Layer 2 bridge. As a result, the management IP will not be accessible from port2 and port3. In addition, all administrative access protocols will be disabled on port2 and port3 to prevent unauthorized administrative access attempts from the subscriber and external networks.

Both port2 and port3 will be connected to the same router, and do not require additional static routes.

To remove port2 and port3 from the bridge

Go to System > Network > Interface.
Double-click port2 to edit it.
Enable Do not associate with management IP.

The network interface will be removed from the bridge, and may be configured with its own IP address.

In IP/Netmask, type the IP address and netmask of the network interface.
Under Advanced Setting, next to Access, disable all administrative access protocols, including HTTPS, SSH, and PING.
Next to Administrative status, select Up.
Select OK.
Repeat this procedure for port3.

Configuring the session profiles

When configuring the protected domain and session profiles, you can select transparency, encryption, authentication, and antispam IP-based reputation settings that will be applied by an IP-based policy.

In this deployment example, you configure two session profiles:

a profile for connections from subscribers
a profile for connections from SMTP clients on the external network

FortiMail applies each profile in the IP-based policy that governs connections from either the subsurface or external network.

In both profiles, TLS-encrypted connections are not allowed in order to prevent viruses from entering or leaving the subscriber network, since encrypted connections cannot be scanned. Authentication is required to prevent spammers from connecting to open relays. No protected domains are configured, and so transparency will be configured through the session profiles alone. This will hide the existence of the FortiMail unit to all SMTP clients.

Because subscribers use dynamic IP addresses, instead of sender reputation, endpoint reputation is used in the subscribers’ session profile to score their trustworthiness. Endpoint reputation scans use RADIUS accounting notices from your RADIUS server to map subscriber end point identifiers or MSISDNs to their current IP address. Subscribers who have a reputation for sending spam or viruses will be blocked, thereby reducing the risk that your public IP addresses could be blocklisted by DNS block list (DNSBL) services.

Sender reputation, which functions best with static IP addresses and does not require a RADIUS server, will be used in the external networks’ session profile to score SMTP clients on external networks. This will help to prevent viruses and spam from reaching your subscribers.

To configure the session profile for connections from external SMTP clients

Go to Profile > Session > Session in the advanced mode of the web UI.
Select New.
In Profile name, type a name for the session profile, such as external_session_profile.
Configure the following:

Connection Setting
Hide this box from the mail server (transparent mode only)	Enable to preserve the IP address or domain name of the SMTP client in: the SMTP greeting (`HELO`/`EHLO`) and in the `Received:` message headers of email messages the IP addresses in the IP header This masks the existence of the FortiMail unitto the protected SMTP server.
Sender Reputation
Enable sender reputation	Enable to accept or reject email based upon sender reputation scores.
Throttle client at	Enter a sender reputation score over which the FortiMail unit will rate limit the number of email messages that can be sent by this SMTP client. The enforced rate limit is either Restrict number of email per hour to n or Restrict email to n percent of the previous hour, whichever value is greater.
Restrict number of email per hour to	Enter the maximum number of email messages per hour that the FortiMail unit will accept from a throttled SMTP client.
Restrict email to n percent of previous hour	Enter the maximum number of email messages per hour that the FortiMail unit will accept from a throttled SMTP client, as a percentage of the number of email messages that the SMTP client sent during the previous hour.
Temporarily fail client at	Enter a sender reputation score over which the FortiMail unit will return a temporary failure error when the SMTP client attempts to initiate a connection.
Reject client at	Enter a sender reputation score over which the FortiMail unit will return a permanent rejection error when the SMTP client attempts to initiate a connection.
Session Setting
Prevent encryption of the session (transparent mode only)	Enable to block `STARTTLS`/MD5 commands so that email connections cannot be TLS-encrypted.
Unauthenticated Session Setting
Prevent open relaying (transparent mode only)	Enable to prevent clients from using open relays to send email by blocking sessions that are unauthenticated (unauthenticated sessions are assumed to be occurring to an open relay). If you permit SMTP clients to use open relays to send email, email from their domain could be blocklisted by other SMTP servers.

Select Create.

To configure the session profile for connections from internal SMTP clients

Go to Profile > Session > Session in the advanced mode of the web UI.
Select New.
In Profile name, type a name for the session profile, such as internal_session_profile.
Configure the following:

Connection Setting
Hide this box from the mail server (transparent mode only)	Enable to preserve the IP address or domain name of the SMTP client in: the SMTP greeting (`HELO`/`EHLO`) and in the `Received:` message headers of email messages the IP addresses in the IP header This masks the existence of the FortiMail unitto the protected SMTP server.
Do not let client connect to blocklisted SMTP servers (transparent mode only)	Enable to prevent clients from connecting to SMTP servers that have been blocklisted in antispam profiles or, if enabled, the FortiGuard Antispam service. This option applies only if you have enabled Use client-specified SMTP server to send email, and only for outgoing connections.
Endpoint Reputation
Enable Endpoint Reputation	Enable to accept, monitor, or reject email based upon endpoint reputation scores. This option is designed for use with SMTP clients with dynamic IP addresses. It requires that your RADIUS server provide mappings between dynamic IP addresses and MSISDNs/subscriber IDs to the FortiMail unit.
Action	Select either: Reject: Reject email and MMS messages from MSISDNs/subscriber IDs whose endpoint reputation scores exceed Auto blocklist score trigger value. Monitor: Log, but do not reject, email and MMS messages from MSISDNs/subscriber IDs whose endpoint reputation scores exceed Auto blocklist score trigger value. Log entries appear in the history log.
Auto blocklist score trigger value	Enter the endpoint reputation score over which the FortiMail unit will add the MSISDN/subscriber ID to the automatic blocklist. The trigger score is relative to the period of time configured as the automatic blocklist window.
Auto blocklist duration	Enter the number of minutes that an MSISDN/subscriber ID will be prevented from sending email or MMS messages after they have been automatically blocklisted.
Session Setting
Prevent encryption of the session (transparent mode only)	Enable to block STARTTLS/MD5 commands so that email connections cannot be TLS-encrypted.
Unauthenticated Session Setting
Prevent open relaying (transparent mode only)	Enable to prevent clients from using open relays to send email by blocking sessions that are unauthenticated (unauthenticated sessions are assumed to be occurring to an open relay). If you permit SMTP clients to use open relays to send email, email from their domains could be blocklisted by other SMTP servers.

Configuring the IP-based policies

Session profiles are applied to IP-based policies governing SMTP client connections.

In this deployment example, two IP-based policies are configured. The first policy governs connections from the internal subscriber network. The second policy matches all other connections that did not match the first policy, and will therefore govern connections from the external network.

To configure the IP-based policy for connections from internal SMTP clients

Go to Policy > IP Policy > IP Policy in the advanced mode of the web UI.
Select New.
In Source IP/Netmask, type the IP address and netmask of your subscriber network.
In Destination, type 0.0.0.0/0 to match all SMTP server IP addresses.
From Session, select internal_session_profile.
From AntiSpam, select the name of an antispam profile. When this profile detects spam, it will affect the subscriber’s endpoint reputation score.
From AntiVirus, select the name of an antivirus profile. When this profile detects a virus, it will affect the subscriber’s endpoint reputation score.
Select Create.

The internal network policy appears at the bottom of the list of IP-based policies. Policies are evaluated in order until a policy is found that matches the connection.

Because the default IP-based policy (0.0.0.0/0 ‑‑> 0.0.0.0/0) matches all connections, and because it is first in the list, in order for connections to be able to match the new policy, you must move the new policy to an index number above the default policy.

To move a policy

Select the new IP policy and click Move.

A menu appears with four choices: Down, Up, after, Before.

Do one of the following:

Select Up to move it one position in that direction and repeat the movement until the new record is in the top position.
Select Before. A dialog appears.
In the field beside Move right before, enter 1.
Click OK.

Your new policy for internal SMTP clients should now appear above the default policy, in the row whose index number is 1.

To configure the IP-based policy for connections from external SMTP clients

Go to Policy > IP Policy > IP Policy in the advanced mode of the web UI.
Select Edit for the default policy whose Match column contains 0.0.0.0/0 ‑‑> 0.0.0.0/0.
From Session, select external_session_profile.
From AntiSpam, select the name of an antispam profile. When this profile detects spam, it will affect the SMTP client’s sender reputation score.
From AntiVirus, select the name of an antivirus profile. When this profile detects a virus, it will affect the SMTP client’s sender reputation score.
Select OK.

Configuring the outgoing proxy

Proxy pick-up is configured separately for incoming and outgoing connections.

For information on determining directionality, see Connection directionality versus email directionality.

In this deployment example, there are no protected domains; therefore, all connections are outgoing. In addition, per-domain and per-recipient Bayesian databases and per-recipient quarantines do not exist and, therefore, the FortiMail unit does not need to receive local SMTP connections in order to train databases or delete or release a domain’s recipient’s quarantined email.

The FortiMail unit must not expend resources to queue undeliverable email, nor reroute connections, and therefore it must not implicitly use its built-in MTA. Instead, it must always use its outgoing proxy by enabling Use client-specified SMTP server to send email. Because port1 is used exclusively for administration, the outgoing proxy must be configure to pick up outgoing connections only on port2 and port3.

To configure outgoing proxy pick-up

Go to System > Mail Setting > Proxies in the advanced mode of the web UI.
Enable Use client-specified SMTP server to send email
Go to System > Network > Interface.
Edit SMTP Proxy settings on both port 2 and port 3:

Port 2
	Incoming connections	Drop
	Outgoing connections	Proxy
	Local connections	Disable
Port 3
	Incoming connections	Drop
	Outgoing connections	Proxy
	Local connections	Disable

Configuring policy-based routes on the router

After you have configured the FortiMail settings, you must create policy routes on the router to redirect the SMTP traffic (from and to the subscribers) to the FortiMail unit for scanning.

For example, on the FortiGate unit as the firewall, you can create two routes: one for the external-to-subscribers SMTP traffic and one for the subscribers-to-external SMTP traffic.

For details, see the FortiGate Administration Guide.

Testing the installation

Basic configuration is now complete, and the installation may be tested. For testing instructions, see Testing the installation.

Unlike other deployments, this deployment requires that SMTP clients be configured to use the SMTP AUTH command, and not to use TLS. Before testing, you should verify that SMTP clients that will connect for themselves through the FortiMail unit meet those requirements. If some subscribers require TLS or do not use authentication, consider first making separate session profiles and IP-based policies for those subscribers.