Configuring mail settings

Go to System > Mail Setting to configure assorted settings that apply to the SMTP server and webmail server that are built into the FortiMail unit.

This section includes:

Configuring mail server settings
Configuring SMTP relay hosts
Configuring global disclaimers
Configuring disclaimer exclusion list
Selecting the mail data storage location
Configuring proxies (transparent mode only)

Configuring mail server settings

Use the mail server settings to configure SMTP server/relay settings of the System domain, which is located on the local host (that is, your FortiMail unit).

To access this part of the web UI, your administrator account’s:

Domain must be System
access profile must have Read or Read-Write permission to the Others category

For details, see About administrator account permissions and domains.

To configure local SMTP server settings

Go to System > Mail Setting > Mail Server Settings.

A multisection page appears.

Configure the following sections as needed:

Configuring local host settings
Configuring mail queue setting
Configuring outgoing email options
Configuring mail queue setting
Configuring deferred message delivery
Configuring domain check options

Configuring local host settings

Provide the name and SMTP information for the mail server.

GUI item	Description
Host name	Enter the host name of the FortiMail unit. Displays the FortiMail unit’s fully qualified domain name (FQDN) is in the format: `<host-name>.<local-domain-name>` such as `fortimail-400.example.com`, where `fortimail‑400` is the Host name and `example.com` is the Local domain name. Note: The FQDN of the FortiMail unit should be different from that of protected SMTP servers. If the FortiMail unit uses the same FQDN as your mail server, it may become difficult to distinguish the two devices during troubleshooting. Note: You should use a different host name for each FortiMail unit, especially when you are managing multiple FortiMail units of the same model, or when configuring a high availability (HA) cluster. This will let you to distinguish between different members of the cluster. If the FortiMail unit is in HA mode, the FortiMail unit will add the host name to the subject line of alert email messages. For details, see Configuring alert email.
Local domain name	Enter the local domain name to which the FortiMail unit belongs. The local domain name is used in many features such as email quarantine, Bayesian database training, quarantine report, and delivery status notification (DSN) email messages. FortiMail unit’s fully qualified domain name (FQDN) is in the following format: `<host-name>.<local-domain-name>` such as `fortimail-400.example.com`, where `fortimail-400` is the Host name and `example.com` is the Local domain name. Note: The IP address should be globally resolvable into the FQDN of the FortiMail unit if it will relay outgoing email. If it is not globally resolvable, reverse DNS lookups of the FortiMail unit’s domain name by external SMTP servers will fail. For quarantine reports, if the FortiMail unit is operating in server mode or gateway mode, DNS records for the local domain name may need to be globally resolvable to the IP address of the FortiMail unit. If it is not globally resolvable, web and email release/delete for the per-recipient quarantines may fail. Note: The Local domain name is not required to be different from or identical to any protected domain. It can be a subdomain or different, external domain. For example, a FortiMail unit whose FQDN is fortimail.example.com could be configured with the protected domains example.com and accounting.example.net. When sending out quarantine reports, if the FortiMail local domain name is different from its protected domains, FortiMail will use its local domain name, because the local domain name is unique; however, if the FortiMail local domain is the same as one of its protected domains, FortiMail will use its FQDN to send out reports, so as to distinguish itself from the protected domains or other subdomains.
SMTP server port number	Enter the port number on which the FortiMail unit’s SMTP server will listen for SMTP connections. The default port number is 25.
SMTP over SSL/TLS	Enable to allow SSL- and TLS-secured connections from SMTP clients that request SSL/TLS. When disabled, SMTP connections with the FortiMail unit’s built-in MTA must occur as clear text, unencrypted. Note: This option must be enabled to receive SMTPS connections. However, it does not require them. To enforce client use of SMTPS, see Configuring access control rules.
SMTPS server port number	Enter the port number on which the FortiMail unit’s built-in MTA listens for secure SMTP connections. The default port number is 465. This option is unavailable if SMTP over SSL/TLS is disabled.
SMTP MSA service	Enable let your email clients use SMTP for message submission on a separate TCP port number from deliveries or mail relay by MTAs. For details on message submission by email clients as distinct from SMTP used by MTAs, see RFC 2476.
SMTP MSA port number	Enter the TCP port number on which the FortiMail unit listens for email clients to submit email for delivery. The default port number is 587.
POP3 server port number	Enter the port number on which the FortiMail unit’s POP3 server will listen for POP3 connections. The default port number is 110. This option is available only if the FortiMail unit is operating in server mode.
Default domain for authentication	If you set one domain as the default domain, users on the default domain only need to enter their user names without the domain part for webmail/SMTP/IMAP/POP3 authentication, such as user1. Users on the non-default domains must enter both the user name part and domain part to authentication, such as user2@example.com.
Webmail access	Enable to redirect HTTP webmail access to HTTPS.

