Controlling SMTP access and delivery
The Policy > Access Control submenu lets you configure access control and delivery policies for SMTP sessions.
Unlike proxy/implicit relay pickup, access control rules take effect after the FortiMail unit has initiated or received an IP and TCP-level connection at the application layer of the network.
Other protocols can also be restricted if the connection’s destination is the FortiMail unit. For details, see Configuring the network interfaces. |
Access control policies are categorized based on whether they affect either:
- receipt (the FortiMail unit is the destination of the SMTP session)
- delivery (the FortiMail unit is the source of the SMTP session)
This is different from the idea of incoming vs. outgoing direction in IP-based and recipient policies. For example, delivery policies can affect both incoming and outgoing mail; receiving policies can, too.
See also
Configuring access control receiving policies
Configuring access control receiving policies
The Receiving tab displays a list of access control rules that apply to SMTP sessions being received by the FortiMail unit (initiated by SMTP clients).
Access control policies, sometimes also called the access control list or ACL, specify whether the FortiMail unit will process and relay/proxy, reject, or discard email messages in SMTP sessions.
When an SMTP client tries to send email through the FortiMail unit, the FortiMail unit compares each access control policy to the commands used by the SMTP client during the SMTP session, such as:
- sender email address in the SMTP envelope (
MAIL FROM:
) - recipient email address in the SMTP envelope (
RCPT TO:
) - domain name of the SMTP client that is delivering the email
- authentication (
AUTH
) - session encryption (
STARTTLS
)
Policies are evaluated for a match in sequential order, from top to bottom of the list. If all attributes of a policy match, then the FortiMail unit applies the action in the policy or TLS profile, and stops match evaluation. Remaining access control policies, if any, are not applied.
Only one access control policy is applied to an SMTP session.
If no access control rules exist, or none match, then the action varies by whether the SMTP client authenticated: The default action varies by whether or not the recipient email address in the SMTP envelope (
See also Configuring protected domains. |
Rejecting unauthenticated SMTP clients that send email to unprotected domains prevents your email service from becoming an open relay. Open relays are abused by spammers, and therefore DNSBLs block them, so this FortiMail behavior helps to protect the reputation of your email server. Senders can deliver email incoming to your protected domains, but cannot deliver email outgoing to unprotected domains.
If you want to allow your email users or email servers to send email to unprotected domains, then you must configure at least one access control policy. You may need to configure more access control rules if, for example, you want to discard or reject email from:
- specified email addresses, such as ones that no longer exist in your protected domain
- specified SMTP clients, such as a spammer that is not yet known to public blocklists
Like IP-based policies, access control rules can reject connections based on IP address.
Unlike IP-based policies, however, access control rules cannot affect email in ways that occur after the session’s DATA
command, such as by applying antispam profiles. Access control rules also cannot be overruled by recipient-based policies, and cannot match connections based on the SMTP server (which is always the FortiMail unit itself, unless the FortiMail unit is operating in transparent mode). For more information on IP-based policies, see Controlling email based on IP addresses.
For information about the sequence in which access control rules are used relative to other antispam methods, see Order of execution.
Do not create an access control policy where:
This creates an open relay, which could result in other MTAs and DNSBL servers blocklisting your protected domain. |
To configure an access control rule
- Go to Policy > Access Control > Receiving.
- Up or Down
- After or Before, which opens a dialog, then in Move right after or Move right before indicate the policy’s new location by entering the ID of another policy
-
Either click New to add an access control rule, or double-click an access control rule to modify it.
-
Configure the following:
GUI item
Description
Select whether or not the access control rule is currently in effect.
Select either User Defined and enter a complete or partial sender email address to match, or select:
- Internal: Match any email address from a protected domain.
- External: Match any email address from an unprotected domain.
- Email Group: Match any email address in the group.
If you select this option, select an email group from the Email Group Selection field. Click New to add a new email group or Edit to modify an existing one.
For more information, see Configuring email groups. - LDAP Group: Match any email address in the group.
If you select this option, select an LDAP profile from the LDAP Profile field. - LDAP Verification: Match any individual email address queried by the LDAP profile.
If you select this option, select an LDAP profile from the dropdown list or click New to create a new one.
Note: Use
$s
to match sender addresses. For example, to reject senders that are not in the recipient's allowed sender list:- Create an ACL rule and choose LDAP verification in the sender pattern.
-
Choose a LDAP profile where below user query string is used:
&(mail=$m)(!(allowedSenders=$s)))
- Set the ACL rule action to Reject.
This will match a sender that is not in the allowedSenders list of the recipient and reject email from such senders.
- Regular Expression: Use regular expression syntax instead of wildcards to specify the pattern. Optionally, click Validate to test regular expressions and string text.See Using wildcards and regular expressions with access control.
- User Defined: Specify the email addresses. The pattern can use wildcards or regular expressions. See Appendix D: Wildcards and regular expressions. For example, the sender pattern
*@example.???
will match messages sent to any email user at example.com, example.net, or any “example” domain ending with a three-letter top-level domain name.Either select User Defined and enter a complete or partial recipient email address to match, or select:
- Internal: Match any email address from a protected domain.
- External: Match any email address from a domain that is not protected.
- Email Group: Match any email address in the group.
If you select this option, select an email group from the Email Group Selection field. Click New to add a new group, or Edit to modify an existing one.See also Configuring email groups. - LDAP Group: Match any email address in the group.
If you select this option, select an LDAP profile from the LDAP Profile field. - LDAP Verification: Match any individual email address queried by the LDAP profile.
If you select this option, select an LDAP profile from the dropdown list or click New to create a new one. - Regular Expression: Use regular expression syntax instead of wildcards to specify the pattern. Optionally, click Validate to test the regular expression. See Using wildcards and regular expressions with access control.
- User Defined: Specify the email addresses. The pattern can use wildcards or regular expressions.
Note: Use
$m
to match recipient addresses.Specify the source IP address of the SMTP client attempting to send the email message, using one of these types:
- IP/Netmask: Enter the IP address and netmask of the SMTP client.
- IP Group: Select an IP group, click New to add a new group, or click Edit to modify an existing one. See also Configuring IP groups.
- GeoIP Group. Select a GeoIP group, or click New to add a new group, or click Edit to modify an existing one. See also Configuring GeoIP groups.
- ISDB: Select an ISDB. The Internet Service Database (ISDB) is an automatically updated collection of IP addresses and subnets used by popular services such as Microsoft 365 or 8x8.
For example, you can enter
10.10.10.10/24
to match a 24-bit subnet, or all addresses starting with 10.10.10. In the access control rule table, this appears as10.10.10.0/24
, with the0
indicating that any value is matched in that position of the address.Similarly, if you enter
10.10.10.10/32
, it appears as10.10.10.10/32
because a 32-bit netmask only matches one address, 10.10.10.10 specifically.To match any address, enter
0.0.0.0/0
.Enter a pattern to compare to the result of a reverse DNS look-up of the IP address of the SMTP client delivering the email message.
Because domain names in the SMTP session
HELO/EHLO
are self-reported by the connecting SMTP server and easy to fake, the FortiMail unit does not trust the domain name that an SMTP server reports. Instead, the FortiMail does a DNS lookup using the SMTP server’s IP address. The resulting domain name is compared to the reverse DNS pattern for a match. If the reverse DNS query fails, the access control rule match will also fail. If no other access control rule matches, the connection will be rejected with SMTP reply code 550 (Relaying denied
).The pattern can use wildcards or regular expressions. If you enable Regular Expression, you may optionally click Validate to test regular expressions and string text. See Using wildcards and regular expressions with access control.
For example, the recipient pattern
mail*.com
matches messages delivered by an SMTP server whose domain name starts with “mail” and ends with “.com”.Note: Reverse DNS queries for access control rules require that the domain name be a valid top level domain (TLD). For example, “.lab” is not a valid top level domain name because it is reserved for testing on private networks, not the Internet, and thus the FortiMail unit cannot successfully perform a reverse DNS query for it.
Select whether or not to match this access control rule based on whether the sender authenticates with the FortiMail unit.
- Any: Do not consider client authentication.
- Authenticated: Match this rule only if the client authenticates.
- Not Authenticated: Match this rule only if the client did not authenticate.
If you want to allow or reject the connection based on whether the session attributes matches TLS profile, then select the TLS profile.
- Match:Action occurs.
- No Match:Action on failure in the TLS profile occurs.
Select which relay or proxy action the FortiMail unit will perform for SMTP sessions that match this access control rule.
-
Discard: Accept the email (SMTP reply code
250 OK
), but then silently delete it and do not deliver it. Do not inform the SMTP client nor recipient. -
Reject: Reject the email (SMTP reply code
550 Relaying denied
). -
Relay: Accept the email (SMTP reply code
250 OK
), regardless of authentication or protected domain. Do not greylist, but continue with remaining antispam and other scans. If all scans pass, the email is delivered. -
Receive: Like Relay, except greylist, and require authentication or protected domain.
Otherwise, if the sender does not authenticate or the recipient does not belong to a protected domain, then FortiMail rejects (SMTP reply code
554 5.7.1 Relaying denied
).Tip: Usually, the Receive action is used when you need to apply a TLS profile, but do not want to safelist nor allow outbound, which Relay does. If you do not need to apply a TLS profile, then a rule with this action is often not required because by default, email inbound to protected domains is relayed/proxied.
-
Safe: Accept the email (SMTP reply code
250 OK
) if the sender authenticates or recipient belongs to a protected domain. Greylist, but skip other remaining antispam scans. Antivirus, content monitoring, and other scans still occur.Otherwise, if the sender does not authenticate, or the recipient does not belong to a protected domain, then reject delivery of the email (SMTP reply code
554 5.7.1 Relaying denied
).In older FortiMail versions, this setting was named Bypass.
-
Safe & Relay: Like Safe, except do not greylist.
For the sequence of other antispam checks that could be skipped because of this selected option, or which affect the resulting action, see Order of execution.
Comments
Optional. Enter a description or comment. The comment will appears as a mouse-over tooltip in the ID column of the rule list.
-
Click Createor OK.
-
If you want your new policy to be evaluated before another policy, click Move and put your new policy before the other policy in the list.
Initially, the policy appears at the end of the list of policies. List order indicates order of evaluation. As a result, the new policy will match an SMTP session only if no previous policy matches.
The policy ID number may be different from the order of evaluation.
GUI item |
Description |
---|---|
Move (button) |
Select a policy, click Move, then select either: FortiMail units match the policies in sequence, from the top of the list downwards. |
Enabled |
Select to enable or disable an existing rule. |
ID |
Displays the number identifying the rule. If a comment is added to this rule when the rule is created, the comment will show up as a mouse-over tool-tip in this column. Note: This may be different from the order in which they appear on the page, which indicates order of evaluation. |
Sender |
Displays the pattern that defines matching email senders). |
Recipient |
Displays the pattern that defines matching email recipients. |
Source |
Displays the IP address and netmask of the SMTP client attempting to deliver the email message. |
Reverse DNS Pattern |
Displays whether a reverse DNS look-up is used for matching. |
Authentication Status |
Displays whether authentication status is used for matching. |
TLS Profile |
Displays the TLS profile, if any, used to allow or reject an SMTP session. |
Actions |
Displays the action to take when SMTP sessions match the rule (unless a TLS profile is used). |
Using wildcards and regular expressions with access control
Before you enable a policy that uses a regular expression, in the policy, click Validate to verify that it matches everything that you intend, and nothing that you do not intend. See also Syntax and Example regular expressions.
When you configure access control policies, do not leave any pattern fields blank. Instead, if you want the FortiMail unit to ignore a pattern:
- If Regular Expression is disabled for the field, enter an asterisk (
*
) in the pattern field. - If Regular Expression is enabled for the field, enter a dot-star (
.*
) character sequence in the pattern field.
For example, if you enter an asterisk (*
) in the Recipient and do not enable Regular Expression, then the asterisk matches all recipient addresses, and therefore all SMTP sessions can match the policy (unless one of the other criteria does not match).
See also
Example: Access control rules with wild cards
Example: Access control rules with regular expressions
Controlling SMTP access and delivery
Example: Access control rules with wild cards
If your protected domain, example.com
, contains email addresses in the format of user1@example.com
, user2@example.com
, and so on, and you want to allow those email addresses to send email to any external domain if they authenticate their identities and use TLS according to tlsprofile1
, then you might configure the following access control rule:
Enable |
|
user*@example.com |
|
* |
|
0.0.0.0/0 |
|
* |
|
Authenticated |
|
tlsprofile1 |
|
Relay |
See also
Configuring access control receiving policies
Example: Access control rules with regular expressions
Controlling SMTP access and delivery
Using wildcards and regular expressions with access control
Example: Access control rules with regular expressions
Example Corporation uses a FortiMail unit operating in gateway mode, and that has been configured with only one protected domain: example.com. The FortiMail unit was configured with the access control rules illustrated in the following table.
ID |
||||||
---|---|---|---|---|---|---|
1 |
-/* |
-/user932@example.com |
0.0.0.0/0 |
-/* |
Any |
Reject |
2 |
R/^\s*$ |
-/* |
0.0.0.0/0 |
-/* |
Any |
Reject |
3 |
-/* |
-/*@example.com |
172.20.120.0/24 |
-/mail.example.org |
Any |
Relay |
4 |
-/*@example.org |
-/* |
0.0.0.0/0 |
-/* |
Any |
Reject |
5 |
-/* |
R/^user\d*@example\.com$ |
0.0.0.0/0 |
-/* |
Any |
Relay |
Policy 1
The email account of former employee user932
receives a large amount of spam. Since this employee is no longer with the company and all of the user’s external contacts now email the replacement employee instead, email to the former employee’s address must be spam.
Policy 1 uses only Recipient and Action. All other settings are configured to match any value. This policy rejects all messages sent to the user932@example.com
recipient email address. Rejection at the access control stage prevents these messages from being scanned for spam and viruses, saving FortiMail system resources for other email that need more complex evaluation.
This policy is placed first because it is the most specific access control policy in the list. It applies only to SMTP sessions for that single recipient address. SMTP sessions sending email to any other recipient do not match it. If a policy that matched all messages were placed at the top of the list, no policy after the first would ever be checked for a match, because the first would always match.
SMTP sessions that do not match this policy are compared to the next policy.
Policy 2
Much of the spam received by Example Corporation has no sender email address specified in the SMTP envelope. Most valid email have a sender email address.
Policy 2 uses only Sender and ActionThe regular expression ^\s*$
matches sender email addresses that are empty or contain only spaces (look empty). If any non-space character appears in the sender string, then this policy does not match. The rule's action rejects email with no sender.
Not all email without a sender are spam, however. Delivery status notification (DSN) messages often have no specified sender. Bounce notifications are the most common type of DSN messages. These are legitimate email, but the FortiMail administrators at Example Corporation decided that the advantages of this policy outweigh the disadvantages.
SMTP sessions that do not match this policy are compared to the next policy.
Policies 3 and 4
Recently, Example Corporation has been receiving spam that appears to be sent by example.org
. The FortiMail log files revealed that the source IP address is being spoofed (the address in the SMTP greeting does not match) and the email are sent from servers operated by spammers. Because spam servers often change IP addresses to avoid being blocked, the FortiMail administrators decided to use two rules to block all mail from example.org
unless delivered from a server at the legitimate IP address and host name.
When legitimate, email messages from example.org
are sent from one of multiple mail servers. All these servers have IP addresses within the 172.20.120.0/24 subnet and have a domain name of mail.example.org
that can be verified using a reverse DNS query.
Policy 3 uses Recipient, Source, Reverse DNS pattern, and Action. This policy will relay messages to email users of example.com
sent from a client whose verified domain name is mail.example.org
and source IP address is between 172.20.120.1 and 172.20.120.255.
SMTP sessions that do not match this policy are compared to the next policy.
Policy 4 works with policy 3. It uses only Source and Action. Policy 4 rejects all messages from example.org
, but because it is positioned after policy 3 in the list, policy 4 affects only messages that were not already proven to be legitimate by policy 3, thereby rejecting only email messages with a fake sender.
Policies 3 and 4 must appear in that order. If their order were reversed, then all mail from example.org
would be rejected. The more specific policy 3 (accept valid mail from example.org
) must be before the more general policy 4 (reject all mail from example.org
).
SMTP sessions that do not match this policy are compared to the next policy.
Policy 5
An administrator of example.com
has noticed that during peak traffic, a flood of spam using random user names causes the FortiMail unit to devote a significant amount of resources to recipient address verification. Verification is performed by an LDAP query to their directory server which also expends significant resources servicing these requests. Example Corporation email addresses start with user
, followed by the user’s employee number, and end with @example.com
.
Policy 5 uses only Recipient and Action. The regular expression matches email addresses that follow that pattern. SMTP sessions that match this policy are relayed.
Default implicit rules
For SMTP sessions that do not match any policy, the FortiMail unit will perform the default action, which varies by whether or not the recipient email address in the SMTP envelope (RCPT TO:
) is a member of a protected domain.
- For protected domains, the default action is delivery (with greylisting).
- For unprotected domains, the default action is Reject.
See also
Configuring access control receiving policies
Example: Access control rules with wild cards
Controlling SMTP access and delivery
Using wildcards and regular expressions with access control
Configuring delivery rules
The Delivery tab displays a list of delivery rules that apply to SMTP sessions being initiated by the FortiMail unit in order to deliver email.
Delivery rules can be used to encrypt each connection with TLS, and/or to encrypt each email with secure MIME (S/MIME) (also called IBE).
When the FortiMail unit initiates an SMTP session, it compares each delivery policy to the domain name in the recipient email address (RCPT TO:
) and sender email addresses (MAIL FROM:
) in the SMTP envelope. Policies are evaluated for a match in order, from top to bottom of the list. If a match does not exist, then the email is delivered. If a match does exist, then the FortiMail unit compares the TLS profile settings to the connection attributes. Depending on the result, either the email is delivered (with encryption profile settings, if selected, and to the specified destination IP address) or the connection is not allowed. No subsequent delivery rules are applied. Only one delivery policy is ever applied to each SMTP session.
If you apply S/MIME encryption, the destination can be any email gateway or server, if either the:
- destination’s MTA or mail server
- recipient’s MUA
supports S/MIME and has the sender’s certificate and public key, which is necessary to decrypt the email. Otherwise, the recipient cannot read the email.
To configure a delivery rule
-
Go to Policy > Access Control > Delivery.
-
Either click New to add a policy, or double-click a policy to modify it.
-
Configure the following:
GUI item
Description
Enable or disable the policy.
Select how you will define the sender email addresses (
MAIL FROM:
) in the SMTP envelope that match the policy, either:-
User Defined: An email address or wild card pattern that can match multiple email addresses. In the text field below the dropdown list, enter the pattern. Wild card characters can be used to match multiple email addresses. An asterisk (
*
) represents one or more characters. A question mark (?
) represents any single character. For example:*@example.???
matches all email addresses at example.com, example.net, example.org, or any other “example" domain ending with a three‑letter top-level domain name.
- Email Group: A group of email addresses configured on the FortiMail unit. In the dropdown list below this setting, select the group name. See also Configuring email groups.
-
LDAP Group: A group of email addresses configured on a directory server such as Microsoft Active Directory. In the text field and dropdown list below this setting, enter the group of recipient email addresses that is in the directory server, and select the LDAP profile that is used for the query. See also Configuring LDAP profiles.
Note: In the LDAP query string, use
$m
to match sender email addresses. -
Regular Expression: A regular expression that can match multiple email addresses. In the text field below the dropdown list, enter the regular expression.
Tip: To verify that the regular expression is valid and only matches the email addresses that you intend, click Validate See also Appendix D: Wildcards and regular expressions and Using wildcards and regular expressions with access control.
Select how you will define the recipient email addresses (
RCPT TO:
) in the SMTP envelope that match the policy.Options are the same as Sender.
Note: For the LDAP Group option, use
$m
in the LDAP query string to match recipient email addresses.If you configured TLS profile, then select how you will define the destination IP addresses and netmasks that match the policy, either:
-
IP/Netmask: Enter the IP address and netmask.
For example, you can enter
10.10.10.10/24
to match a 24-bit subnet, or all addresses starting with 10.10.10. In the policy list, this appears as10.10.10.0/24
, with the0
indicating that any value is matched in that position of the address.Similarly, if you enter
10.10.10.10/32
, it appears as10.10.10.10/32
because a 32-bit netmask only matches one address, 10.10.10.10 specifically.To match any address, enter
0.0.0.0/0
. - IP Group: Select an IP address group. See also Configuring IP groups.
If you want to allow or reject the connection based on whether the TLS profile matches the session, select a profile.
- Match: Processing continues and delivery may occur.
- No match: Action on failure in the TLS profile occurs.
For details, see Configuring TLS security profiles.
Select an IP pool profile that FortiMail will use as its source IP address when it delivers email. For details, see Configuring IP pools.
If you want to apply S/MIME or IBE encryption to the email, select a profile. See also Configuring encryption profiles, Configuring certificate bindings, and Configuring content action profiles.
Note: If you select IBE in the content action profile, but S/MIME in Encryption profile, then IBE is overridden and not used. Destination does not affect whether to apply Encryption profile.
Optional. Enter a description or comment. If a comment exists, it is displayed as a tool tip when you mouse-over the ID column in the list of rules in the GUI.
-
-
Click Createor OK.
-
If you want your new policy to be evaluated before another policy, click Move and put your new policy before the other policy in the list.
Initially, the policy appears at the end of the list of policies. List order indicates order of evaluation. As a result, the new policy will match an SMTP session only if no previous policy matches.
The policy ID number may be different from the order of evaluation.
Rate limiting for delivery
Administrators often block MTA IP addresses that send email at a high rate because this is a common trait of spammers. Because of this, marketing mail campaigns can accidentally cause your protected domains to be registered in a DNSBL.
To prevent this problem, you can rate limit email delivery, either for a specific sender email address in a protected domain (see Sender Address Rate Control), for an entire protected domain, or all domains protected by FortiMail.
When the FortiMail unit initiates an SMTP session, each delivery rate limit policy is compared to the domain name in the recipient email address (RCPT TO:
) in the SMTP envelope. Policies are evaluated for a match in order, from top to bottom of the list. If a match does not exist, then the email is delivered with no rate control. If a match does exist, then the rate limit is applied. No subsequent delivery rate limit policies are applied. Only one delivery rate limit policy is applied to each SMTP session.
To configure a delivery control policy
-
Go to Policy > Access Control > Delivery Control.
-
Either click New to add a policy, or double-click a policy to modify it.
-
Configure the following settings, and then click Create.
GUI item
Description
Status
Enable or disable the policy.
Enter a complete or partial domain name in recipient email addresses. 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.
Restrict the number of concurrent connections
Enter the maximum concurrent SMTP connections, or enter 0 to disable the limit. Valid range is 0-100.
Restrict the number of messages per connection
Enter the maximum number of email per SMTP connection, or enter 0 to disable the limit. Valid range is 0-1000.
Restrict the number of recipients per period (30 minutes)
Enter the maximum recipients per 30 minute time span, or enter 0 to disable the limit. Valid range is 0-1000000000.
Restrict the number of recipients per message
Enter the maximum recipients per email, or enter 0 to disable the limit. Valid range is 0-1000.
See also
Incoming versus outgoing email
Which policy/profile is applied when an email has multiple recipients?