Sender Domain Reputation Filtering

This chapter contains the following sections:

Overview of Sender Domain Reputation Filtering

Cisco Talos Sender Domain Reputation (SDR) is a cloud service that provides a reputation verdict for email messages based on the domains provided in the email envelope and header. Examples may include domains from - HELO/EHLO strings, envelope and header "From" addresses, "Reply-to" addresses, and "List-Unsubscribe" headers.

The domain-based reputation analysis enables a higher spam catch rate by looking beyond the reputation of shared IP addresses, hosting or infrastructure providers, and derives verdicts based on features that are associated with fully qualified domain names (FQDNs) and other sender information in the Simple Mail Transfer Protocol (SMTP) conversation and message headers.

For more information, see the Cisco Talos Sender Domain Reputation (SDR) white paper in the Security Track of the Cisco Customer Connection program at http://www.cisco.com/go/ccp.


Note

  • You must create a Cisco Customer Connection account to access the SDR white paper.

  • Like Cisco IPAS disputes, submit SDR disputes by opening a support request with the Cisco Technical Assistance Center (TAC).


SDR Verdicts

The following table lists the SDR verdict names, descriptions, and recommended actions:

Table 1. SDR Verdicts

Verdict Name

Description

Recommended Action

Awful

The worst reputation verdict.

Expect to see false-negatives (FN) if the blocking threshold is set to only this verdict, which prioritizes delivery over security.

Block the message.

Poor

The recommended blocking threshold.

This balances the trade-offs between false-negatives (FN) and false-positives (FP). Talos tunes SDR so that messages that are blocked by SDR have either a poor or awful verdict.

Not blocking on this verdict prioritizes delivery over security, but it results in false-negatives that the customer accepts when not blocking based on this verdict.

Scan the message with the other engines configured on your email gateway.

Tainted

The sender reputation is suspect.

Blocking based on these verdicts is aggressive and not recommended by Talos. It promotes security over delivery, but it results in false-positives that you can accept when blocking based on this verdict.

Scan the message with the other engines configured on your email gateway.

Weak

A common verdict for many domains (including legitimate and mixed-use) associated with weak indicators that preclude a neutral verdict. Talos does not recommend blocking on this verdict.

While this prioritizes security over Delivery, it results in an unacceptable number of False-Positives (as per Talos) when you block messages based on this verdict.

Scan the message with the other engines configured on your emal gateway.

Unknown

The sender is using a newly registered domain or one that SDR does not otherwise recognize. For domains in this undetermined state, Talos performs further analysis to establish a verdict quickly. Talos does not recommend blocking on this verdict. Blocking on this verdict results in many False Positives that you accept when adjusting their threshold to this verdict. Talos recommends quarantining messages with a verdict of “unknown.”

The message delivery is slightly delayed to allow time for Talos to investigate the domain before scanning the message with subsequent engines.

Scan the message with the other engines configured on your emal gateway.

Neutral

The normal expected verdict when the sender is using a domain that is not new and adheres to the sender best practices. The following are the sender best practices - using SPF, DKIM-signing, not sending spam, etc.

Scan the message with the other engines configured on your emal gateway.

Good

A rare verdict that indicates the sender is using a certified domain where messages are DKIM signed (aligned on the “From:” header domain).

Scan the message with the other engines configured on your emal gateway.

How to Filter Messages based on Sender Domain Reputation

Steps

Do This

More Information

Step 1

Enable SDR filtering on Cisco Email Security Gateway.

Note 
After you upgrade to AsyncOS 12.0, SDR queries are enabled by default.

Enabling Sender Domain Reputation Filtering on Email Gateway

Step 2

Configure a message or content filter to handle messages based on SDR.

Configuring Message or Content Filter for Handling Messages based on Sender Domain Reputation

Step 3

Attach the content filter that you configured to filter messages based on SDR to an incoming mail policy.

Attaching Content Filter to Incoming Mail Policy

Enabling Sender Domain Reputation Filtering on Email Gateway


Note

After you upgrade to AsyncOS 12.0, SDR queries are enabled by default.


Procedure


Step 1

Go to Security Services > Domain Reputation.

Step 2

Click Enable.

Step 3

Check Enable Sender Domain Reputation Filtering.

Step 4