Configuring mail queue setting

Use these sections to configure mail queues and the use of Extended Simple Mail Transfer Protocol (ESMTP).

For more information on the FortiMail mail queue, see Managing the mail queue and Managing undeliverable mail.

GUI item		Description
Mail Queue section
	Maximum time for email in queue	Select the maximum number of hours that deferred email messages can remain in the deferred or quarantined e mail queue, during which the FortiMail unit periodically retries to send the message. After it reaches the maximum time, the FortiMail unit sends a final delivery status notification (DSN) email message to notify the sender that the email message was undeliverable.
	Maximum time for DSN email in queue	Select the maximum number of hours a delivery status notification (DSN) message can remain in the mail queues. After it reaches the maximum, the FortiMail unit moves the DSN email to the dead mail folder. If set to zero (0), the FortiMail unit attempts to deliver the DSN only once.
	Time before delay warning	Select the number of hours after an initial failure to deliver an email message before the FortiMail unit sends the first delivery status notification (DSN) message to notify the sender that the email message was deferred. After sending this initial DSN, the FortiMail unit continues trying to sending the email until reaching the limit configured in Maximum time for email in queue.
	Time interval for retry	Select the number of minutes between delivery retries for email messages in the deferred and spam mail queues.
	Dead mail retention period	Enter the number of days that undeliverable email and its associated DSN will be kept in the dead mail folder. After this time, the dead email and its DSN are automatically deleted.

Configuring outgoing email options

For outgoing email, you can specify to use an STMP relay, instead of the FortiMail built-in MTA, to deliver email.

Under some circumstance, connections from certain relays may by blocked by other parties. If you have other backup relays, you can use them instead.

For information about adding STMP relays, see Configuring SMTP relay hosts.

GUI item		Description
Deliver to relay host		Select a relay that you configured in Configuring SMTP relay hosts.
Disable ESMTP		Mark the check box to disable (ESMTP) for outgoing email. By default, FortiMail units can use ESMTP commands. ESMTP supports email messages with graphics, sound, video, and text in various languages. For more information on ESMTP, see RFC 1869.
Delivery Failure Handling		When email delivery fails, you can choose to use the mail queue settings (Configuring mail queue setting) to handle the temporary or permanent failures. You can also try another relay that you know might work.
	Normal	Select this option if you want to queue the email and use the mail queue settings.
	Deliver to relay host	Select another relay (backup relay) that you want to use for failed deliveries. Then specify how long the undelivered email should wait in the normal queue before trying the backup relay. You can also specify which types of failed connections the backup relay should take over and retry: DNS failure: failed DNS lookups Temporary failure from remote MTA (4XX reply code) Permanent failure from remote MTA (5XX reply code) Network failure -- connection Network failure -- other

Configuring DSN options

Use this section to configure mail server delivery status notifications.

For information on failed deliveries, see Managing the mail queue and Managing undeliverable mail.

GUI item	Description
DSN (NDR) email generation	Enable to allow the FortiMail unit to send DSN messages to notify email users of delivery delays and/or failure. Note that if the email message triggers an antispam or antivirus profile, no DSN message will be sent. If it triggers a content profile, a DSN message will still be sent. The following are the potential states in which DSN messages are sent: SPF=Pass SPF=None SPF=Neutral SPF=PERM-Error SPF=TEMP-Error SPF=Sender Alignment DSN messages are not sent for the following potential states: SPF=Soft Fail SPF=Hard Fail
Sender displayname	Displays the name of the sender, such as `FortiMail administrator`, as it should appear in DSN email. If this field is empty, the FortiMail unit uses the default name of `postmaster`.
Sender address	Displays the sender email address in DSN. If this field is empty, the FortiMail unit uses the default sender email address of `postmaster@<domain_str>`, where <`domain_str>` is the domain name of the FortiMail unit, such as `example.com`.

