- Getting Started with the Cisco Email Security Appliance
- Accessing the Appliance
- Setup and Installation
- Understanding the Email Pipeline
- Configuring the Gateway to Receive Email
- Sender Reputation Filtering
- Defining Which Hosts Are Allowed to Connect Using the Host Access Table
- Accepting or Rejecting Connections Based on Domain Name or Recipient Address
- Using Message Filters to Enforce Email Policies
- Mail Policies
- Content Filters
- Anti-Virus
- Anti-Spam
- Managing Graymail
- Outbreak Filters
- Protecting Against Malicious or Undesirable URLs
- File Reputation Filtering and File Analysis
- Data Loss Prevention
- Cisco Email Encryption
- S/MIME Security Services
- Automatically Remediating Messages in Office 365 Mailboxes
- Email Authentication
- Text Resources
- Validating Recipients Using an SMTP Server
- Encrypting Communication with Other MTAs
- Configuring Routing and Delivery Features
- LDAP Queries
- Authenticating SMTP Sessions Using Client Certificates
- Using Email Security Monitor
- Tracking Messages
- Centralized Policy, Virus, and Outbreak Quarantines
- Spam Quarantine
- Distributing Administrative Tasks
- System Administration
- Managing and Monitoring Using the CLI
- SenderBase Network Participation
- Other Tasks in the GUI
- Advanced Network Configuration
- Logging
- Centralized Management Using Clusters
- Testing and Troubleshooting
- Optimizing the Appliance for Outbound Mail Delivery Using D-Mode
- Centralizing Services on a Cisco Content (M-Series) Security Management Appliance
- FTP, SSH, and SCP Access
- Assigning Network and IP Addresses
- Example of Mail Policies and Content Filters
- Firewall Information
- End User License Agreement
- Index
User Guide for AsyncOS 11.0 for Cisco Email Security Appliances
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- March 25, 2021
Chapter: Anti-Spam
- Overview of Anti-Spam Scanning
- How to Configure the Appliance to Scan Messages for Spam
- IronPort Anti-Spam Filtering
- Cisco Intelligent Multi-Scan Filtering
- Defining Anti-Spam Policies
- Understanding Positive and Suspect Spam Thresholds
- Configuration Examples: Actions for Positively Identified versus Suspected Spam
- Unwanted Marketing Messages From Legitimate Sources
- Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy: Configuration Example
- Enabling Different Anti-Spam Scanning Engines in Different Mail Policies: Configuration Example
- Protecting Appliance-Generated Messages From the Spam Filter
- Headers Added During Anti-Spam Scanning
- Reporting Incorrectly Classified Messages to Cisco
- Determining Sender IP Address In Deployments with Incoming Relays
- How Incoming Relays Affect Functionality
Anti-Spam
This chapter contains the following sections:
- Overview of Anti-Spam Scanning
- How to Configure the Appliance to Scan Messages for Spam
- IronPort Anti-Spam Filtering
- Cisco Intelligent Multi-Scan Filtering
- Defining Anti-Spam Policies
- Protecting Appliance-Generated Messages From the Spam Filter
- Headers Added During Anti-Spam Scanning
- Reporting Incorrectly Classified Messages to Cisco
- Determining Sender IP Address In Deployments with Incoming Relays
- Monitoring Rules Updates
- Testing Anti-Spam
Overview of Anti-Spam Scanning
Anti-spam processes scan email for incoming (and outgoing) mail based on the mail policies that you configure.
- One or more scanning engines scan messages through their filtering modules.
- Scanning engines assign a score to each message. The higher the score, the greater the likelihood that the message is spam.
- Based on the score, each message is categorized as one of the following:
- An action is taken based on the result.
Actions taken on messages positively identified as spam, suspected to be spam, or identified as unwanted marketing messages are not mutually exclusive; you can combine some or all of them differently within different incoming or outgoing policies for different processing needs for groups of users. You can also treat positively identified spam differently from suspected spam in the same policy. For example, you may want to drop messages positively identified as spam, but quarantine suspected spam messages.
For each mail policy, you can specify thresholds for some of the categories, and determine the action to take for each category. You can assign different users to different mail policies and define different scanning engines, spam-definition thresholds, and spam-handling actions for each policy.
 Note | For information about how and when anti-spam scanning is applied, see Email Pipeline and Security Services. |
