User Guide for AsyncOS 11.1 for Cisco Email Security Appliances - GD (General Deployment)
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.
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.
You can license and enable both these solutions on your 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
Procedure
Command or Action
Purpose
Step 1
Enable anti-spam scanning on the 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
.
(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.
If your 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.
Your 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.
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.
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.
If you have not
enabled IronPort Anti-Spam in the system setup wizard:
Click
Enable.
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
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.
Cisco advises not to exceed 3 MB for the always scan message size. A larger value may result in decreased performance.
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.
Cisco advises not to exceed 10 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.
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.
If you have not
enabled Cisco Intelligent Multi-Scan in the system setup wizard:
Click
Enable.
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.
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.
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.
(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.
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.
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 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:
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
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.
Procedure
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.
Log in to your appliance using the web interface.
Go to System Administration > Email Submission and Tracking Portal Registration.
If your appliance is part of a cluster, set the mode to cluster level.
Click Set Registration ID.
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 (_).
Submit and commit your changes.
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 can be done in any one of the following ways:
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.
Note
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.
Registering when you are the first administrator in your organization to access the portal:
On Email Submission and Tracking Portal, select Register a new Registration ID, 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.
Registering when an administrator in your organization is already registered on the portal:
On Email Submission and Tracking Portal, select Register as an administrator, enter the email address of the administrator already registered in the portal, and click Register.
After you click Register, an email notification is sent to the administrator who is already registered on the portal. The
administrator needs to log in to the portal, and click Admin registration requests in the Configuration Panel to allow or reject your registration request.
Step 3
Register your
domain with Cisco Email Submission and Tracking Portal.
Go to Cisco Email Submission and Tracking Portal.
Click Configuration > Domains.
Click Add new domain.
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
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.
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.
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.
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.
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 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
appliance
, as well as the header used to store the originating IP address.
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 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 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 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 appliance
.
Figure 5. Mail Relayed by MX/MTA — Advanced
Configuring the Appliance
to Work with Incoming Relays
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.
Procedure
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 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.
Select the
header type:
Choose
custom headers (recommended) or Received headers.
For custom
headers:
Enter the
header name that you configured the relaying machine to add to relayed
messages.
For
example:
SenderIP
or
X-CustomHeader
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.
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
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 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 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 appliance
is parsed. If neither the parsing character nor a valid IP address is found, the 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 appliance
as in Figure - Mail Relayed by MX/MTA — Advanced. This example shows extraneous headers (ignored by your 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 appliance
ignores these headers.
The 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 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
The Incoming Relays feature provides the various IP Reputation Service related filter rules (reputation, no-reputation) with
the correct IP 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 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.
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 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 theappliance
are not processed. One way to help determine which headers are used is to configure AsyncOS logging to include the headers
you use.
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.
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?
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, blocked lists, 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