Configuring deferred message delivery

You can choose to defer delivery those email that may be resource intensive and reduce performance of the mail server:

large email messages
lower priority email from certain senders, for example, marketing campaign email and mass mailing

For improved FortiMail performance, schedule delivery during times when email traffic volume is low, such as nights and weekends.

To set a deferral period, configure both of the following:

In Start delivering messages at, select the hour and minute of the day at which to begin delivering email messages.
In Stop delivering messages at, select the hour and minute of the day at which to stop delivering email messages.

To configure the size limit or senders of deferred email, see Configuring content profiles.

Configuring domain check options

Use this section for LDAP compatibility.

If the domain lookup option is also enabled in the LDAP profile (see Configuring domain lookup options), the parent domain from the domain lookup query is used to hold domain association.

GUI item	Description
Perform LDAP domain verification for unknown domains	Enable to verify the existence of domains that are not configured as protected domains. Also configure LDAP profile for domain check. To verify the existence of unknown domains, the FortiMail unit queries an LDAP server for a user object that contains the email address. If the user object exists, the verification is successful, and: If Automatically create domain association for verified domain is enabled, the FortiMail unit automatically adds the unknown domain as a domain associated of the protected domain selected in Internal domain to hold association. If Automatically create domain association for verified domain is disabled, and the LDAP domain name lookup of the unknown domain name is successful, the FortiMail unit routes the email to the IP address resolved for the domain name during the lookup. Because the domain is not formally defined as a protected domain, the email is considered to be outgoing, and outgoing recipient-based policies are used to scan the email. For more information, see Controlling email based on sender and recipient addresses.
LDAP profile for domain check	Select the LDAP profile to use when verifying existence of unknown domains. The LDAP query is configured under User Query Options in an LDAP profile. If you also enable the domain lookup option in the LDAP profile, the option must be enabled for the domain. This option is available only if Perform LDAP domain verification for unknown domains is enabled.
Automatically create domain association for verified domain	Enable to automatically add unknown domains as domain associations if they are successfully verified by the LDAP query. See Configuring domain lookup options. For more information about domain association, see Domain Association. This option is available only if Perform LDAP domain verification for unknown domains is enabled.
Internal domain to hold domain association	Select the name of a protected domain with which to associate unknown domains, if they pass domain verification. However, if the domain lookup query (see Configuring domain lookup options) returned its own parent domain, that parent domain is used. This option is available only if Automatically create domain association for verified domain is enabled.

Configuring SMTP relay hosts

Configure one or more SMTP relays, if needed, to which the FortiMail unit will relay outgoing email. This is typically provided by your Internet service provider (ISP), but could be mail relays on your internal network.

When you configure mail server settings (Configuring outgoing email options), you can specify to use a relay host for outgoing email.

If the SMTP relay’s domain name resolves to more than one IP address, for each SMTP session, the FortiMail unit will randomly select one of the IP addresses from the result of the DNS query, effectively load balancing between the SMTP relays.

If you do not configure a relay, for outgoing email delivered by the built-in MTA, the FortiMail unit will instead query the DNS server for the MX record of the mail domain in the recipient’s email address (RCPT TO:), and relay the email directly to that mail gateway. For details, see When FortiMail uses the proxies instead of the built-in MTA.

Server relay is ignored if the FortiMail unit is operating in transparent mode, and Use client-specified SMTP server to send email (for outgoing connections) or Use this domain’s SMTP server to deliver the mail (for incoming connections containing outgoing email messages) is enabled.

Server relay is ignored for email that matches an antispam or content profile where you have enabled Deliver to alternate host.

To configure SMTP relays

Go to System > Mail Setting > Relay Host List. You can configure a maximum of five relays.
Click New.
Configure the following:

