Antispam

Sophos UTM can be configured to detect unsolicited spam emails and to identify spam transmissions from known or suspected spam purveyors. Configuration options located on the Antispam tab let you configure SMTP security features aimed at preventing your network from receiving unsolicited commercial emails.

Note – Outgoing emails will be scanned if the checkbox Scan relayed (outgoing) messages on the Relaying tab is selected.

Note – Some of the features on this tab are not available with BasicGuard subscription.

Spam Detection During SMTP Transaction

You have the possibility to reject spam already during SMTP Simple Mail Transfer Protocol transaction. Select one of the following settings for the option Reject at SMTP Time:

• Off: Spam detection is disabled and no email is going to be rejected for spam reasons.
• Confirmed spam: Only confirmed spam is rejected.
• Spam: All emails that the system regards as spam are rejected. Note that there may be a higher false positive rate because emails regarded as probable spam may be rejected such as newsletters.

Emails which are not rejected during SMTP transaction will be treated according to your settings in the Spam Filter section below.

In Profile Mode: This setting cannot be changed per profile. Messages with more than one recipient will skip this feature if one of the recipient profiles has spam scanning completely turned off. This means it is advisable to leave the regular spam scanning setting set to either Spam or Confirmed spam.

RBLs (Realtime Blackhole Lists)

A Realtime Blackhole List (RBL) is a means by which an Internet site may publish a list of IP addresses linked to spamming.

Use recommended RBLs: Selecting this option causes the mail transfer agent to query external databases of known spam senders (so-called Realtime Blackhole Lists). Messages sent from a site included in one or more of such lists can easily be rejected. Several services of this type are available on the Internet. This function massively helps to reduce the amount of spam.
By default, the following RBLs are queried:

• Sophos SXL
• cbl.abuseat.org

Note – The list of RBLs queried by Sophos UTM is subject to change without notice. Sophos does not warrant for the contents of these databases.

You can also add further RBL Realtime Blackhole List sites to enhance the antispam capability of Sophos UTM. To do so, click the Plus icon in the Extra RBL zones box. In the appearing textbox, enter the RBL zone.

Click Apply to save your settings.

Spam Filter

Sophos UTM includes a heuristic check of emails for characteristics suggestive of spam. It uses SMTP envelope information and an internal database of heuristic tests and characteristics. This spam filtering option scores messages based on their content and SMTP envelope information. Higher scores indicate a higher spam probability.

With the following two options you can specify what to do with messages that have been assigned a certain spam score. This ensures that potential spam emails are treated differently by the gateway.

• Spam action: Here you can define what to do with messages that are classified as probable spam. Note that there may be false positives, such as newsletters, thus blackholing may lead to email loss.
• Confirmed spam action: Here you can define what to do with confirmed spam messages.

You can choose between different actions for those two types of spam:

• Off: No messages will be marked as spam or filtered out.
• Warn: No messages will be filtered out. Instead, for incoming messages, a spam flag will be added to the message's header and a spam marker will be added to the message's subject. Outgoing messages will be sent without action.
• Quarantine: Messages will be blocked and stored in the email quarantine. Quarantined messages can be reviewed either through the User Portal or the daily Quarantine Report.
• Blackhole: Incoming messages will be accepted and instantly removed. Outgoing messages will never be blackholed to avoid unintended mail loss. They will be quarantined instead.

Spam marker: With this option you can specify a spam marker, that is, a string that will be added to the message's subject line making it easy to identify spam messages quickly. By default, the string *SPAM* is used to tag messages as spam.

Sender Blacklist

The envelope sender of incoming SMTP sessions will be matched against the addresses on this blacklist. If the envelope sender is found on the blacklist the message will be rejected during SMTP time. Settings in the Reject at SMTP time field do not affect this function. Mails blocked due to the personal sender blacklist (User Portal) will be quarantined.
To add a new address pattern to the blacklist click the Plus icon in the Blacklisted Address Patterns box, enter (a part of) an address, and click Apply. You can use an asterisk (*) as a wildcard, e.g., *@abbeybnknational.com. A wildcard does not work in the domain or TLD part of an address.

Tip – End-users can create their personal blacklist and whitelist in the User Portal.

Expression Filter

