Migrating email from other mail servers (server mode only)

If you already have other mail servers, such as Exchange or FortiMail server, and you want to consolidate the mail user and data into one FortiMail server, you can do so by migrating the users and data to your FortiMail unit.

The email migration process involves the following procedures:

1. Preparation
   1. Enable the mail migration feature using the following CLI commands. config system global

set email-migration-status enable

end

414. Define the remote mail server settings. For details, see “Defining a remote mail server for mail migration” on page 414.
415. Create a domain for the to-be-migrated users. In v5.0 release, the domain name must be the same as the users’ domain on the remote mail server. Beginning from v5.0.1 release, the domain name can be different. For details, see “Creating domains for mail migration” on page 414.

2. User migration: Because FortiMail will act as an IMAP client on behalf of the users to get their email from the remote mail server, you must import the user/password information first. To do this, you can use one of the following methods:
   • If you only need to migrate email for a few users and you know the users’ login credentials, you can manually enter their user name/password information by going to Mail Settings > Mail Migration > Migration Users and click New.
   • If you can export the user name/non-encrypted password list into a CSV file, you can import the CSV file by going to Mail Settings > Mail Migration > Migration Users and click Action > Import > .CSV File.
   • If the to-be-migrated users already have accounts on the FortiMail server, you can import/copy the local user list to the migration user list by going to Mail Settings > Mail Migration > Migration Users and click Action > Import > All Local Users.
   • If the user passwords are encrypted, you have to collect their passwords through FortiMail webmail login or SMTP client login. To do this:
     543. First create an authentication profile that uses the remote mail server as the authentication server. For details, see “Configuring authentication profiles” on page 543.
     544. Create a recipient-based policy that includes the migration users as senders and also includes the authentication profile. For details, see the “Controlling email based on recipient addresses” on page 468.

• Finally, you can inform the users to use FortiMail host name as their outgoing mail server.

After you have done the above, when the users try to send email, they will have to authenticate through FortiMail. Then FortiMail will record the user names and passwords into the migration user list under Mail Settings > Mail Migration > Migration Users.

3. Mail data migration: After you have migrated the users, you can start to migrate the their mail boxes from the remote server. To do this:
   1. Go to Mail Settings > Mail Migration > Migration Users.
   2. From the Action dropdown list, select Migrate > Selected Users or All Users. iii. If needed, you can click the Stop and Start button to control the migration process.
   3. After the user’s mail data is successfully migrated, you can export the user to the local user list by clicking Action > Export > Selected Users or All Users. The exported users will appear as local users under User > User.

Defining a remote mail server for mail migration

This is one of the email migration procedures. For the entire procedures, see “Migrating email from other mail servers (server mode only)” on page 412.

1. Go to Mail Settings > Mail Migration > Remote Mail Server.
2. Click New.
3. Enter a name for the remote server.
4. Enter the host name or IP address of the remote server.
5. For Protocol, select either IMAP or IMAPS, FortiMail will act as an IMAP client on the users’ behalf to get email from the remote server.
6. Enter the IMAP port number if different from the default one (port 993).
7. Click Create.

Creating domains for mail migration

This is one of the email migration procedures. For the entire procedures, see “Migrating email from other mail servers (server mode only)” on page 412.

1. Go to Mail Settings > Domains > Domains.
2. Click New.
3. Configure the settings as described in “Configuring protected domains” on page 380.
4. Since you have enabled mail migration, a new section called Mail Migration Settings appears at the bottom of the domain settings page. Expand this section and configure the following settings.
5. Check Enable mail migration.
6. Specify the remote mail server from the dropdown list. See “Defining a remote mail server for mail migration” on page 414.
7. Click Create.

Configuring proxies (transparent mode only)

In addition to the proxy settings under each network interface settings, you can also go to Mail Settings > 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” on page 380 and “Configuring session profiles” on page 482.

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

Table 48:Mail routing in transparent mode

Destination IP of connection

RCPT TO:

Configuration

Result

Table 48:Mail routing in transparent mode

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 SMTP server
		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-specifie d 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 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” on page 206.

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.

Figure 167: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 Figure 167 on page 417, 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.

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

For example, in Figure 167 on page 417, 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” on page 418.