Controlling email based on IP addresses

The IP Policies section of the Policies tab lets you create policies that apply profiles to SMTP connections based on the IP addresses of SMTP clients and/or servers.

Due to the nature of relay in SMTP, an SMTP client is not necessarily always located on an email user’s computer. The SMTP client is the connection initiator; it could be, for example, another email server or a mail relay attempting to deliver email. The SMTP server, however, is always a mail relay or email server that receives the connection.

For example, if computer A opened a connection to computer B to deliver mail, A is the client and B is the server. If computer B later opened a connection to computer A to deliver a reply email, B is now the client and A is now the server.

Like access control rules, IP-based policies can reject connections based on IP address. For information about IP pools, see Configuring IP pools.

Unlike access control rules, however, IP-based policies can affect email in many ways that occur after the session’s DATA command, such as by applying antispam profiles. IP-based policies can also be overruled by recipient-based policies, and, if the FortiMail unit is operating in server mode, may match connections based on the IP address of the SMTP server, not just the SMTP client. For more information on access control rules, see Configuring access control receiving policies.

IP-based policies can apply in addition to recipient-based policies, although recipient-based policies have precedence if the two conflict unless you enable Take precedence over recipient based policy match.

To find both IP-based and recipient-based policies that match, see Policy Lookup.

For information about how recipient-based and IP-based policies are executed and how the order of policies in the list affects the order of execution, see How to use policies.

If SMTP traffic does not match any IP-based or recipient-based policy, it is allowed. However, no antivirus or antispam protection may be applied.
If you are certain that you have configured policies to match and allow all required traffic, you can tighten security by adding an IP policy at the bottom of the policy list to reject all other, unwanted connections.
To do this, create a new IP policy, enter 0.0.0.0/0 as the client IP/netmask, and set the action to Reject. See the following procedures about how to configure an IP policy. Then, move the policy to the very bottom of the IP policy list. Because this policy matches any connection, all connections that do not match any other policy will match this final policy, and be rejected.

Profiles used by the policy, if any, are listed in the policy table, and appear as linked text. To modify profile settings, click the name of the profile.

Domain administrators can create and modify IP-based policies. Because they can affect any IP address, a domain administrator could therefore create a policy that affects another domain. If you do not want to allow this, do not grant Read-Write permission to the Policy category in domain administrators’ access profiles.

For details, see About administrator account permissions and domains.

To configure an IP-based policy

Go to Policy > IP Policy > IP Policy.
Select New to add a policy or double-click a policy to modify it.

A dialog appears that varies with the operation mode.

Configure the following settings and then click Create.

GUI item	Description
Enable	Enable or disable the policy.
Source	You can use the following types of IP addresses of the SMTP clients to whose connections this policy will apply: IP address and subnet mask IP group. See Configuring IP groups. GeoIP group. See Configuring GeoIP groups. ISDB To match all IPv4 clients, enter `0.0.0.0/0`; to match all IPv6 clients, enter `::/0`; to match both IPv4 and IPv6 clients, you must create two separate policies.
Reverse DNS pattern	To define which SMTP clients match this policy, depending on whether you enable Regular Expression, enter either a: Complete or partial domain name. Wild card characters can be used to match multiple domain names. An asterisk (``) represents one or more characters. A question mark (`?`) represents any single character. For example: .example.??? matches all sub-domains at example.com, example.net, example.org, or any other “example" domain ending with a three‑letter top-level domain name. Regular expression. Tip: To verify syntax and correct matching, click Validate. See also Appendix D: Wildcards and regular expressions and Using wildcards and regular expressions with access control. Because the domain name in the SMTP session greeting (`HELO/EHLO`) is self-reported by the connecting SMTP client, it could be fake and the FortiMail unit does not trust it. Instead, the FortiMail does a reverse DNS lookup of the SMTP client’s IP address to discover its real domain name. This is compared to the pattern. If the domain name does not match the pattern, or if the reverse DNS query fails, then the policy does not match. Note: The domain name must be a valid top level domain (TLD). For example, `.lab` is not valid because it is reserved for testing on private networks, not the Internet, and thus a reverse DNS query to DNS servers on the Internet will always fail.
Destination	If the FortiMail unit runs in transparent mode, enter the IP address of the SMTP server to whose connections this policy will apply. IP address and subnet mask IP group. See Configuring IP groups. To match all servers, enter `0.0.0.0/0`. If the FortiMail unit runs in gateway or server mode, the destination will be the FortiMail unit itself. But if you use virtual hosts on the FortiMail unit, you can specify which virtual host (IP/subnet or IP group) the email is destined to. Otherwise, you do not have to specify the destination address. If you use virtual hosts, you must also configure the DNS `MX` record to direct email to the virtual host IP addresses as well. This feature can be used to support multiple virtual hosts on a single physical interface, so that different profiles can be applied to different host and logging for each host can be separated as well.
Action	Select whether to: Scan: Accept the connection and perform any scans configured in the profiles selected in this policy. Reject: Reject the email and respond to the SMTP client with SMTP reply code 550, indicating a permanent failure. Fail Temporarily: Reject the email and respond to the SMTP client with SMTP reply code 451, indicating to try again later. Proxy Bypass: Bypass the FortiMail proxy without scanning. This action is available only if FortiMail is in transparent mode.
Comment	Optional. Enter a description or comment. The comment will appears as a mouse-over tool-tip in the ID column of the rule list.