GUI item	Description
Name	Enter a descriptive name for this relay host.
Host name/IP	Enter the domain name or IP address of an SMTP relay.
Port	Enter the TCP port number on which the SMTP relay listens. This is typically provided by your Internet service provider (ISP).
Use SMTPS sic	Enable to initiate SSL- and TLS-secured connections to the SMTP relay if it supports SSL/TLS. When disabled, SMTP connections from the FortiMail unit’s built-in MTA or proxy to the relay will occur as clear text, unencrypted. This option must be enabled to initiate SMTPS connections.
Authentication Required	If the relay server requires use of the SMTP `AUTH` command, enable this option, click the arrow to expand the section and configure: User name: Enter the name of the FortiMail unit’s account on the SMTP relay. Password: Enter the password for the FortiMail unit’s user name. Authentication type: Available SMTP authentication types include: AUTO (automatically detect and use the most secure SMTP authentication type supported by the relay server) PLAIN (provides an unencrypted, scrambled password) LOGIN (provides an unencrypted, scrambled password) DIGEST-MD5 (provides an encrypted hash of the password) CRAM-MD5 (provides an encrypted hash of the password, with hash replay prevention, combined with a challenge and response mechanism) NTLM (supports NT LAN Manager protocols and provides an hashed password)

Configuring global disclaimers

The System > Mail Setting > Disclaimer tab lets you configure system-wide disclaimer messages.A disclaimer message is text that is generally attached to email to warn the recipient that the email contents may be confidential.

Disclaimers can be appended to both incoming and outgoing email. For an explanation of directionality, see Inbound versus outbound email.

If Allow per-domain settings is enabled, you can configure disclaimer messages that are specific to each protected domain. For more information, see Disclaimer for a domain.

To access this part of the web UI, your administrator account’s:

Domain must be System
access profile must have Read or Read-Write permission to the Others category

For details, see About administrator account permissions and domains.

To configure disclaimer messages

Go to System > Mail Setting > Disclaimer.
Configure the following:

GUI item		Description
Allow per-domain settings		Enable to allow protected domains to select from either the system-wide disclaimer messages, configured below, or their own separate disclaimer messages. Disable to require that all protected domains use the system-wide disclaimer messages. If this option is disabled, domain-specific disclaimers cannot be configured. For information on configuring disclaimer messages specific to a protected domain, see Disclaimer for a domain.
Outgoing (or Incoming)
	Insert new header	Enable to insert a new header to the email and append a disclaimer message to the new header, then enter the disclaimer message. The maximum length is 256 characters.
	Insert disclaimer at	Select to insert the disclaimer at the end or start of the email and click Edit to author a disclaimer. This disclaimer can be in HTML or text. The maximum length is 1024 characters.
Enable disclaimer exclusion list		If you do not want to insert disclaimers to the email messages from certain senders or to certain recipients, you can enable this option. For details about disclaimer exclusion list, see Configuring disclaimer exclusion list.

Configuring disclaimer exclusion list

In some cases, you may not want to insert disclaimers to some email messages. For example, you may not want to insert disclaimers to paging text or SMS text messages. To do this, you add the specific senders, sender domains, recipients, or recipients domains to the exclusion list, and when you configure the global disclaimer settings (see Configuring global disclaimers), you can enable the exclusion list.

To create a disclaimer exclusion list

Go to System > Mail Setting > Disclaimer Exclusion List.
Click New to create or new list or double click on an existing one to edit it.
Enter a sender pattern and/or recipient pattern. For example, for sender pattern, if you add *@example.com, all messages from example.com users will be exempted from disclaimer insertion.
Click Create.

Selecting the mail data storage location

The System > Mail Setting > Storage tab lets you configure local or remote storage of mail data such as the mail queues, email archives, email users’ mailboxes, quarantined email, and IBE encrypted email.

FortiMail units can store email either locally or remotely. FortiMail units support remote storage by a centralized quarantine, and/or by a network attached storage (NAS) server using the network file system (NFS) protocol.

NAS has the benefits of remote storage which include ease of backing up the mail data and more flexible storage limits. Additionally, you can still access the mail data on the NAS server if your FortiMail unit loses connectivity.

If the FortiMail unit is a member of an active-passive HA group, and the HA group stores mail data on a remote NAS server, disable mail data synchronization to prevent duplicate mail data traffic. For details, see Configuring the HA mode and group.

If you store the mail data on a remote NAS device, you cannot back up the data. You can only back up the mail data stored locally on the FortiMail hard disk. For information about backing up mail data, see Configuring mailbox backups.

If you choose remote storage, mail data will not be duplicated locally. Mail data on remote storage cannot be transferred back to local storage either, if you choose to switch to local storage later.

Tested and Supported NFS servers

