Cisco Cisco Email Security Appliance X1070 Information Guide
How does the Exception Table on the ESA work?
Document ID: 118506
Contributed by Shiu Ng and Enrico Werner, Cisco TAC Engineers.
Oct 09, 2014
Contents
Introduction
How does the Exception Table on the ESA work?
Allow Action
Reject Action
How does the Exception Table on the ESA work?
Allow Action
Reject Action
Introduction
This document describes how the Exception Table on the Email Security Appliance (ESA) works.
How does the Exception Table on the ESA work?
The Exception Table lists email addresses − full or partial − with two different types of behavior: Allow or
Reject. In the Mail Flow Policies, the option "Use Sender Verification Exception Table" needs to be checked,
otherwise the Exception Table entries will not be matched.
Reject. In the Mail Flow Policies, the option "Use Sender Verification Exception Table" needs to be checked,
otherwise the Exception Table entries will not be matched.
Allow Action
Allow listings in the Exception Table bypass Sender DNS Verification. If the envelope sender's domain or
email address is listed in the Exception Table, the sender will be allowed to proceed with sending the mail to
the ESA, whether the domain name of the envelope sender email address can be resolved or not. This is
useful when sender DNS verification is enabled and the domain cannot be resolved (e.g. allow mail from
internal or test domains, even if they would not otherwise be verified).
email address is listed in the Exception Table, the sender will be allowed to proceed with sending the mail to
the ESA, whether the domain name of the envelope sender email address can be resolved or not. This is
useful when sender DNS verification is enabled and the domain cannot be resolved (e.g. allow mail from
internal or test domains, even if they would not otherwise be verified).
If Sender DNS Verification is enabled for the Mail Flow Policy in use, and an envelope sender's domain name
cannot be resolved (it does not exist, cannot be resolved, or is malformed), the message will be rejected. Here
is an example of an SMTP response:
cannot be resolved (it does not exist, cannot be resolved, or is malformed), the message will be rejected. Here
is an example of an SMTP response:
SMTP code: 553
Message: #5.1.8 Domain of sender address <$EnvelopeSender> does not exist
If the email address or domain of the envelope sender is listed in the Exception Table with Allow behavior,
then the sender can proceed with the remainder of the message (RCPT TO, DATA, etc, and normal processing
of the message will take place: message filters, Anti−Spam scanning, etc.). This allows the message into the
appliance despite the domain name of the sender not being verifiable. For example, the sender will be rejected
under the following circumstances:
then the sender can proceed with the remainder of the message (RCPT TO, DATA, etc, and normal processing
of the message will take place: message filters, Anti−Spam scanning, etc.). This allows the message into the
appliance despite the domain name of the sender not being verifiable. For example, the sender will be rejected
under the following circumstances:
the envelope sender is user@example.com
•
the domain "example.com" does not exist
•
user@example.com is not in the Exception Table allow list
•
example.com are not in the Exception Table allow list
mail from:user@example.com
mail from:user@example.com
•