Transparent mode deployment
The following procedures and examples show you how to deploy the FortiMail unit in transparent mode.
- Configuring DNS records
- Example 1: FortiMail unit in front of an email server
- Example 2: FortiMail unit in front of an email hub
- Example 3: FortiMail unit for an ISP or carrier
Configuring DNS records
If the FortiMail unit is operating in transparent mode, in most cases, configuring DNS records for protected domain names is not required. Proper DNS records for your protected domain names are usually already in place. However, you usually must configure public DNS records for the FortiMail unit itself.
For performance reasons, and to support some configuration options, you may also want to provide a private DNS server for exclusive use by the FortiMail unit.
This section includes the following:
- Configuring DNS records for the FortiMail unit itself
- Configuring a private DNS server
Configuring DNS records for the FortiMail unit itself
In addition to that of protected domains, the FortiMail unit must be able to receive web connections, and send and receive email, for its own domain name. Dependent features include:
- delivery status notification (DSN) email
- spam reports
- email users’ access to their per-recipient quarantined mail
- FortiMail administrators’ access to the web UI by domain name
- alert email
- report generation notification email
For this reason, you should also configure public DNS records for the FortiMail unit itself.
Appropriate records vary by whether or not Web release host name/IP (located in AntiSpam > Quarantine > Quarantine Report in the advanced mode of the web UI) is configured:
- Case 1: Web Release Host Name/IP is empty/default
- Case 2: Web Release Host Name/IP is configured
Unless you have enabled both Hide the transparent box in each protected domain and Hide this box from the mail server in each session profile, the FortiMail unit is not fully transparent in SMTP sessions: the domain name and IP address of the FortiMail unit may be visible to SMTP servers, and they might perform reverse lookups. For this reason, public DNS records for the FortiMail unit usually should include reverse DNS (RDNS) records.
Case 1: Web Release Host Name/IP is empty/default
When Web release host name/IP is not configured (the default), the web release/delete links that appear in spam reports use the fully qualified domain name (FQDN) of the FortiMail unit. For example, if the FortiMail unit’s host name is fortimail, and its local domain name is example.net, resulting in the FQDN fortimail.example.net, a spam report’s default web release link might look like (FQDN highlighted in bold):
https://fortimail.example.net/releasecontrol?release=0%3Auser2%40examp le.com%3AMTIyMDUzOTQzOC43NDJfNjc0MzE1LkZvcnRpTWFpbC00MDAsI0YjUyM2N TkjRSxVMzoyLA%3D%3D%3Abf3db63dab53a291ab53a291ab53a291
In the DNS configuration to support this and the other DNS-dependent features, you would configure the following three records:
example.net IN MX 10 fortimail.example.net fortimail IN A 10.10.10.1 1 IN PTR fortimail.example.net.
where:
- net is the local domain name to which the FortiMail unit belongs; in the MX record, it is the local domain for which the FortiMail is the mail gateway
- example.net is the FQDN of the FortiMail unit
- fortimail is the host name of the FortiMail unit; in the A record of the zone file for example.net, it resolves to the IP address of the FortiMail unit for the purpose of administrators’ access to the web UI, email users’ access to their per-recipient quarantines, to resolve the FQDN referenced in the MX record when email users send Bayesian and quarantine control email to the FortiMail unit, and to resolve to the IP address of the FortiMail unit for the purpose of the web release/delete hyperlinks in the spam report
- 10.10.1 is the public IP address of the FortiMail unit
Case 2: Web Release Host Name/IP is configured
You could configure Web release host name/IP to use an alternative fully qualified domain name (FQDN) such as webrelease.example.info instead of the configured FQDN, resulting in the following web release link (web release FQDN highlighted in bold):
https://webrelease.example.info/releasecontrol?release=0%3Auser2%40exa mple.com%3AMTIyMDUzOTQzOC43NDJfNjc0MzE1LkZvcnRpTWFpbC00MDAsI0YjUyM 2NTkjRSxVMzoyLA%3D%3D%3Abf3db63dab53a291ab53a291ab53a291
Then, in the DNS configuration to support this and the other DNS-dependent features, you would configure the following MX record, A records, and PTR record (unlike “Case 1: Web Release Host Name/IP is empty/default” on page 52, in this case, two A records are required; the difference is highlighted in bold):
example.net IN MX 10 fortimail.example.net fortimail IN A 10.10.10.1 webrelease IN A 10.10.10.1 1 IN PTR fortimail.example.net.
where:
- net is the local domain name to which the FortiMail unit belongs; in the MX record, it is the local domain for which the FortiMail is the mail gateway
- example.net is the FQDN of the FortiMail unit
- fortimail is the host name of the FortiMail unit; in the A record of the zone file for example.net, it resolves to the IP address of the FortiMail unit for the purpose of administrators’ access to the web UI and to resolve the FQDN referenced in the MX record when email users send Bayesian and quarantine control email to the FortiMail unit
- webrelease is the web release host name; in the A record of the zone file for example.info, it resolves to the IP address of the FortiMail unit for the purpose of the web release/delete hyperlinks in the spam report
- 10.10.1 is the public IP address of the FortiMail unit
Configuring a private DNS server
Consider providing a private DNS server on your local network to improve performance with features that use DNS queries.
Figure 11:Public and private DNS servers (transparent mode)
172.16.1.10 Private DNS Server Public DNS Server
Email Domain: example.com IN MX 10 mail.example.com example.com IN MX 10 mail.example.com
@example.com mail IN A 172.16.1.10 mail IN A 10.10.10.1
In some situations, a private DNS server may be required. If:
- you configure the FortiMail unit to use a private DNS server, and
- both the FortiMail unit and the protected SMTP server reside on the internal network, with private network IP addresses, and • you enable the Use MX record option you should configure the A records on the private DNS server and public DNS server differently: the private DNS server must resolve to the domain names of the SMTP servers into private IP addresses, while the public DNS server must resolve them into public IP addresses.
For example, if both a FortiMail unit (fortimail.example.com) operating in transparent mode and the SMTP server reside on your private network behind a router or firewall as illustrated in Figure 7 on page 53, and the Use MX record option is enabled, Table 9 on page 81 illustrates differences between the public and private DNS servers for the authoritative DNS records of example.com.
Table 9: Public versus private DNS records when “Use MX Record” is enabled
Private DNS server | Public DNS server |
example.com IN MX 10 mail.example.com | example.com IN MX 10 mail.example.com |
mail IN A 172.16.1.10 | mail IN A 10.10.10.1 |
10 IN PTR fortimail.example.com | 1 IN PTR fortimail.example.com |
If you choose to add a private DNS server, to configure the FortiMail unit to use it, go to System > Network > DNS in the advanced mode of the web UI.
when configuring transparent mode is it necessary to configure mail settings (SMTP port, SSL for SMTP etc.). From my understanding is not necessary because Fortimail acts as a proxy. But if these are not configured connection is not intercepted(scanned).
kindly expound on active-passive H/A deployment for two Fortimails in transparent mode in an ISP environment where we use PBRs on the connected routers. Am keen on the IPs to be used on the PBR and if this can be done without using an ADC.