Linux NAS
FreeNAS
Openfiler
EMC VNXe3150 (version 2.4.2.21519(MR4 SP2))
EMC Isilon S200 (OneFS 7.1.0.3)

Untested NFS servers

Buffalo TeraStation
Cisco Linksys NAS server

Non-Supported NFS Servers

Windows 2003 R2 /Windows 2008 Service for NFS

If you do not need consolidated storage for the mail queue and email user inboxes, the higher FortiMail models (FortiMail VM02/400C series and above) can act as a centralized quarantine server and IBE encrypted email storage server. If applicable to your model, the Receive quarantined messages from clients option and the Receive IBE messages from clients option appear on the Storage tab.

FortiMail VM02, VM04, 400C, 400E, and 1000D models can host a maximum of 10 clients and FortiMail VM08/2000E and above models can host up to 20 clients. Any FortiMail model can be a client.

To access this part of the web UI, your administrator account’s:

Domain must be System
access profile must have Read or Read-Write permission to the Others category

For details, see About administrator account permissions and domains.

To configure mail data storage

Go to System > Mail Setting > Storage.
Configure the following:

GUI item		Description
Option
	Local	Select to store email on the FortiMail unit’s local disk or RAID.
	NAS server	Select to store email on a remote network attached storage (NAS) server, such as a FortiAnalyzer unit.
	Test (button)	Click to verify the NAS server settings are correct and that the FortiMail unit can access that location. The test action basically tries to discover, login, mount, and unmount the remote device. This button is available only when NAS server is selected.
	Protocol	Select a type of the NAS server: NFS: To configure a network file system (NFS) server. For this option, enter the following information: Hostname/IP address: the IP address or fully qualified domain name (FQDN) of the NFS server. Port: the TCP port number on which the NFS server listens for connections. Directory: the directory path of the NFS export on the NAS server where the FortiMail unit will store email. iSCSI Server: To configure an Internet SCSI (Small Computer System Interface) server. For this option, enter the following information: Username: the user name of the FortiMail unit’s account on the iSCSI server. Password: the password of the FortiMail unit’s account on the iSCSI server. Hostname/IP address: the IP address or fully qualified domain name (FQDN) of the iSCSI server. Port: the TCP port number on which the iSCSI server listens for connections. Encryption key: the key that will be used to encrypt data stored on the iSCSI server. Valid key lengths are between 6 and 64 single-byte characters. iSCSI ID: the iSCSI identifier in the format expected by the iSCSI server, such as an iSCSI Qualified Name (IQN), Extended Unique Identifier (EUI), or T11 Network Address Authority (NAA). Status: When available. it indicates if the iSCSI share was successfully mounted on the FortiMail unit’s file system. This field appears only after you configure the iSCSI share and click Apply. Status may take some time to appear if the iSCSI server is slow to respond. If Not mounted appears, the iSCSI share was not successfully mounted. Verify that the iSCSI server is responding and the FortiMail unit has both read and write permissions on the iSCSI server.
	Refresh (button)	This button appears when you configure an iSCSI server. Click it to update the information in the Status field.
	Click here to format this device Click here to check file system on this device	These two links appear when you configure an iSCSI server and click Apply. Click a link to initiate the described action (that is, format the device or check its file system). A message appears saying the action is being executed. Click OK to close the message and click Refresh to see a Status update. Note: If the ISCSI disk has never been formatted, FortiMail needs to format it before it can be used. If the disk has been formatted before, you do not need to format it again. unless you want to wipe out the data on it.
Centralized Quarantine
	Disabled	Select to store the quarantines on the FortiMail unit’s local disk or RAID.
	Receive quarantined messages from clients	Select to have this FortiMail unit act as a centralized quarantine server, then enter the IP addresses of all valid clients. This option is available on some high end models. FortiMail VM02, 400E, 1000D and 2000E models can host a maximum of 10 clients and FortiMail 3000 series and above models can host up to 20 clients. Any FortiMail model can be a client. Other FortiMail units acting as clients send all their quarantined email to this FortiMail unit. This FortiMail unit only accepts a connection if the client’s IP address matches an IP address on the list of clients configured here.
	Send quarantined messages to remote server	Select to have this FortiMail unit act as a centralized quarantine client. All quarantined email is saved on a centralized quarantine server, if available. When selected, enter the following information: Over SSL: Select to send quarantined messages over SSL. Hostname/IP address: Enter home name or IP address of the FortiMail unit that is acting as a centralized quarantine server.