Profile
	Session	Select the name of a session profile to have this policy apply. This option is applicable only if Action is Scan. Caution: If you are configuring an IP-based policy in transparent mode, you must select a session profile for the policy to work.
	AntiSpam	Select the name of an antispam profile to have this policy apply. This option is applicable only if Action is Scan.
	AntiVirus	Select the name of an antivirus profile to have this policy apply. This option is applicable only if Action is Scan.
	Content	Select the name of a content profile to have this policy apply. This option is applicable only if Action is Scan.
	DLP (if DLP is enable on GUI)	Select the name of a DLP profile to have this policy apply. This option is applicable only if Action is Scan.
	IP pool	Select the name of an IP pool profile, if any, that this policy will apply. An IP pool in an IP policy will be used to deliver incoming email from FortiMail to the protected server. It will also be used to deliver outgoing emails if the sender domain doesn't have a delivery IP pool or, although it has a delivery IP pool, Take precedence over recipient based policy match is enabled in the IP-based policy. An IP pool (either in an IP policy or domain settings) will be used to deliver emails to the protected domain servers if the mail flow is from internal to internal domains. When an email message’s `MAIL FROM` is empty "<>", normally the email is a NDR or DSN bounced message. FortiMail will check the IP address of the sender device against the IP list of the protected domains. If the sender IP is found in the protected domain IP list, the email flow is considered as from internal to internal and the IP pool will be skipped. FortiMail will also skip the DNS query if servers of the protected domains are configured as host names and MX record. This option is applicable only if Action is Scan. For details about IP pools, see Configuring IP pools.
Authentication and Access (not available in server mode)		This section appears only if the FortiMail unit is operating in gateway or transparent mode. For server mode, select a resource profile instead. For more information on configuring authentication, see Workflow to enable and configure authentication of email users.
	Authentication type	If you want the email user to authenticate using an external authentication server, select the authentication type of the profile (SMTP, POP3, IMAP, RADIUS, or LDAP). Note: In addition to specifying an authentication server for SMTP email messages that this policy governs, configuring Authentication profile also allows email users to authenticate when accessing their per-recipient quarantine using HTTP or HTTPS. For more information, see How to enable, configure, and use personal quarantines.
	Authentication profile	Select an existing authentication profile to use with this policy. Click New to create on or Edit to modify the selected profile.
	Allow SMTP authentication	Enable to allow the SMTP client to use the SMTP `AUTH` command, and to use the server defined in Authentication profile to authenticate the connection. Disable to make SMTP authentication unavailable. This option is available only if you have selected an Authentication profile. Note: Enabling this option allows, but does not require, SMTP authentication. To enforce SMTP authentication for connecting SMTP clients, ensure that all access control rules require authentication. For details, see Configuring access control receiving policies.
Miscellaneous
	Reject different SMTP sender identity for authenticated user	Enable to require that the sender uses the same identity for: authentication name, SMTP envelope `MAIL FROM:`, and header `FROM:`. Disable to remove such requirements on sender identities. By default, this feature is disabled.
	Sender identity verification with LDAP server	In some cases, while you do not want to allow different SMTP sender identities for an authenticated user, you still want to: allow users to authenticate with their identities (for example, user1@example.com) and send email from their proxy email addresses (for example, user1.name@example.com and user1name@example.com) or to allow users in an alias group to authenticate with their own identities (for example, salesperson1@example.com) and send email from their alias group address (for example, sales@example.com) Then you can choose to verify the sender identity with the LDAP server. If the verification is successful, the sender will be allowed to send email with different identities. Note: When the above rejection option is enabled, even though the authentication identity can be different from the sender identity upon successful LDAP verification. the envelope (`MAIL FROM:)`address is never allowed to be different from the header `FROM:)`address. And the two addresses cannot be empty either.
	Take precedence over recipient based policy match	Enable to omit use of recipient-based policies for connections matching this IP-based policy. For information on how policies are executed, see How to use policies. Note that if there is no authentication profile in a recipient based policy, but there is an authentication profile in an IP-based policy, SMTP authentication can still succeed without this feature enabled. This option is applicable only if Action is Scan. Note: Enabling this option also causes the FortiMail unit to ignore the option Hide the transparent box in the protected domain.