This document describes the Sender Domain Reputation (SDR) configuration for the Email Security Appliance (ESA).
Cisco recommends that you have knowledge of these topics:
The information in this document is based on AsyncOS for ESA 12.0 and later.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
1. SDR has been developed as an additional resource in order to improve spam detection.
2. SDR captures multiple header values, uploads them to Talos Threat Intelligence Servers where additional detail gets combined to determine a verdict for each message on a graduated scale based on a formula derived by Talos.acron
3. The header values included in the decision are:
dmarc, dkim and spf verification (if configured)
From (name portion) is optionally submitted from the 'From' and 'Reply-To' headers
Display name in the 'From' and 'Reply-To' headers
5. SDR Scan gets performed on all inbound messages.
6. SDR scan takes place just after the Simple Mail Transfer Protocol (SMTP) acceptance of a message.
7. No action will be taken without the implementation of a Message Filter or Content Filter.
8. SDR action would take place in a configured Message Filter or Content Filter.
9. Configured components include:
Enable Domain Reputation Service
Domain Exception Lists (optional)
Domain Exception List (Global)
Domain Exception List (Message/Content Filter specific)
Message Filter or Content Filter
Enable Domain Reputation Service WebUI
SDR can be enabled from either the WebUI or the CLI interfaces.
1. Navigate to Mail Security Services > Domain Reputation > Enable.
2. Click the box next to Enable Sender Domain Reputation Filtering.
3. Select this box Include Additional Attributes: (Optional) if you would like to include the optional header value to the checked data for improved efficacy. Click ? to learn.
The Domain Exception List application within message filters would be included as an option within a condition. Note that these samples include the domain_exception_list as a portion of the whole condition.
A more comprehensive explanation and samples of Message filter application can be found with the ESA User Guides under the headings:
Domain Reputation Rule for ETF
Filtering Messages based on Sender Domain Reputation using Message Filter
Create a Content Filter to Take Action on the SDR Verdict
SDR is only enabled for Incoming Mail Flow.
The SDR Condition Name: Domain Reputation.
Multiple Conditions can be created to combine different results.
The Domain Reputation Condition contains 2 different checks that contain multiple options for each:
Sender Domain Reputation
Sender Domain Reputation Verdict
Sender Domain Age
Sender Domain Reputation Unscannable
External Threat Feeds
Allows the utilization of the Threat Feeds downloaded content lists to scan against the same domain headers collected for SDR.
Note: These options within the Domain Reputation Condition will visually change based on the different options for each selection.
5. The final option within the Domain Reputation Condition is the Domain Exception List.
6. The Domain Exception List function associated with an Address List adds more control to the application of the action by applying the list to the more detailed Mail Policy Level of message processing.
7. Navigate to Mail Policy > Incoming Content Filters > Add Filter > Add Condition > Domain Reputation.
8. Condition 1: Sender Domain Reputation Verdict.
Awful, Poor, Tainted, Weak, Unknown, Neutral, Good
Contains sliding triangular markers to choose the range you would like to match.
The Awful and Poor are the recommended values to take action.
The messages which match Awful and Poor will have an additional Category, value such as Spam or Malicious viewable within Message Tracking.
Full view of the SDR Verdict Slide Bar.SDR Verdict adjustable range slide bar.
9. Condition 2: Sender Domain Age.
The age of the Domain can be associated with more risk or long-established reliability.
The possibility of a domain with an age of fewer than 10 days may be riskier.
Sender Domain Age. Lower values suggest more risk.
This section provides information you can use to troubleshoot your configuration.
No SDR: logs present within the mail_logs or Message Tracking:
SDR logs will always be present for messages which pass through an ACCEPT Mail Flow Policy.
Ensure the Service has been enabled as presented in the initial steps of this guide.
2. SDR Timed Out:
Verify the Cisco cloud server for SDR is open and available for use.
A very general test can be performed with the use of the telnet from the CLI.
If the banner appears, it will confirm the basic reachability.
CLI > telnet v2.sds.cisco.com 443 (this will verify a point in time only.)
Check logs from other services to determine if there are potential communication failures out to internet-based services.
CLI > displayalerts in order to check for additional signs of communication failures.
Prior to 13.5 AsyncOS, SDR and URL Filtering both utilize v2.sds.cisco.com.
A check of the URL Filtering CLI command > websecuritydiagnostics might provide some validation if the network path contains latency.
Check the Sender Domain Reputation Timeout Setting, and determine if the value should be increased 1-10 seconds. Navigate to Security Services > Domain Reputation > Edit > Sender Domain Reputation Query Timeout:2
The default is 2 seconds and a maximum setting of 10 seconds.