Centralized IBE
	Disabled	Select to store IBE encrypted email on the FortiMail unit’s local disk or RAID.
	Receive IBE messages from clients	Select to have this FortiMail unit act as a centralized IBE mail storage server, then enter the IP addresses of all valid clients which are the FortiMail units that are configured to send IBE messages to this unit. This option is available on some high end models. FortiMail VM02, 400E, 1000D and 2000E models can host a maximum of 10 clients and FortiMail 3000 series and above models can host up to 20 clients. Any FortiMail model can be a client. Other FortiMail units acting as clients send all their IBE email to this FortiMail unit. This FortiMail unit will only accept a connection if the client’s IP address matches an IP address on the list of clients configured here. Note: The protected domains on the IBE mail server must match the domains on the clients. Otherwise the secure mail recipients cannot retrieve their secure email from the server.
	Send IBE messages to remote server over SSL	Select to have this FortiMail unit act as a centralized IBE storage client. All IBE email will be saved on the centralized IBE mail storage server, if available. When selected, enter the following information: Name: Enter a name to identify this client to the centralized IBE mail storage server. This value must match the name of the client as it is configured on the centralized IBE mail storage server. Otherwise, the connection will fail. Host: Enter the IP address of the FortiMail unit that is acting as a centralized IBE mail storage server.

Configuring proxies (transparent mode only)

In addition to the proxy settings under each network interface settings, you can also go to System > Mail Setting > Proxies to configure connection pick-up of the proxies and implicit relay.

Furthermore, the protected domains and session profiles also configure aspects of the proxies and implicit relay, such as transparency. For details, see Configuring protected domains and Configuring session profiles.

This section contains the following topics:

About the transparent mode proxies
Use client-specified SMTP server to send email

About the transparent mode proxies

FortiMail has two transparent proxies: an incoming proxy and an outgoing proxy. The proxies’ degree of transparency at the IP layer and at the SMTP layer varies by your configuration. Proxy behaviors are configured separately based on whether the SMTP connection is considered to be incoming or outgoing. Depending on your configuration, a FortiMail unit operating in transparent mode may implicitly use its built-in MTA instead.

Depending on your network topology, verify that email is not being scanned twice.

Incoming versus outgoing SMTP connections
Transparency of the proxies and built-in MTA
Avoiding scanning email twice
Relaying using FortiMail’s built-in MTA versus unprotected SMTP servers

When FortiMail uses the proxies instead of the built-in MTA

When operating in transparent mode, a FortiMail unit has two ways of handling an SMTP connection: to proxy, or to relay. A FortiMail unit will proxy a connection only if you have enabled the proxy option applicable to the connection’s directionality, either:

Use client-specified SMTP server to send email (for outgoing connections), or
Use this domain’s SMTP server to deliver the mail (for incoming connections containing outgoing email messages)

This option is ignored for email that matches an antispam or content action profile where you have enabled Deliver to alternate host.

Otherwise, it will use its built-in MTA instead.

Unlike in gateway mode, in transparent mode, the built-in MTA is used implicitly. SMTP clients do not explicitly connect to it, but unless proxied, all connections traveling through the FortiMail unit are implicitly handled by the built-in MTA. In this sense, while in transparent mode, the built-in MTA may initially seem to be similar to the proxies, which are also used implicitly, and not specifically requested by the SMTP client. However, the proxies or the built-in MTA may reroute connections to different destination IP addresses, and thereby may affect mail routing.

Because the outgoing proxy does not queue undeliverable email or apply authentication, while the built-in MTA and incoming proxy do, whether a proxy or the built-in MTA handles a connection may also affect the FortiMail unit’s mail queues and authentication Verify.

Mail routing in transparent mode

Destination IP of connection	`RCPT TO:`	Configuration		Result
SMTP Server (incoming connection)	A protected domain (incoming email)	N/A		Built-in MTA establishes session with SMTP Server
	A protected domain (incoming email)	N/A		Built-in MTA establishes session with SMTP Server
	Not a protected domain (outgoing email)	Use this domain’s SMTP server to deliver the mail is enabled		Incoming queueing proxy establishes session with Use this domain’s SMTP server to deliver the mail
		Use this domain’s SMTP server to deliver the mail is disabled	Relay Server section is configured	Built-in MTA establishes session with Relay Server section
			Relay Server section is not configured	Built-in MTA performs MX lookup of the domain in `RCPT TO:` and establishes session with the resulting MTA