(Optional) Check Include Additional Attributes if you want the SDR service to check for SDR based on additional attributes of the message.

If you enable this option, the following additional attributes of the message are included in the SDR check to improve the efficacy:

  • Username part of the email address present in the 'Envelope From:,' 'From:,' and 'Reply-To:' headers.

  • Display name in the 'From:' and 'Reply-To:' headers.

Step 5

(Optional) Enter the number of elapsed seconds before the SDR query times out.

Note 

Modifying the SDR query timeout value may impact the performance of mail processing.

Step 6

(Optional) Check Match Domain Exception List based on Domain in Envelope From: if you want the email gateway to skip the SDR check based on the domain in the Envelope From: header only.

Step 7

Click Submit .

Step 8

(Optional) Click I Agree if you want to accept the SDR Include Additional Attributes Agreement message.

Note 

The SDR Include Additional Attributes Agreement message appears only when you select the Include Additional Attributes option.

Step 9

Click Commit to commit your changes.


What to do next

Configure a content or message filter to handle messages based on SDR. See Configuring Message or Content Filter for Handling Messages based on Sender Domain Reputation.

Configuring Message or Content Filter for Handling Messages based on Sender Domain Reputation

You can use the ‘Domain Reputation’ message or content filter in any one of the following ways to filter messages based on SDR, and take appropriate actions on such messages:

  • Sender Domain Verdict

  • Sender Domain Age

  • Sender Domain Unscannable

Related Topics

Filtering Messages based on Sender Domain Reputation using Message Filter

Filtering Messages based on Sender Domain Verdict


Note

The recommended blocking threshold is "Awful." For more information about SDR verdicts, see SDR Verdicts.


Syntax:

drop_msg_based_on_sdr_verdict:
if sdr-reputation (['awful', 'poor'], "<domain_exception_list>")
{drop();}

Where:

  • 'drop_msg_based_on_sdr_verdict'is the name of the message filter.

  • 'sdr-reputation' is the Domain Reputation message filter rule.

  • 'awful','poor' is the range of the sender domain verdict used to filter messages based on SDR.

  • 'domain_exception_list' is the name of a domain exception list. If a domain exception list is not present it is displayed as "".

  • 'drop' is the action applied on the message.

Example

In the following message, if the SDR verdict is 'Unknown', the message is quarantined.

quarantine_unknown_sdr_verdicts:
if sdr-reputation (['unknown'], "")
{quarantine("Policy")}

Filtering Messages based on Sender Domain Age

Syntax:

<msg_filter_name> 
if sdr-age (<‘unit'>, <‘operator'> <‘actual value’>)
{<action>}

Where:

  • ‘sdr-reputation' is the Domain Reputation message filter rule.

  • ‘sdr_age’ is the age of the sender domain used to filter messages based on SDR.

  • ‘unit' is the number of ‘days,’ ‘years,’ ‘months,’ or 'weeks' option used to filter messages based on the sender domain age.

  • ‘operator' are the following comparison operators used to filter messages based on the sender domain age:

    • – > (Greater than)

    • – >= (Greater than or equal to)

    • – < (Lesser than)

    • – <= (Lesser than or equal to)

    • – == (Equal to)

    • – != (Not equal to)

    • – Unknown

  • ‘actual value' is the number used to filter messages based on the sender domain age.

Examples

In the following message, if the age of the sender domain is unknown, the message is dropped.

Drop_Messages_Based_On_SDR_Age: if (sdr-age ("unknown", "")) {drop();}

In the following message, if the age of the sender domain is less than one month, the message is dropped.

Drop_Messages_Based_On_SDR_Age: if (sdr-age ("months", <, 1, "")) { drop(); }

Filtering Messages based on Sender Domain Unscannable

Syntax:

<msg_filter_name> 
if sdr-unscannable (<'domain_exception_list'>)
{<action>}

Where:

  • 'sdr-unscannable' is the Domain Reputation message filter rule.

    'domain_exception_list' is the name of a domain exception list. If a domain exception list is not present it is displayed as "".

Example

In the following message, if the message failed the SDR check, the message is quarantined.

Quarantine_Messages_Based_On_Sender_Domain_Unscannable: if (sdr-unscannable ("")) {quarantine("Policy");}

Filtering Messages based on Sender Domain Reputation using Content Filter