The expression filter scans messages' content passing through the SMTP proxy for specific expressions. Suspicious emails will be blocked. Expressions can be entered as Perl Compatible Regular Expressions (with max. 128 characters). Simple strings such as "online dating" are interpreted in a case-insensitive manner. Click Apply to save your settings.

Cross Reference – For detailed information on using regular expressions in the expression filter, see the Sophos Knowledge Base.

Advanced Antispam Features

This area gathers various other advanced options increasing the antispam capability of Sophos UTM.

Reject invalid HELO/missing RDNS: Select this option if you want to reject hosts that send invalid HELO A command in the Simple Mail Transfer Protocol (SMTP) with which the client responds to the initial greeting of the server. entries or lack RDNS Reverse Domain Name Service entries. If you want to exempt hosts from this check, please refer to the Exceptions tab.

Do strict RDNS checks: Select this option if you want to additionally reject mail from hosts with invalid RDNS records. An RDNS record is invalid if the found hostname does not resolve back to the original IP address.

Use greylisting: Greylisting basically means the temporary rejection of emails for a certain amount of time. Typically, a mail server using greylisting will record the following pieces of information for all incoming messages:

• The sender address
• The IP Internet Protocol address of the host the message is sent from
• The recipient address
• The message subject

This data set is checked against the SMTP proxy's internal database; if the data set has not been seen before, a record is created in the database along with a special time stamp describing it. This data set causes the email to be rejected for a period of five minutes. After that time the data set is known to the proxy and the message will be accepted when it is sent again. Note that the data set will expire after 30 days if it is not updated within this period.
Greylisting uses the fact that most senders of spam messages use software based on the "fire-and-forget" method: Try to deliver the mail and if it doesn’t work, forget it! This means that senders of spam mail do not try to send emails again when there is a temporary failure, contrary to RFC Request for Comment-conform mail servers. The assumption is that since temporary failures are built into the RFC specifications for email delivery, a legitimate server will try again to send the email later, at which time the destination will accept it.

Use BATV: BATV Bounce Address Tag Validation is a draft of the IETF, facing the challenge to distinguish legitimate uses from unauthorized uses of email addresses. BATV provides a method to sign the envelope sender of outgoing mail by adding a simple shared key to encode a hash of the address and time-varying information as well as some random data proving that the email was really sent by you. It is basically used to reject bounce messages not sent by you. By using BATV, you can now check if bounces you receive are really caused by your initial email, and not from a spammer forging an email with your address. If a bounce returns and the email address is not signed according to BATV, the SMTP proxy will not accept the message. Note that the signature provided by BATV expires after seven days. To change the key (also known as BATV secret) that is used to encode the hash of an email's envelope MAIL FROM address, go to the Email Protection > SMTP > Advanced tab.

Note – Some mail transfer agents may reject a message whose envelope sender address was modified using BATV. In this case, you need to create an exception rule for the senders, recipients, or domains affected.

Perform SPF check: SPF (Sender Policy Framework) is a framework where domain owners can publish information about their outgoing email servers. Domains use public records to direct requests for different services (web, email, etc.) to the machines that perform those services. All domains already publish MX records for email related services to let others know what machines receive mail for the domain. SPF works by domains publishing some sort of "reverse MX" records to tell the world what machines send mail from the domain. When receiving a message from a certain domain, the recipient can check those records to make sure that mail is coming from where it should be coming from.

Cross Reference – Further information is available at the Sender Policy Framework website.

As an additional antispam feature, the SMTP proxy tacitly checks each recipient address it receives with your backend mail server(s) before accepting mail for this address. Emails for invalid recipient addresses will not be accepted. In order for this function to work, your backend mail server(s) must reject mails for unknown recipients at the SMTP stage. The general rule is that if your backend server rejects a message, the SMTP proxy will reject it, too.

Note, however, that recipient verification is not done for trusted (authenticated) or relay hosts, because some user agents may encounter problems when recipients get rejected in the SMTP transaction. In the usual scenario (backend mail server rejects unknown recipients in the SMTP transaction), Sophos UTM will only generate bounces in the following cases:

• When a trusted or relay source sends a message to an undeliverable recipient.
• When the backend mail server has been down so that Sophos UTM was not able to verify the recipient.

However, Sophos UTM does not prevent your backend mail server(s) from sending non-delivery reports (NDRs) or bounces. In addition, Sophos UTM caches positive callout replies from the mail server for 24 hours, and negative ones for two hours.