Anti-Spam Solutions
Your Cisco appliance offers the following anti-spam solutions:
You can license and enable both these solutions on your Cisco appliance, but you can only use one in a particular mail policy. You can specify a different anti-spam solution for different groups of users.
How to Configure the Appliance to Scan Messages for Spam
| Command or Action | Purpose | |||
|---|---|---|---|---|
| Step 1 | Enable anti-spam scanning on the Email Security appliance. |
If you have feature keys for both Cisco IronPort Anti-Spam and Intelligent Multi-Scan, you can enable both solutions on the appliance. | ||
| Step 2 | Configure whether to quarantine spam on the local Email Security appliance or use an external quarantine on a Security Management appliance. | |||
| Step 3 | Define the groups of users whose messages you want to scan for spam. |
Creating a Mail Policy for a Group of Senders and Recipients | ||
| Step 4 | Configure the anti-spam scanning rules for the user groups you defined. | |||
| Step 5 | If you want certain messages to skip Cisco Anti-Spam scanning, create message filters that use the skip-spamcheck action. | |||
| Step 6 | (Recommended) Enable SenderBase Reputation Service scoring for each inbound mail flow policy, even if you are not rejecting connections based on SenderBase Reputation Scores. |
For each inbound mail flow policy, ensure that “Use SenderBase for Flow Control” is On. See Defining Rules for Incoming Messages Using a Mail Flow Policy. | ||
| Step 7 | If your Email Security appliance does not connect directly to external senders to receive incoming mail, but instead receives messages relayed through a mail exchange, mail transfer agent, or other machine on your network, ensure that relayed incoming messages include the original sender IP address. |
Determining Sender IP Address In Deployments with Incoming Relays | ||
| Step 8 | Prevent alert and other messages generated by your appliance from being incorrectly identified as spam. |
Protecting Appliance-Generated Messages From the Spam Filter | ||
| Step 9 | (Optional) Enable URL filtering to strengthen protection against malicious URLs in messages. | |||
| Step 10 | Test your configuration. | |||
| Step 11 | (Optional) Configure settings for service updates (including anti-spam rules.) |
Scanning rules for both anti-spam solutions are retrieved by default from the Cisco update servers. |
IronPort Anti-Spam Filtering
Evaluation Key
Your Cisco appliance ships with a 30-day evaluation key for the Cisco Anti-Spam software. This key is not enabled until you accept the license agreement in the system setup wizard or Security Services > IronPort Anti-Spam pages (in the GUI) or the systemsetup or antispamconfig commands (in the CLI). Once you have accepted the agreement, Cisco Anti-Spam will be enabled, by default, for the default incoming Mail Policy. An alert is also sent to the administrator address you configured (see the System Setup Wizard, Step 2: System) noting that the Cisco Anti-Spam license will expire in 30 days. Alerts are sent 30, 15, 5, and 0 days prior to expiration. For information on enabling the feature beyond the 30-day evaluation period, contact your Cisco sales representative. You can see how much time remains on the evaluation via the System Administration > Feature Keys page or by issuing the featurekey command. (For more information, see Feature Keys.)
Cisco Anti-Spam: an Overview
IronPort Anti-Spam addresses a full range of known threats including spam, phishing and zombie attacks, as well as hard-to-detect low volume, short-lived email threats such as “419” scams. In addition, IronPort Anti-Spam identifies new and evolving blended threats such as spam attacks distributing malicious content through a download URL or an executable.
To identify these threats, IronPort Anti-Spam examines the full context of a message-its content, methods of message construction, the reputation of the sender, the reputation of web sites advertised in the message, and more. IronPort Anti-Spam combines the power of email and web reputation data, leveraging the full power of the world's largest email and web traffic monitoring network — SenderBase — to detect new attacks as soon as they begin.
IronPort Anti-Spam analyzes over 100,000 message attributes across the following dimensions:
- Email reputation — who is sending you this message?
- Message content — what content is included in this message?
- Message structure — how was this message constructed?
- Web reputation — where does the call to action take you?
Analyzing multi-dimensional relationships allows the system to catch a broad range of threats while maintaining accuracy. For example, a message that has content claiming to be from a legitimate financial institution but that is sent from an IP address on a consumer broadband network or that contains a URL hosted on a “zombie” PC will be viewed as suspicious. In contrast, a message coming from a pharmaceutical company with a positive reputation will not be tagged as spam even if the message contains words closely correlated with spam.
Spam Scanning for International Regions
Cisco Anti-Spam is effective world-wide and uses locale-specific content-aware threat detection techniques. You can also optimize anti-spam scanning for a specific region using a regional rules profile.
-
If you receive a large quantity of spam from a particular region outside of the US, you may want to use a regional rules profile to help you stop spam from that region.
For example, China and Taiwan receive a high percentage of spam in traditional or modern Chinese. The Chinese regional rules are optimized for this type of spam. If you receive mail primarily for mainland China, Taiwan, and Hong Kong, Cisco strongly recommends you use the Chinese regional rules profile included with the anti-spam engine.
- If your spam comes primarily from the US or from no one particular region, do not enable regional rules because doing so may reduce capture rates for other types of spam. This is because the regional rules profile optimizes the anti-spam engine for a particular region.
You can enable the regional rules profile when you configure IronPort Anti-Spam Scanning.
Configuring IronPort Anti-Spam Scanning
Note | When IronPort Anti-Spam is enabled during system setup, it is enabled for the default incoming mail policy with the default values for the global settings. |
Before You Begin
- Determine whether you will use regional scanning. See Spam Scanning for International Regions.
Cisco Intelligent Multi-Scan Filtering
Cisco Intelligent Multi-Scan incorporates multiple anti-spam scanning engines, including Cisco Anti-Spam, to provide a multi-layer anti-spam solution.
When processed by Cisco Intelligent Multi-Scan:
- A message is first scanned by third-party anti-spam engines.
- Cisco Intelligent Multi-Scan then passes the message and the verdicts of the third-party engines to Cisco Anti-Spam, which assumes responsibility for the final verdict.
- After Cisco Anti-Spam performs its scan, it returns a combined multi-scan score to AsyncOS.
- Combining the benefits of the third-party scanning engines and Cisco Anti-Spam results in more caught spam while maintaining Cisco Anti-Spam’s low false positive rate.
You cannot configure the order of the scanning engines used in Cisco Intelligent Multi-Scan; Cisco Anti-Spam will always be the last to scan a message and Cisco Intelligent Multi-Scan will not skip it if a third-party engine determines that a message is spam.
Using Cisco Intelligent Multi-Scan can lead to reduced system throughput. Please contact your Cisco support representative for more information.
Note | The Intelligent Multi-Scan feature key also enables Cisco Anti-Spam on the appliance, giving you the option of enabling either Cisco Intelligent MultiScan or Cisco Anti-Spam for a mail policy. |
Configuring Cisco Intelligent Multi-Scan
Note | When Cisco Intelligent Multi-Scan is enabled during system setup, it is enabled for the default incoming mail policy with the default values for the global settings. |
Before You Begin
Activate the feature key for this feature. See Feature Keys. You will see the IronPort Intelligent Multi-Scan option only if you have done so.
| Step 1 | Select Security Services > IronPort Intelligent Multi-Scan. |
| Step 2 | If you have not enabled Cisco Intelligent Multi-Scan in the system setup wizard: |
| Step 3 | Click Edit Global Settings. |
| Step 4 | Select the
check box for
Enable
IronPort Intelligent Multi-Scan.
Checking this box enables the feature globally for the appliance. However, you must still enable per-recipient settings in Mail Policies. |
| Step 5 | Select the
thresholds for scanning with Cisco Intelligent Multi-Scan.
The default values are: |
| Step 6 | Enter the
number of seconds to wait for timeout when scanning a message.
When specifying the number of seconds, enter an integer from 1 to 120. The default value is 60 seconds. Most users will not need to change the maximum message size to be scanned or the timeout value. That said, you may be able to optimize the throughput of your appliance by lowering the maximum message size setting. |
| Step 7 | Submit and commit your changes. |
Defining Anti-Spam Policies
For each mail policy, you specify settings that determine which messages are considered spam and what action to take on those messages. You also specify which engine will scan messages that the policy applies to.
You can configure different settings for the default incoming and outgoing mail policies. If you need different anti-spam policies for different users, use multiple mail policies with different anti-spam settings. You can enable only one anti-spam solution per policy; you cannot enable both on the same policy.
Before You Begin
- Complete all steps to this point in the table in How to Configure the Appliance to Scan Messages for Spam.
- Familiarize yourself with
the following:
- Understanding Positive and Suspect Spam Thresholds
- Configuration Examples: Actions for Positively Identified versus Suspected Spam
- Unwanted Marketing Messages From Legitimate Sources
- If you have enabled more than one anti-spam solution: Enabling Different Anti-Spam Scanning Engines in Different Mail Policies: Configuration Example
- Headers Added During Anti-Spam Scanning
- If you will archive spam into the “Anti-Spam Archive” log, see also Logging.
- If you will send messages to an alternate mailhost, see also Alter Delivery Host Action.
| Step 1 | Navigate to the
Mail
Policies > Incoming Mail Policies page.
Or | ||||||||||||||||||||||
| Step 2 | Navigate to the Mail Policies > Outgoing Mail Policies page. | ||||||||||||||||||||||
| Step 3 | Click the link under the Anti-Spam column for any mail policy. | ||||||||||||||||||||||
| Step 4 | In the
Enable
Anti-Spam Scanning for This Policy section, select the anti-spam
solution you want to use for the policy.
Options you see depend on the anti-spam scanning solution(s) that you have enabled. For mail policies other than the default: If you use settings from the default policy, all other options on the page are disabled. You can also disable anti-spam scanning altogether for this mail policy. | ||||||||||||||||||||||
| Step 5 | Configure
settings for positively identified spam, suspected spam, and marketing
messages:
| ||||||||||||||||||||||
| Step 6 | Submit and commit your changes. | ||||||||||||||||||||||
What to Do Next
If you enabled anti-spam scanning for outgoing mail, check the anti-spam settings of the relevant host access table, especially for a private listener. See Defining Access Rules for Email Senders Using Mail Flow Policies.
Understanding Positive and Suspect Spam Thresholds
When evaluating messages for spam, both anti-spam scanning solutions apply thousands of rules in order to arrive at an overall spam score for the message. The score is then compared to the thresholds specified in the applicable mail policy to determine whether the message is considered spam.
For highest accuracy, the threshold for positive identification as spam is quite high by default: Messages scoring between 90 and 100 are considered to be positively identified as spam. The default threshold for suspected spam is 50.
- Messages with scores below the suspected spam threshold will be considered legitimate.
- Messages above the suspected threshold but below the positive-identification threshold will be considered to be suspected spam.
You can configure your anti-spam solution to reflect the spam tolerance levels of your organization by customizing the Positive and Suspected spam thresholds in each mail policy.
You can change the positively identified spam threshold to a value between 50 and 99. You can change the threshold for suspected spam to any value between 25 and the value you specified for positively-identified spam.
When you change the thresholds:
- Specifying a lower number (a more aggressive configuration) identifies more messages as spam and may produce more false positives. This provides a lower risk that users will see spam but a higher risk of having legitimate mail marked as spam.
- Specifying a higher number (a more conservative configuration) identifies fewer messages as spam and may deliver more spam. This provides a higher risk of users seeing spam but less risk that legitimate mail will be withheld as spam. Ideally, if set up correctly, the message subject will identify the message as likely spam and message will be delivered.
You can define separate actions to take on positively-identified and suspected spam. For example, you may want to drop “positively identified” spam but quarantine “suspected” spam.
Configuration Examples: Actions for Positively Identified versus Suspected Spam
|
Spam |
Sample Actions (Aggressive) |
Sample Actions (Conservative) |
|---|---|---|
|
Positively Identified |
Drop |
|
|
Suspected |
Deliver with “ [Suspected Spam] ” added to the subject of messages |
Deliver with “ [Suspected Spam] ” added to the subject of messages |
The aggressive example tags only suspected spam messages, while dropping those messages that are positively identified. Administrators and end-users can check the subject line of incoming message for false positives, and an administrator can adjust, if necessary, the suspected spam threshold.
In the conservative example, positively identified and suspected spam is delivered with an altered subject. Users can delete suspected and positively identified spam. This method is more conservative than the first.
For a further discussion of aggressive and conservative policies in mail policies, see Managed Exceptions.
Unwanted Marketing Messages From Legitimate Sources
If you had configured Marketing Email Settings under anti-spam settings for a mail policy, after upgrading to AsyncOS 9.5 for Email, Marketing Email Settings under anti-spam settings will be moved under graymail settings of the same policy. See Managing Graymail.
Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy: Configuration Example
You can rewrite URLs in suspected spam so that when a recipient clicks a link in the message, the request is routed through the Cisco Web Security proxy service, which evaluates the safety of the site at click time and blocks access to known malicious sites.
Before You Begin
Enable the URL Filtering feature and its prerequisites. See Setting Up URL Filtering.
| Step 1 | Apply a custom
header to suspected spam messages:
|
| Step 2 | Create a
content filter to redirect URLs in messages that have the custom header:
|
| Step 3 | Add the content
filter to the mail policy.
|
Enabling Different Anti-Spam Scanning Engines in Different Mail Policies: Configuration Example
When using the System Setup Wizard (or systemsetup command in the CLI), you are presented with option to enable either Cisco Intelligent Multi-Scan or the Cisco Anti-Spam engine. You cannot enable both during system setup, but after system setup is complete you can enable the anti-spam solution that you didn’t choose, by using the Security Services menu.
After the system is set up, you can configure the anti-spam scanning solution for incoming mail policies via the Mail Policies > Incoming Mail Policies page. (Anti-spam scanning is typically disabled for outgoing mail policies.) You can even disable anti-spam scanning for a policy.
In this example, the default mail policy and the “Partners” policy are using the Cisco Anti-Spam scanning engine to quarantine positive and suspected spam.
To change the Partners policy to use Cisco Intelligent Multi-Scan and scan for unwanted marketing messages, click on the entry in the Anti-Spam column corresponding with the Partners row (“use default”).
Select Cisco Intelligent Multi-Scan for the scanning engine, and select Yes to enable unwanted marketing message detection. Use the default settings for unwanted marketing message detection.
The following figure shows Cisco Intelligent Multi-Scan and unwanted marketing message detection enabled in a policy.
After submitting and committing the changes, the mail policy looks like this:
Protecting Appliance-Generated Messages From the Spam Filter
Because automated email messages that are sent from the Cisco IronPort appliance (such as email alerts and scheduled reports) may contain URLs or other information that may cause them to be incorrectly identified as spam, you should do the following to ensure their delivery:
Include senders of these messages in an incoming mail policy that bypasses anti-spam scanning. See Creating a Mail Policy for a Group of Senders and Recipientsand Bypass Anti-Spam System Action.
Headers Added During Anti-Spam Scanning
-
If either anti-spam scanning engine is enabled for a mail policy, each message that passes through that policy will have the following headers added to the message:
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result
The second header contains information that allows Cisco Support to identify the rules and engine version used to scan the message. Result information is encoded proprietary information and is not customer-decodable.
- Cisco Intelligent Multi-Scan also adds headers from the third-party anti-spam scanning engines.
- You can define additional custom headers to be added to all messages for a given mail policy that are positively identified as spam, suspected to be spam, or identified as unwanted marketing mail. See Defining Anti-Spam Policies.
Reporting Incorrectly Classified Messages to Cisco
Messages that appear to be incorrectly classified may be reported to Cisco for analysis. The reported messages are used to enhance the accuracy and effectiveness of the product.
You can report incorrectly classified messages that belong to the following categories:
- How to Report Incorrectly Classified Messages to Cisco
- How to Report Incorrectly Classified Messages to Cisco
- How to Track Your Submissions
How to Report Incorrectly Classified Messages to Cisco
Before You Begin
Before you start reporting incorrectly classified messages to Cisco, you must perform the following steps. Perform this step only once.
| Step 1 | Set a common
registration ID for all the appliances in your organization. A Registration ID
is a unique identifier to identify submissions made from the Cisco Email
Security Gateways that belong to a particular organization.
You can also use the portalregistrationconfig command in CLI to set the registration ID. | ||
| Step 2 | Register as an
administrator on Cisco Email Submission and Tracking Portal. Cisco Email
Submission and Tracking Portal is a web-based tool that allows email
administrators to report incorrectly classified messages to Cisco and track
them.
| ||
| Step 3 | Register your
domain with Cisco Email Submission and Tracking Portal.
A request to add your domain is sent to postmaster@domain.com , where domain.com is the domain you entered in this step. An administrator from this domain must review and approve your request. If your organization is not using postmaster@domain.com or your administrator does not have access to the postmaster mailbox, create a message filter (on all your appliances) to redirect messages from SubmissionPortal@cisco.com sent to postmaster@domain.com to a different email address. The following is a sample message filter: redirect_postmaster: if (rcpt-to == "postmaster@domain.com") AND (mail-from == "^SubmissionPortal@cisco.com$") { alt-rcpt-to ("admin@domain.com"); } |
How to Report Incorrectly Classified Messages to Cisco
For more information, see https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/200648-ESA-FAQ-How-to-work-with-Cisco-Email-Su.html.
| Step 1 | Perform the steps mentioned in Before You Begin section of How to Report Incorrectly Classified Messages to Cisco. |
| Step 2 | Report
incorrectly classified messages to Cisco using one of the following methods:
After you report an incorrectly classified message to Cisco, you will receive an email notification within two hours. The following is a sample email notification:  If you did not receive an email notification within two hours, your submission may have failed. For troubleshooting instructions, on the portal, click Help > Troubleshooting Instructions. |
Using Cisco Email Security Plug-In
Cisco Email Security Plug-In is a tool that allows users (email administrators and end users) to report incorrectly classified messages to Cisco using Microsoft Outlook. When you deploy this plug-in as part of Microsoft Outlook, a reporting menu is added to the Microsoft Outlook web interface. You can use the plug-in menu to report incorrectly classified messages.
Additional Information
- You can download Cisco Email Security Plug-In from the following page: https://software.cisco.com/portal/pub/download/portal/select.html?&mdfid=284900944&flowid=41782&softwareid=283090986.
- For more information, see the Cisco Email Security Plug-In Administrator Guide http://www.cisco.com/c/en/us/support/security/email-encryption/products-user-guide-list.html.
Using Cisco Email Submission and Tracking Portal
Cisco Email Submission and Tracking Portal is a web-based tool that allows email administrators to report incorrectly classified messages to Cisco. Administrators can also track the submissions from their organization using the portal.
Note | Currently, you can report only incorrectly classified spam messages using the portal. |
| Step 1 | Log in to Cisco SecurityHub ( https://securityhub.cisco.com/) using your Cisco credentials. |
| Step 2 | Click Email Submission and Tracking. |
| Step 3 | On Email Submission and Tracking Portal, under Submissions tab, click New Submission. |
| Step 4 | Select the incorrectly classified messages. These messages must be in EML format and the total size of the messages must not exceed 15 MB. |
| Step 5 | Click Create. |
What to Do Next
Additional Information
For more information about Cisco Email Submission and Tracking Portal, see the following documents:
|
How To |
See |
|---|---|
|
Report incorrectly classified messages to Cisco using Email Submission and Tracking Portal |
|
|
Work with Cisco Email Submission and Tracking Portal |
|
|
Troubleshoot Cisco Email Submission and Tracking Portal |
Forwarding Incorrectly Classified Message as an Attachment
Depending on the category of the message, you can forward each incorrectly classified message as an RFC 822 attachment to the following addresses:
- Missed spam - spam@access.ironport.com
- Message marked as a spam, but is not a spam - ham@access.ironport.com
- Missed marketing message - ads@access.ironport.com
- Message marked as a marketing message, but is not a marketing message - not_ads@access.ironport.com
- Missed phishing message - phish@access.ironport.com
You can achieve best results if you use one of the following email programs to forward the message:
 Caution | If you are using Microsoft Outlook 2010, 2013, or 2016 for Microsoft Windows, you must use the Cisco Email Security Plug-In or the Microsoft Outlook Web App to report incorrectly classified messages. This is because Outlook for Windows may not forward the message with the required headers intact. Also, use the mobile platforms only if you can forward the original message as an attachment. |
How to Track Your Submissions
After your receive an email notification with the submission details, you can view and track your submission on Cisco Email Submission and Tracking Portal.
| Step 1 | Log in to Cisco SecurityHub ( https://securityhub.cisco.com/) ) using your Cisco credentials. |
| Step 2 | Click Email Submission and Tracking. |
| Step 3 | On Email Submission and Tracking Portal, click Submissions. |
| Step 4 | Use the filters (Time Duration, Submission ID, Subject, Submitter, and Status) to find your submission. |
What to Do Next
For more information, see https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/200648-ESA-FAQ-How-to-work-with-Cisco-Email-Su.html. .
Determining Sender IP Address In Deployments with Incoming Relays
If one or more mail exchange/transfer agents (MX or MTA), filtering servers, etc. stand at the edge of your network, between your Cisco appliance and the external machines that are sending incoming mail, then your appliance cannot determine the IP addresses of the sending machines. Instead, mail appears to originate from the local MX/MTA. However, IronPort Anti-Spam and Cisco Intelligent Multi-Scan (using the SenderBase Reputation Service) depend on accurate IP addresses for external senders.
The solution is to configure your appliance to work with incoming relays. You specify the names and IP addresses of all of the internal MX/MTAs connecting to the Cisco appliance, as well as the header used to store the originating IP address.
- Example Environments with Incoming Relays
- Configuring the Appliance to Work with Incoming Relays
- How Incoming Relays Affect Functionality
- Configuring Logs to Specify Which Headers Are Used
Example Environments with Incoming Relays
The following figure shows a very basic example of an incoming relay. Mail from IP address 7.8.9.1 appears to come from IP address 10.2.3.4 because the local MX/MTA is relaying mail to the Cisco appliance.
The following figure shows two other, slightly more complicated examples of how mail may be relayed inside the network and how mail may be processed by several servers within the network before it is passed to the Cisco appliance. In example A, mail from 7.8.9.1 passes through the firewall and is processed by an MX and an MTA before being delivered to the Cisco appliance. In example B, mail from 7.8.9.1 is sent to a load balancer or other type of traffic shaping appliance and is sent to any one of a range of MXs prior to being delivered to the Cisco appliance.
Configuring the Appliance to Work with Incoming Relays
Enabling the Incoming Relays Feature
Note | You should only enable the incoming relays feature if a local MX/MTA relays mail to your Cisco appliance. |
Adding an Incoming Relay
Add incoming relays to identify:
- Each machine on your network that will relay incoming messages to your Email Security appliance, and
- The header that will label the IP address of the original external sender.
Before You Begin
For information needed to complete these prerequisites, see Message Headers for Relayed Messages.
| Step 1 | Select Network > Incoming Relays. |
| Step 2 | Click Add Relay. |
| Step 3 | Enter a name for this relay. |
| Step 4 | Enter the IP
address of the MTA, MX, or other machine that connects to the Email Security
appliance to relay incoming messages.
You can use IPv4 or IPv6 addresses, standard CIDR format, or an IP address range. For example, if you have several MTAs at the edge of your network receiving email, you might want to enter a range of IP addresses to include all of your MTAs, such as 10.2.3.1/8 or 10.2.3.1-10. For IPv6 addresses, AsyncOS supports the following formats: |
| Step 5 | Specify the
header that will identify the IP address of the original external sender.
When entering a header, you do not need to enter the trailing colon. |
| Step 6 | Submit and commit your changes. |
What to Do Next
Consider doing the following:
- Add the relaying machine to a sender group with a mail flow policy that has unlimited messages for DHAP. For an explanation, see Incoming Relays and Directory Harvest Attack Prevention.
- To facilitate tracking and troubleshooting, configure the appliance logs to show which header is used. See Configuring Logs to Specify Which Headers Are Used.
Message Headers for Relayed Messages
You will configure your appliance to use one of the following types of header to identify the original sender of a relayed message:
Custom Header
Using custom headers is the recommended method of identifying original senders. The machine connecting to the original sender needs to add this custom header. The value of the header is expected to be the IP address of the external sending machine. For example:
SenderIP: 7.8.9.1
X-CustomHeader: 7.8.9.1
If your local MX/MTA can receive mail from a variable number of hops, inserting a custom header is the only way to enable the Incoming Relays feature. For example, in the following figure, both path C and D lead to IP address 10.2.3.5; however, path C has two hops and path D has one. Because the number of hops can vary in this situation, you must use a custom header in order to have Incoming Relays configured correctly.
Received Header
If configuring the MX/MTAs to include a custom header containing the sending IP address is not an option, you can configure the incoming relays feature to attempt to determine the sending IP address by examining the “Received:” headers in the message. Using the “Received:” header will only work if the number of network “hops” will always be constant for an IP address. In other words, the machine at the first hop (10.2.3.5 in Figure - Mail Relayed by MX/MTA — Advanced) should always be the same number of hops away from the edge of your network. If incoming mail can take different paths (resulting in a different number of hops, as described in Figure - Mail Relayed by MX/MTA — Variable Number of Hops) to the machine connecting to your Cisco appliance, you must use a custom header (see Custom Header).
Specify a parsing character or string and the number of network hops (or Received: headers) back to look. A hop is basically the message traveling from one machine to another (being received by the Cisco appliance does not count as a hop. See Configuring Logs to Specify Which Headers Are Usedfor more information). AsyncOS looks for the first IP address following the first occurrence of the parsing character or string in the Received: header corresponding to the number of specified hops. For example, if you specify two hops, the second Received: header, working backward from the Cisco appliance is parsed. If neither the parsing character nor a valid IP address is found, the Cisco appliance uses the real IP address of the connecting machine.
For the following example mail headers, if you specify an opening square bracket ( [ ) and two hops, the IP address of the external machine is 7.8.9.1. However, if you specify an closing parenthesis ( ) ) as the parsing character, a valid IP address will not be found. In this case, the Incoming Relays feature is treated as disabled, and the IP of the connecting machine is used (10.2.3.5).
In the example in Figure - Mail Relayed by MX/MTA — Advanced the incoming relays are:
- Path A — 10.2.3.5 (with 2 hops when using received headers) and
- Path B — 10.2.6.1 (with 2 hops when using received headers)
The following table shows example email headers for a message as it moves through several hops on its way to the Cisco appliance as in Figure - Mail Relayed by MX/MTA — Advanced. This example shows extraneous headers (ignored by your Cisco appliance) which are present once the message has arrived in the recipient’s inbox. The number of hops to specify would be two.
|
1 |
Microsoft Mail Internet Headers Version 2.0 Received: from smemail.rand.org ([10.2.2.7]) by smmail5.customerdoamin.org with Microsoft SMTPSVC(5.0.2195.6713); Received: from ironport.customerdomain.org ([10.2.3.6]) by smemail.customerdoamin.org with Microsoft SMTPSVC(5.0.2195.6713); |
|
2 |
Received: from mta.customerdomain.org ([10.2.3.5]) by ironport.customerdomain.org with ESMTP; 21 Sep 2005 13:46:07 -0700 |
|
3 |
Received: from mx.customerdomain.org (mx.customerdomain.org) [10.2.3.4]) by mta.customerdomain.org (8.12.11/8.12.11) with ESMTP id j8LKkWu1008155 for <joefoo@customerdomain.org> |
|
4 |
Received: from sending-machine.spamham.com (sending-machine.spamham.com [7.8.9.1]) by mx.customerdomain.org (Postfix) with ESMTP id 4F3DA15AC22 for <joefoo@customerdomain.org> |
|
5 |
Received: from linux1.thespammer.com (HELO linux1.thespammer.com) ([10.1.1.89]) by sending-machine.spamham.com with ESMTP; Received: from exchange1.thespammer.com ([10.1.1.111]) by linux1.thespammer.com with Microsoft SMTPSVC(6.0.3790.1830); Subject: Would like a bigger paycheck? Date: Wed, 21 Sep 2005 13:46:07 -0700 From: "A. Sender" <asend@otherdomain.com> To: <joefoo@customerdomain.org> |
Notes for the above table:
- The Cisco appliance ignores these headers.
- The Cisco appliance receives the message (not counted as a hop).
- First hop (and incoming relay).
- Second hop. This is the sending MTA. The IP address is 7.8.9.1.
- The Cisco appliance ignores these Microsoft Exchange headers.
The following table shows the headers for the same email message, without the extraneous headers
|
1 |
Received: from mta.customerdomain.org ([10.2.3.5]) by ironport.customerdomain.org with ESMTP; 21 Sep 2005 13:46:07 -0700 |
|
2 |
Received: from mx.customerdomain.org (mx.customerdomain.org) [10.2.3.4]) by mta.customerdomain.org (8.12.11/8.12.11) with ESMTP id j8LKkWu1008155 for <joefoo@customerdomain.org>; |
|
3 |
Received: from sending-machine.spamham.com (sending-machine.spamham.com [7.8.9.1]) by mx.customerdomain.org (Postfix) with ESMTP id 4F3DA15AC22 for <joefoo@customerdomain.org>; |
The following figure shows the incoming relay for path A (above) as configured in the Add Relay page in the GUI:
How Incoming Relays Affect Functionality
- Incoming Relays and Filters
- Incoming Relays, HAT, SBRS, and Sender Groups
- Incoming Relays and Directory Harvest Attack Prevention
- Incoming Relays and Trace
- Incoming Relays and Email Security Monitor (Reporting)
- Incoming Relays and Message Tracking
- Incoming Relays and Logging
Incoming Relays and Filters
The Incoming Relays feature provides the various SenderBase Reputation Service related filter rules ( reputation, no-reputation ) with the correct SenderBase Reputation score.
Incoming Relays, HAT, SBRS, and Sender Groups
HAT policy groups do not currently use information from Incoming Relays. However, because the Incoming Relays feature does supply the SenderBase Reputation score, you can simulate HAT policy group functionality via message filters and the $reputation variable.
Incoming Relays and Directory Harvest Attack Prevention
If a remote host attempts a directory harvest attack by sending messages to the MX or MTA serving as an incoming relay on your network, the appliance drops the connection from the incoming relay if the relay is assigned to a sender group with a mail flow policy with Directory Harvest Attack Prevention (DHAP) enabled. This prevents all messages from the relay, including legitimate messages, from reaching the Email Security appliance. The appliance does not have the opportunity to recognize the remote host as the attacker and the MX or MTA that’s acting as the incoming relay continues to receive mail from the attacking host. To work around this issue and continue receiving messages from the incoming relay, add the relay to a sender group with a mail flow policy that has unlimited messages for DHAP.
Incoming Relays and Trace
Trace returns the Incoming Relay’s SenderBase Reputation Score in its results instead of the reputation score for the source IP address.
Incoming Relays and Email Security Monitor (Reporting)
When using Incoming Relays:
- Email Security Monitor reports include data for both the external IP and the MX/MTA. For example, if an external machine (IP 7.8.9.1) sent 5 emails through the internal MX/MTA (IP 10.2.3.4), Mail Flow Summary will show 5 messages coming from IP 7.8.9.1 and 5 more coming from the internal relay MX/MTA (IP 10.2.3.5).
- The SenderBase Reputation score is not reported correctly in the Email Security Monitor reports. Also, sender groups may not be resolved correctly.
Incoming Relays and Message Tracking
When using Incoming Relays, the Message Tracking Details page displays the relay’s IP address and the relay’s SenderBase Reputation Score for a message instead of the IP address and reputation score of the original external sender.
Incoming Relays and Logging
In the following log example, the SenderBase Reputation score for the sender is reported initially on line 1. Later, once the Incoming Relay is processed, the correct SenderBase Reputation score is reported on line 5.
|
1 |
Fri Apr 28 17:07:29 2006 Info: ICID 210158 ACCEPT SG UNKNOWNLIST match nx.domain SBRS rfc1918 |
|
2 |
Fri Apr 28 17:07:29 2006 Info: Start MID 201434 ICID 210158 |
|
3 |
Fri Apr 28 17:07:29 2006 Info: MID 201434 ICID 210158 From: <joe@sender.com> |
|
4 |
Fri Apr 28 17:07:29 2006 Info: MID 201434 ICID 210158 RID 0 To: <mary@example.com> |
|
5 |
Fri Apr 28 17:07:29 2006 Info: MID 201434 IncomingRelay(senderdotcom): Header Received found, IP 192.192.108.1 being used, SBRS 6.8 |
|
6 |
Fri Apr 28 17:07:29 2006 Info: MID 201434 Message-ID '<7.0.1.0.2.20060428170643.0451be40@sender.com>' |
|
7 |
Fri Apr 28 17:07:29 2006 Info: MID 201434 Subject 'That report...' |
|
8 |
Fri Apr 28 17:07:29 2006 Info: MID 201434 ready 2367 bytes from <joe@sender.com> |
|
9 |
Fri Apr 28 17:07:29 2006 Info: MID 201434 matched all recipients for per-recipient policy DEFAULT in the inbound table |
|
10 |
Fri Apr 28 17:07:34 2006 Info: ICID 210158 close |
|
11 |
Fri Apr 28 17:07:35 2006 Info: MID 201434 using engine: CASE spam negative |
|
12 |
Fri Apr 28 17:07:35 2006 Info: MID 201434 antivirus negative |
|
13 |
Fri Apr 28 17:07:35 2006 Info: MID 201434 queued for delivery |
Incoming Relays and Mail Logs
The following example shows a typical log entry containing Incoming Relay information:
Wed Aug 17 11:20:41 2005 Info: MID 58298 IncomingRelay(myrelay): Header Received found, IP 192.168.230.120 being used |
Configuring Logs to Specify Which Headers Are Used
Your Cisco appliance only examines the headers that were present when the message was received. So, additional headers added locally (such as Microsoft Exchange headers, etc.) or when the message is received by the Cisco appliance are not processed. One way to help determine which headers are used is to configure AsyncOS logging to include the headers you use.
To configure logging settings for headers, see Configuring Global Settings for Logging.
Monitoring Rules Updates
Once you have accepted the license agreement, you can view the most recent Cisco Anti-Spam and Cisco Intelligent Multi-Scan rules updates.
| Step 1 | Select
Security
Services > IronPort Anti-Spam.
or | ||||||||
| Step 2 | Select Security Services > IronPort Intelligent Multi-Scan. | ||||||||
| Step 3 | Look at the
Rule
Updates section and:
|
Testing Anti-Spam
|
To |
Do This |
More Information |
|---|---|---|
|
Test your configuration. |
Test your configuration using the X-advertisement: spam header. For testing purposes, Cisco Anti-Spam considers any message with an X-header formatted as X-Advertisement: spam to be spam. |
The test message you send with this header is flagged by Cisco Anti-Spam, and you can confirm that the actions you configured for the mail policy (Defining Anti-Spam Policies) are performed. Use this header with one of the following:
|
|
Evaluate Anti-Spam engine efficacy. |
Evaluate the product using a live mail stream directly from the Internet. |
For a list of ineffective evaluation approaches that you should avoid, see Ways Not to Test Anti-Spam Efficacy. |
Sending an Email to the Appliance to Test Cisco Anti-Spam
Before You Begin
Review the example in Testing Anti-Spam Configuration: Example Using SMTP.
| Step 1 | Enable Cisco Anti-Spam on a mail policy. |
| Step 2 | Send a test
email that includes the following header to a user in that mail policy:
X-Advertisement: spam
Use SMTP commands with Telnet to send this message to an address to which you have access. |
| Step 3 | Check the
mailbox of the test account and confirm that the test message was correctly
delivered based upon the actions you configured for the mail policy.
For example: |
Testing Anti-Spam Configuration: Example Using SMTP
For this example, the mail policy must be configured to receive messages for the test address and the HAT must accept the test connection.
# telnet IP_address_of_IronPort_Appliance_with_IronPort_Anti-Spam port 220 hostname ESMTP helo example.com 250 hostname mail from: <test@example.com> 250 sender <test@example.com> ok rcpt to: <test@address> 250 recipient <test@address> ok data 354 go ahead Subject: Spam Message Test X-Advertisement: spam spam test . 250 Message MID accepted 221 hostname quit
Ways Not to Test Anti-Spam Efficacy
Because IronPort AntiSpam and Cisco Intelligent Multi-Scan rules are added quickly to prevent active spam attacks and quickly expire once attacks have passed, you should not test efficacy using any of the following methods:
-
Evaluating using resent or forwarded mail or cut-and-pasted spam messages.
Mail lacking the proper headers, connecting IP, signatures, etc. will result in inaccurate scores.
-
Testing “hard spam” only.
Removing the “easy spam” using SBRS, blacklists, message filters, etc. will result in a lower overall catch rate percentage.
-
Resending spam caught by another anti-spam vendor.
-
Testing older messages.
The scanning engine adds and removes rules rapidly based on current threats. Testing using old messages will therefore lead to inaccurate test results.
Feedback