Before you begin

  • (Optional) Create an address list that contains only domains. To create one, go to Mail Policies > Address Lists page in the web interface or use the addresslistconfig command in the CLI. For more information, see Mail Policies.

  • (Optional) Create a Domain Exception List. For more information, see Creating Domain Exception List.

Procedure


Step 1

Go to Mail Policies > Incoming Content Filters.

Step 2

Click Add Filter.

Step 3

Enter a name and description for the content filter.

Step 4

Click Add Condition.

Step 5

Click Domain Reputation.

Step 6

Choose any one of the following conditions to filter messages based on SDR:

  • Select Sender Domain Reputation Verdict to choose a verdict range to filter messages based on the verdict received from the SDR service.

    Note 

    The recommended blocking threshold is "Awful." For more information about SDR Verdicts, see SDR Verdicts.

  • Select Sender Domain Age, choose the comparison operator, enter a number, and choose the time period to filter messages based on the age of the sender domain.

  • Select Sender Domain Reputation Unscannable to filter messages that failed the SDR check.

Step 7

(Optional) Select the list of allow listed domains that you do not want the email gateway to filter messages based on SDR.

Step 8

Click Add Action to configure an appropriate action to take on messages based on SDR.

Step 9

Submit and commit your changes.


Creating Domain Exception List

A domain exception list consists of a list of addresses that contain only domains. You can use a domain exception list to skip the SDR check for all incoming messages, irrespective of the mail policies configured on your Cisco Email Security Gateway.


Note

If you want to skip SDR content filter actions on incoming messages for specific mail policies, you need to select the domain exception list in the Domain Reputation content filter.


Criteria for using Domain Exception List

By default, to skip the SDR check, the domains in the Envelope From:, From:, and Reply-To: headers of the message must be the same and match the domain configured in the domain exception list. If you want to skip the SDR check based on the domain in the Envelope From: header only, select the ‘Match Domain Exception List based on Domain in Envelope From:’ option in the Domain Reputation settings page.

Procedure

Step 1

Go to Security Services > Domain Reputation.

Step 2

Click Edit Settings under Domain Exception List.

Step 3

Select the required address list that contains domains only.

Step 4

Submit and commit your changes.


What to do next

You can also create a Domain Exception List using the domainrepconfig command in the CLI. For more information, see the CLI Reference Guide for AsyncOS for Cisco Email Security Appliances.

Attaching Content Filter to Incoming Mail Policy

You can attach the content filter that you configured to filter messages based on SDR to an incoming mail policy.

Procedure


Step 1

Go to Mail Policies > Incoming Mail Policies.

Step 2

Click the link below Content Filters.

Step 3

Make sure to select 'Enable Content Filters (Customize Settings).'

Step 4

Select the content filter that you created for filtering messages based on SDR.

Step 5

Submit and commit your changes.


Sender Domain Reputation Filtering and Clusters

If you use centralized management, you can enable SDR filtering and mail policies at the cluster, group, and machine level.

Displaying Sender Domain Reputation Details in Message Tracking

You can use Message Tracking to view the message details based on SDR.

Before you begin

  • Make sure that you enable the Message Tracking feature on the email gateway. To enable Message Tracking, go to Security Services > Message Tracking page in the web interface.

  • Content or message filters for filtering messages based on SDR are operational.

Procedure


Step 1

Go to Monitor > Message Tracking.

Step 2

Click Advanced.

Step 3

Check Sender Domain Reputation under Message Event.

Step 4

Select the required SDR verdict(s) to view messages based on the verdict received from the SDR service.

Step 5

(Optional) Check Unscannable to view messages when the SDR check failed.

Step 6

(Optional) Select the required SDR threat categories to view messages based on the threat category.

Step 7

Click Search.


Viewing Alerts

The following table lists the system alert generated for SDR, including a description of the alert and the alert severity.

Component/Alert Name

Message and Description

Parameters

MAIL.IMH.SENDER_DOMAIN_ LOOKUP_FAILURE_ALERTS

The SDR lookup failed. Reason - <$reason>

Warning. Sent when a SDR query fails.

‘reason’ - The reason why the SDR query failed.

Viewing Logs

The SDR filtering information is posted to the Mail Logs. Most information is at the Info or Debug level.

Examples of SDR Filtering Log Entries

