Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

User Guide for AsyncOS 11.0 for Cisco Email Security Appliances

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

User Guide for AsyncOS 11.0 for Cisco Email Security Appliances

Chapter Title

Anti-Spam

Results

Updated:
March 25, 2021

Chapter: Anti-Spam

Anti-Spam

This chapter contains the following sections:

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:
    • Not spam
    • Suspected spam
    • Positively-identified spam
  • 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 ActionPurpose
    Step 1 Enable anti-spam scanning on the Email Security appliance.  
    Note    Remaining steps in this table apply to both scanning engine options.

    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.  

    Defining Anti-Spam Policies

     
    Step 5 If you want certain messages to skip Cisco Anti-Spam scanning, create message filters that use the skip-spamcheck action.  

    Bypass Anti-Spam System 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.  

    Enable URL Filtering

     
    Step 10 Test your configuration.  

    Testing Anti-Spam

     
    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

      Step 1   Select Security Services > IronPort Anti-Spam.
      Step 2   If you have not enabled IronPort Anti-Spam in the system setup wizard:
      1. Click Enable.
      2. Scroll to the bottom of the license agreement page and click Accept to accept the agreement.
      Step 3   Click Edit Global Settings.
      Step 4   Select the check box for Enable IronPort Anti-Spam Scanning.

      Checking this box enables the feature globally for the appliance.

      Step 5   To optimize the throughput of your appliance while still being able to scan increasingly larger messages sent by spammers, configure the thresholds for message scanning by Cisco Anti-Spam.

      Option

      Description

      Message Scanning Thresholds

      1. Enter a value for Always scan messages smaller than —The recommended value is 1 MB or less. Messages smaller than the always scan size will be fully scanned, except in cases of “early exit.” Messages larger than this size are partially scanned if they are smaller than the never scan size.

        The value must not exceed 1 MB for the always scan message size. A larger value may result in decreased performance.

      2. Enter a value for Never scan messages larger than —The recommended value is 2 MB or less. Messages larger than this size will not be scanned by Cisco Anti-Spam and the X-IronPort-Anti-Spam-Filtered: true header will not be added to the message.

        The value must not exceed 2 MB for the never scan message size. A larger value may result in decreased performance.

        For messages larger than the always scan size or smaller than the never scan size, a limited and faster scan is performed.

        Note    If the Outbreak Filters maximum message size is greater than Cisco Anti-Spam’s always scan message, messages smaller than the Outbreak Filters maximum size are fully scanned.

      Timeout for Scanning Single Message

      Enter the number of seconds to wait for timeout when scanning a message.

      Enter an integer from 1 to 120. The default value is 60 seconds.

      Regional Scanning

      Enable or disable regional scanning and if applicable, select a region.

      Enable this feature only if you receive the bulk of your email from the specified region. Because this feature optimizes the anti-spam engine for a particular region, it can reduce capture rates for other types of spam.

      Step 6   Submit and commit your changes.

      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:
        1. Click Enable.
        2. Scroll to the bottom of the license agreement page and click Accept to accept the agreement.
        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:

        • Always scan 512K or less.

        • Never scan 1M or more.

        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

          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:

          Option

          Description

          Enable Suspected Spam Scanning

          Enable Marketing Email Scanning

          Choose an option.

          Positively-identified spam scanning is always enabled if anti-spam scanning is enabled.

          Apply This Action to Message

          Choose which overall action to take on positively identified spam, suspected spam, or unwanted marketing messages:

          • Deliver
          • Drop
          • Bounce
          • Quarantine

          (Optional) Send to Alternate Host

          You can send identified messages to an alternate destination mailhost (an email server other than the ones listed in SMTP Routes or DNS).

          Enter an IP address or hostname. If you enter a hostname, its Mail Exchange (MX) will be queried first. If none exists, the A record on the DNS server will be used (as with SMTP Routes).

          Use this option if you want to redirect messages, for example to a sandbox mail server for further examination.

          For additional important information, see Alter Delivery Host Action.

          Add Text to Subject

          You can alter text in the Subject of identified messages by prepending or appending certain text strings to help users more easily identify and sort spam and unwanted marketing messages.

          Note    White space is not ignored in this field. Add spaces after (if prepending) or before (if appending) the text you enter in this field to separate your added text from the original subject of the message. For example, if you are prepending, add the text [SPAM] with a few trailing spaces.

          “Add Text to Subject” field only accepts US-ASCII characters.

          Advanced Options (for custom header and message delivery)

          (Optional) Add Custom Header

          You can add a custom header to identified messages.

          Click Advanced and define header and value.

          You can use a custom header in conjunction with a content filter to perform actions such as redirecting URLs in suspected spam messages so that they pass through the Cisco Web Security proxy service. For information, see Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy: Configuration Example.

          (Optional) Send to an Alternate Envelope Recipient

          You can have identified messages sent to an alternate envelope recipient address.

          Click Advanced and define an alternate address.

          For example, you could route messages identified as spam to an administrator’s mailbox for subsequent examination. In the case of a multi-recipient message, only a single copy is sent to the alternate recipient.

          Archive Message

          You can archive identified messages into the “Anti-Spam Archive” log. The format is an mbox-format log file.

          Spam Thresholds

          Use the default thresholds or enter a threshold value for positively identified spam and a value for suspected spam.

          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

          • Deliver with “ [Positive Spam] ” added to the subject of messages, or
          • Quarantine

          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:
            1. Select Mail Policies > Incoming Mail Policies.
            2. Click the link in the Anti-Spam column for a policy such as the Default policy.
            3. In the Suspected Spam Settings section, enable suspected spam scanning.
            4. Click Advanced to display the Add Custom Header option.
            5. Add a custom header such as url_redirect .
            6. Submit and commit your changes.
            Step 2   Create a content filter to redirect URLs in messages that have the custom header:
            1. Select Mail Policies > Incoming Content Filters.
            2. Click Add Filter.
            3. Name the filter url_redirect .
            4. Click Add Condition.
            5. Click Other Header.
            6. Enter the header name: url_redirect .

              Make sure this exactly matches the header you created above.

            7. Select Header exists.
            8. Click OK.
            9. Click Add Action.
            10. Click URL Category.
            11. Select all categories in Available Categories and add them to Selected Categories.
            12. For Action on URL, select Redirect to Cisco Security Proxy.
            13. Click OK.
            Step 3   Add the content filter to the mail policy.
            1. Select Mail Policies > Incoming Mail Policies.
            2. Click the link in the Content Filters column for the policy that you selected earlier in this procedure.
            1. Select Enable Content Filters if it is not already selected.
            2. Select the check box to enable the url_filtering content filter.
            3. Submit and commit your changes.

            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.

            Figure 1. Mail Policies - Anti -spam Engine Per Recipient



            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.

            Figure 2. Mail Policies - Enabling Cisco Intelligent Multi-scan



            After submitting and committing the changes, the mail policy looks like this:

            Figure 3. Mail Policies - Intelligent Multi-Scan Enabled in Policy



            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:

            • Missed spam
            • Message marked as a spam, but is not a spam
            • Missed marketing message
            • Message marked as a marketing message, but is not a marketing message
            • Missed phishing message

            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.
              1. Log in to your appliance using the web interface.
              2. Go to System Administration > Email Submission and Tracking Portal Registration.
              3. If your appliance is part of a cluster, set the mode to cluster level.
              4. Click Set Registration ID.
              5. Enter a value in the Registration ID field. The value that you enter must be at least 16 characters, but not more than 48 characters and must contain only alphanumeric characters, hyphen (-), and underscore (_).
              6. Submit and commit your changes.
              7. If your appliance is not part of a cluster, you must repeat steps 1 through 6 on all the appliances in your 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.
              1. Log in to Cisco SecurityHub ( https:/​/​securityhub.cisco.com/​) using your Cisco credentials.
              2. Click Email Submission and Tracking.
              3. On Email Submission and Tracking Portal, select As administrator, enter the Registration ID you created in Step 1, and click Register. Make sure that the registration ID you enter here is same as what you entered while configuring the Email Submission and Tracking Portal settings on your appliances.
              Step 3   Register your domain with Cisco Email Submission and Tracking Portal.
              1. Go to Cisco Email Submission and Tracking Portal.
              2. Click Configuration > Domains.
              3. Click Add new domain.
              4. Enter your organization’s domain and click Add.
              Note    Make sure that you enter a valid domain name, for example, example.com is the domain name in the following email address: user@example.com. If you have multiple domains in your organization, make sure that you add all the domains.

              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

                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

                  https:/​/​www.cisco.com/​c/​en/​us/​support/​docs/​security/​email-security-appliance /​117822-qanda-esa-00.html

                  Work with Cisco Email Submission and Tracking Portal

                  https:/​/​www.cisco.com/​c/​en/​us/​support/​docs/​security/​email-security-appliance /​200648-ESA-FAQ-How-to-work-with-Cisco-Email-Su.html

                  Troubleshoot Cisco Email Submission and Tracking Portal

                  https:/​/​www.cisco.com/​c/​en/​us/​support/​docs/​security/​email-security-appliance/​ 200653-ESA-FAQ-Troubleshooting-Email-Submissio.html

                  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:

                  You can achieve best results if you use one of the following email programs to forward the message:

                  • Apple Mail
                  • Microsoft Outlook for Mac
                  • Microsoft Outlook Web App
                  • Mozilla Thunderbird

                  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

                    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.

                    Figure 4. Mail Relayed by MX/MTA — Simple



                    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.

                    Figure 5. Mail Relayed by MX/MTA — Advanced



                    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.
                      Step 1   Select Network > Incoming Relays.
                      Step 2   Click Enable.
                      Step 3   Commit your changes.

                      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.

                      • Determine whether you will use custom or received headers to identify the IP address of the original external sender.
                      • If you will use custom headers:
                        • Determine the exact header that will label the originating IP address of relayed messages.
                        • For each MX, MTA, or other machine that connects to original external senders, set up that machine to add the header name and the IP address of the original external sender to incoming 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:

                        • 2620:101:2004:4202::0-2620:101:2004:4202::ff

                        • 2620:101:2004:4202::

                        • 2620:101:2004:4202::23

                        • 2620:101:2004:4202::/64

                        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.

                        1. Select the header type:

                          Choose custom headers (recommended) or Received headers.

                        2. For custom headers:

                          Enter the header name that you configured the relaying machine to add to relayed messages.

                          For example:

                          SenderIP

                          or

                          X-CustomHeader

                        3. For Received headers:

                          Enter the character or string after which the IP address will appear. Enter the number for the “hop” to check for the IP address.

                        Step 6   Submit and commit your changes.
                        What to Do Next

                        Consider doing the following:

                        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.

                        Figure 6. Mail Relayed by MX/MTA — Variable Number of Hops



                        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.

                        Table 1  A Series of Received: Headers (Path A Example 1)

                        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

                        Table 2  A Series of Received: Headers (Path A Example 2)

                        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:

                        Figure 7. A Configured Incoming Relay with Received Header



                        How Incoming Relays Affect Functionality

                        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:

                          To

                          More Information

                          See the most recent update for each component

                          If an update has not occurred, or a server has not been configured, “Never Updated” is displayed.

                          See if an update is available

                          —

                          Update rules if updates are available

                          Click Update Now.

                          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:

                            • Was the subject line altered?

                            • Was your additional custom header added?

                            • Was the message delivered to an alternate address?

                            • Was the message dropped?

                            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.

                            Was this Document Helpful?

                            FeedbackFeedback

                            Contact Cisco

                            Related Cisco Community Discussions

                            About Us
                            Contact Us
                            Work with Us