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
- Configuring action profile preferences
- 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 configure local SMTP server settings
- Go to System > Mail Setting > Mail Server Setting.
- Configure the following sections as needed:
A multisection page appears.
- Configuring local host settings
- Configuring SMTP service
- Configuring IMAP service
- Configuring POP3 service
- Configuring mail queue settings
- Configuring outgoing email options
- Configuring DSN options
- 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 |
|
Enter the host name of the FortiMail unit. Displays the FortiMail unit’s fully qualified domain name (FQDN) is in the format:
such as 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. |
|
|
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:
such as 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. |
|
|
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. |
Configuring SMTP service
Use this section to configure SMTP service settings for the mail server. For the configured settings to take effect, enable SMTP Service.
|
GUI item |
Description |
| SMTP port | Enter the port number on which the FortiMail unit’s SMTP server will listen for SMTP connections. The default port number is 25. |
| SMTPS port |
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 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. |
| 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 | 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. |
| Authentication | Enable SMTP, SMTPS, and/or SMTP over TLS authentication. |
| MTA-STS service |
Enable MTA Strict Transport Security (MTA-STS) domain checking:
Once enabled, MTA-STS domain checking can be utilized in a TLS security profile. For more information, see To configure a TLS profile |
Configuring IMAP service
Use this section to configure IMAP service settings for the mail server. For the configured settings to take effect, enable IMAP Service.
|
GUI item |
Description |
| IMAP port | Enter the IMAP port number. |
| IMAPS port | Enter the IMAPS port number. |
Configuring POP3 service
Use this section to configure POP3 service settings for the mail server. For the configured settings to take effect, enable POP3 Service.
|
GUI item |
Description |
| POP3 port | Enter the POP3 port number. |
| POP3S port | Enter the POP3S port number. |
Configuring mail queue settings
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 |
|
|
|
|
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. |
|
|
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 SMTP 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 |
|
|
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 settings) 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:
DSN messages are not sent for the following potential states:
|
|
EHLO/HELO option |
Specify the argument to use for DSN EHLO/HELO:
|
|
Sender displayname |
Displays the name of the sender, such as If this field is empty, the FortiMail unit uses the default name of |
|
Sender address |
Displays the sender email address in DSN. If this field is empty, the FortiMail unit uses the default sender email address of |
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 |
|
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 and the domain lookup is successful, the email is considered to be incoming and the corresponding incoming policies will be applied. |
|
|
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. |
|
|
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:
See also
Configuring mail server settings
Configuring proxies (transparent mode only)
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 configure disclaimer messages
- Go to System > Mail Setting > Disclaimer.
- Configure the following:
|
GUI item |
Description |
|
|
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. Enable and enter the message header key in the field, and the values in the With value field. FortiMail adds this text to the message header of the email before forwarding it to the recipient. The maximum length is 256 characters. Many email clients can sort incoming email messages into separate mailboxes, such as an external email mailbox, based on text appearing in various parts of email messages, including the subject line. For details, see the documentation for your email client. Message header lines are composed of two parts: a key and a value, which are separated by a colon. For example, you might enter: X-Custom-Header: ALERT-External email from outside of our organization. If you enter a header line that does not include a colon, the FortiMail unit will automatically append a colon, causing the entire text that you enter to be the key. Note: Do not enter spaces in the key portion of the header line, as these are forbidden by RFC 2822. |
|
|
Tag subject |
Enable and enter the text that appears in the subject line of the email, such as Many email clients can sort incoming email messages into separate mailboxes, such as an external email mailbox, based on text appearing in various parts of email messages, including the subject line. For details, see the documentation for your email client. |
|
|
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. |
|
External email only (Incoming only) |
Enable if you want to insert a header warning disclaimer cautioning against any email originating from outside your organization. |
|
|
Enable disclaimer exclusion list |
Enable if you do not want to insert disclaimers to the email messages from certain senders or to certain recipients. 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 source IP netmasks, 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, recipient pattern, and/or source IP/mask.
- Click Create.
For example, for sender pattern, if you add *@example.com, all messages from example.com users will be exempted from disclaimer insertion.
For source IP/mask, if you add 1.1.1.0/24, and both sender and recipient pattern are set to * (wildcard), then emails within the specified IP range are exempted from disclaimer insertion.
See also
Configuring global disclaimers
Customizing the GUI appearance
Configuring action profile preferences
When configuring antispam, antivirus, and/or content action profiles, you may choose to deliver to an alternate host, or send it to either the system or personal quarantine. In addition, you may choose to deliver or quarantine the original email or the modified email. For example, when the HTML content is converted to text, if you choose to deliver the unmodified copy, the HTML version will be delivered. If you choose to deliver the modified copy, the plain text version will be delivered.
You can also specify other action preferences as follows.
To configure action profile preferences
- Go to System > Mail Setting > Preference.
- Select either Modified copy or Unmodified copy for each appropriate option.
-
For Disclaimer insertion, select whether to insert the disclaimer in either:
- Selected message: Only new email. New email is detected when FortiMail finds the same domain in both the
Message-ID:andIn-Reply-To:/References:message headers. This avoids repeatedly inserting disclaimers in email threads where the recipient has already seen the disclaimer before. RFC 2822 specifies that those message headers are optional, and therefore some email clients do not support them. For those email clients, this setting does not have an effect. - All message: All email.
- Selected message: Only new email. New email is detected when FortiMail finds the same domain in both the
- For Subject tag location, specify either tagging at the start or end of the subject line.
- Additionally, enable or disable delivery action enforcement (if either Deliver to alternate host or Deliver to original host is enabled), and enable or disable the execution of attachment scanning on any spam in the personal quarantine.
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)
Non-Supported NFS servers
If you do not need consolidated storage for the mail queue and email user inboxes, the higher FortiMail models 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. Any FortiMail model can be a client.
To configure mail data storage
- Go to System > Mail Setting > Storage.
- Configure the following:
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
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
|
Configuration |
Result |
|||
|---|---|---|---|---|
|
SMTP server (incoming connection) |
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 |
|||
|
Not SMTP server (outgoing connection) |
N/A |
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 |
||
|
Relay Server section is not configured |
Built-in MTA performs MX lookup of the domain in |
|||
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.
See also
Incoming versus outgoing SMTP connections
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
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.
See also
Incoming versus outgoing SMTP connections
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.
The following image and table show the topology and configuration options that result in correct mail routing for this scenario.
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 |
|
enabled |
|
|
port1’s Incoming connections |
Pass through or Drop |
|
port1’s Outgoing connections |
Pass through |
|
port2’s Incoming connections |
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.
The following image and table show the topology and configuration options that result in correct mail routing for this scenario.
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 |
|
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).
See also
Incoming versus outgoing SMTP connections
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 > Preference 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. |