Not SMTP Server (outgoing connection)	N/A	Use client-specified SMTP server to send email is enabled		Outgoing non-queueing proxy establishes session with the unprotected MTA
		Use client-specified SMTP server to send email is disabled	Relay Server section is configured	Built-in MTA establishes session with Relay Server section
		Use client-specified SMTP server to send email is disabled	Relay Server section is not configured	Built-in MTA performs MX lookup of the domain in `RCPT TO:` and establishes session with the resulting MTA

You can determine whether a connection was handled using the built-in MTA or one of the proxies by viewing the Mailer column of the history log messages.

mta: The connection was handled by the built-in MTA.
proxy: The connection was handled by either the incoming proxy or the outgoing proxy.

For information on viewing the history log, see Viewing log messages.

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

Use client-specified SMTP server to send email

Incoming versus outgoing SMTP connections

At the network connection level, directionality is determined by the destination IP address.

Incoming connections

The destination IP address matches a protected domain’s SMTP Server field.

Outgoing connections

The destination IP address does not match any protected domain’s SMTP Server field.

Connection level directionality does not consider a connection’s source IP address, nor whether or not the recipient email address’s (RCPT TO:) mail domain is a protected domain.

Incoming versus outgoing SMTP connections

Directionality at the connection level may be different than directionality at the level of email messages contained by the connection. It is possible that an incoming connection could contain an outgoing email message, and vice versa.

For example, in Incoming versus outgoing SMTP connections, connections from the internal mail relays to the internal mail servers are outgoing connections, but they contain incoming email messages. Conversely, connections from remote MUAs to the internal mail relays are incoming connections, but may contain outgoing email messages if the recipients’ email addresses (RCPT TO:) are external.

For information on the concept of incoming versus outgoing at the application layer, see Inbound versus outbound email.

When the FortiMail unit is operating in transparent mode, directionality correlates with which proxy will be used, if any.

For example, in Incoming versus outgoing SMTP connections, the protected domain is example.com. Mailboxes for example.com are stored on servers located at the company’s headquarters, separate from the mail relays, which are located at a branch office. All email is routed through the mail relays, and so the FortiMail unit is deployed in front of the mail relays at the branch office.

On the FortiMail unit, you have configured the protected domain’s SMTP Server to be 192.168.0.1, a mail relay, because all email must be routed through that mail relay. You have also enabled Use client-specified SMTP server to send email, so, for outgoing connections, the outgoing proxy will be used instead of the built-in MTA. However, you have not enabled Use this domain’s SMTP server to deliver the mail, so, for incoming connections, the built-in MTA will be used, rather than the incoming proxy.

You can configure interception and transparency separately for each of the two proxies. Regardless of which proxy is used, the proxy may not be fully transparent unless you have configured it to be so. For details, see Transparency of the proxies and built-in MTA.

See also

Avoiding scanning email twice

Transparency of the proxies and built-in MTA

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

When FortiMail uses the proxies instead of the built-in MTA

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.

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

When FortiMail uses the proxies instead of the built-in MTA

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). 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.

Configuring mail settings shows the configuration options that result in correct mail routing for this desired scenario. Avoiding scanning email twice: Example 1 topology shows the mail routing that would result from this configuration, in this topology.

Avoiding scanning email twice: Example 1 topology

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.

Configuring mail settings shows the configuration options that result in correct mail routing for this desired scenario. Avoiding scanning email twice: Example 2 topology shows the mail routing that would result from this configuration, in this topology.

Avoiding scanning email twice: Example 2 topology

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
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. As a 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.

For example, 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 Incoming versus outgoing SMTP connections).

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 (for outgoing connections) and Use this domain’s SMTP server to deliver the mail (for incoming connections containing outgoing email messages).

Transparency of the proxies and built-in MTA

When FortiMail uses the proxies instead of the built-in MTA

Use client-specified SMTP server to send email

In FortiMail transparent mode, go to System > Mail Setting > 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, 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.

If this option is enabled, consider also enabling Prevent open relaying. Failure to do so could allow clients to use open relays.

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.

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.