The SDR filtering information is posted to the Mail Logs. Most information is at the Info or Debug level.

Sender Domain Reputation Authentication Failure

In this example, the log shows a message that was not filtered based on SDR because of an authentication failure when connecting to the SDR service.

Mon Jul 2 08:57:18 2018 Info: New SMTP ICID 3 interface Management (192.0.2.10) address 224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 08:57:18 2018 Info: ICID 3 ACCEPT SG UNKNOWNLIST match sbrs[none] SBRS not enabled country not enabled
Mon Jul 2 08:57:18 2018 Info: Start MID 3 ICID 3
Mon Jul 2 08:57:18 2018 Info: MID 3 ICID 3 From: <sender1@example.com>
Mon Jul 2 08:57:18 2018 Info: MID 3 ICID 3 RID 0 To: <recipient1@example.com>
Mon Jul 2 08:57:18 2018 Info: MID 3 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>' Mon Jul 2 08:57:18 2018 Info: MID 3 Subject 'Message 001'
Mon Jul 2 08:57:19 2018 Info: MID 3 SDR: Message was not scanned for Sender Domain Reputation. Reason: Authentication failure.
Solution

Use the sdradvancedconfig command in the CLI to configure the required parameters when connecting your email gateway to the SDR service.

Sender Domain Reputation Request Timeout

In this example, the log shows a message that was not filtered based on SDR because of a request timeout error when communicating with the SDR service.

Mon Jul 2 09:00:13 2018 Info: New SMTP ICID 4 interface Management (192.0.2.10) address 224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 09:00:13 2018 Info: ICID 4 ACCEPT SG UNKNOWNLIST match sbrs[none] SBRS not enabled country not enabled
Mon Jul 2 09:00:13 2018 Info: Start MID 4 ICID 4
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 From: <sender1@example.com>
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 RID 0 To: <recipient1@example.com >
Mon Jul 2 09:00:13 2018 Info: MID 4 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>'
Mon Jul 2 09:00:13 2018 Info: MID 4 Subject 'Message 001'
Mon Jul 2 09:00:13 2018 Info: MID 4 SDR: Message was not scanned for Sender Domain Reputation. Reason: Request timed out.
Solution

When an SDR request times out, the message is marked as unscannable, and the configured actions are applied to the message.

Sender Domain Reputation Invalid Host

In this example, the log shows a message that was not filtered based on SDR because an invalid SDR service host was configured on your email gateway.

Mon Jul 2 09:04:08 2018 Info: ICID 7 ACCEPT SG UNKNOWNLIST match sbrs[none] SBRS not enabled country not enabled
Mon Jul 2 09:04:08 2018 Info: Start MID 7 ICID 7
Mon Jul 2 09:04:08 2018 Info: MID 7 ICID 7 From: <sender1@example.com >
Mon Jul 2 09:04:08 2018 Info: MID 7 ICID 7 RID 0 To: <recipient1@example.com >
Mon Jul 2 09:04:08 2018 Info: MID 7 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>' Mon Jul 2 09:04:08 2018 Info: MID 7 Subject 'Message 001'
Mon Jul 2 09:04:08 2018 Info: MID 7 SDR: Message was not scanned for Sender Domain Reputation. Reason: Invalid host configured.
Solution

Use the sdradvancedconfig command in the CLI to configure the required parameters when connecting your email gateway to the SDR service.

Sender Domain Reputation General Errors

In this example, the log shows a message that was not filtered based on SDR because of an unknown error.

Mon Jul 2 09:00:13 2018 Info: New SMTP ICID 4 interface Management (192.0.2.10) address 224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 09:00:13 2018 Info: ICID 4 ACCEPT SG UNKNOWNLIST match sbrs[none] SBRS not enabled country not enabled
Mon Jul 2 09:00:13 2018 Info: Start MID 4 ICID 4
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 From: <sender1@example.com >
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 RID 0 To: <recipient1@example.com >
Mon Jul 2 09:00:13 2018 Info: MID 4 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>'
Mon Jul 2 09:00:13 2018 Info: MID 4 Subject 'Test mail'
Mon Jul 2 09:00:13 2018 Info: MID 4 SDR: Message was not scanned for Sender Domain Reputation. Reason: Unknown error.
Solution

When an unknown error occurs, the message is marked as unscannable, and the configured actions are applied to the message.