Using wildcards and regular expressions

You can enter wildcards or regular expressions in any pattern field, such as Reverse DNS pattern, on the Access Control Rule dialog.

To use a regular expression as a pattern, first select the Regular expression check box beside the pattern field.

If a pattern is listed on the Receiving tab with the R/ prefix, it is set to use regular expression syntax. If the pattern is listed with a -/ prefix, it does not use regular expression syntax.

Wildcard characters (* and ?) allow you to enter partial patterns that can match multiple reverse DNS lookup results. An asterisk (*) represents one or more characters. A question mark (?) represents any single character.

When configuring access control rules, do not leave any pattern fields blank. Instead, to have the FortiMail unit 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 Pattern field and do not enable Regular expression, the asterisk matches all recipient addresses, and therefore will not exclude any SMTP sessions from matching the access control rule.

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 as long as they authenticate their identities and use TLS, you might configure the following access control rule:

Table 52:Example access control rule

Sender Pattern	user*@example.com
Recipient Pattern	*
Sender IP/Netmask	0.0.0.0/0
Reverse DNS Pattern	*
Authentication Status	authenticated
TLS Profile	tlsprofile1
Action	RELAY

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 Table 53. Table 53:A list of example access control rules

Enabled	ID	Sender Pattern	Recipient Pattern	Sender IP/Netmask	Reverse DNS Pattern	Authent ication	TLS Profile	Action
Yes	1	-/*	-/user932@e xample.com	0.0.0.0/0	-/*	Any		REJECT
Yes	2	R/^\s*$	-/*	0.0.0.0/0	-/*	Any		REJECT
Yes	3	-/*	-/*@example. com	172.20.120. 0/24	-/mail.exam ple.org	Any		RELAY
Yes	4	-/*@exa mple.or g	-/*	0.0.0.0/0	-/*	Any		REJECT
Yes	5	-/*	R/^user\d*@ example\.co m$	0.0.0.0/0	-/*	Any		RELAY

Rule 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 the user’s external contacts were informed of their new Example Corporation employee contacts, messages addressed to the former employee’s address must be spam.

Rule 1 uses only the recipient pattern. All other access control rule attributes are configured to match any value. This rule 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.

This rule is placed first because it is the most specific access control rule 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 rule that matched all messages were placed at the top of the list, no rule after the first would ever be checked for a match, because the first would always match.

SMTP sessions not matching this rule are checked against the next rule.

Rule 2

Much of the spam received by the Example Corporation has no sender specified in the message envelope. Most valid email messages will have a sender email address.

Rule 2 uses only the sender pattern. The regular expression ^\s*$ will match a sender string that contains one or more spaces, or is empty. If any non-space character appears in the sender string, this rule does not match. This rule will reject all messages with a no sender, or a sender containing only spaces.

Not all email messages 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. The FortiMail administrators at the Example Corporation decided that the advantages of this rule outweigh the disadvantages.

Messages not matching this rule are checked against the next rule.

Rules 3 and 4

Recently, the Example Corporation has been receiving spam that appears to be sent by example.org. The FortiMail log files revealed that the sender address is being spoofed and the messages 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 with the proper 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.

Rule 3 uses the recipient pattern, the sender IP, and the reverse DNS pattern. This rule will relay messages to email users of example.com sent from a client whose domain name is mail.example.org and IP address is between 172.20.120.1 and 172.20.120.255.

Messages not matching this rule are checked against the next rule.

Rule 4 works in conjunction with rule 3. It uses only the sender pattern. Rule 4 rejects all messages from example.org. But because it is positioned after rule 3 in the list, rule 4 affects only messages that were not already proven to be legitimate by rule 3, thereby rejecting only email messages with a fake sender.

Rules 3 and 4 must appear in the order shown. If they were reversed, all mail from example.org would be rejected. The more specific rule 3 (accept valid mail from example.org) is placed first, and the more general rule 4 (reject all mail from example.org) follows.

Messages not matching these rules are checked against the next rule.

Rules 5

The 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 verification. Verification is performed with the aid of an LDAP 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”.

Rule 5 uses only the recipient pattern. The recipient pattern is a regular expression that will match all email addresses that start with “user”, end with “@example.com”, and have one or more numbers in between. Email messages matching this rule are relayed.

Default implicit rules

For messages not matching any of the above rules, the FortiMail unit will perform the default action, which varies by whether or not the recipient email address in the envelope (RCPT TO:) is a member of a protected domain.

• For protected domains, the default action is RELAY.
• For unprotected domains, the default action is REJECT.