Cisco Cisco Email Security Appliance C160 Guía Del Usuario
7-29
Cisco AsyncOS 8.5.6 for Email User Guide
Chapter 7 Defining Which Hosts Are Allowed to Connect Using the Host Access Table (HAT)
Verifying Senders
Using the sender group “Connecting Host DNS Verification” settings, you can specify a behavior for
unverified senders (see
unverified senders (see
You can enable host DNS verification in the sender group settings for any sender group; however, keep
in mind that adding host DNS verification settings to a sender group means including unverified senders
in that group. That means that spam and other unwanted mail will be included. Therefore, you should
only enable these settings on sender groups that are used to reject or throttle senders. Enabling host DNS
verification on the WHITELIST sender group, for example, would mean that mail from unverified
senders would receive the same treatment as mail from your trusted senders in your WHITELIST
(including bypassing anti-spam/anti-virus checking, rate limiting, etc., depending on how the mail flow
policy is configured).
in mind that adding host DNS verification settings to a sender group means including unverified senders
in that group. That means that spam and other unwanted mail will be included. Therefore, you should
only enable these settings on sender groups that are used to reject or throttle senders. Enabling host DNS
verification on the WHITELIST sender group, for example, would mean that mail from unverified
senders would receive the same treatment as mail from your trusted senders in your WHITELIST
(including bypassing anti-spam/anti-virus checking, rate limiting, etc., depending on how the mail flow
policy is configured).
Sender Verification: Envelope Sender
With envelope sender verification, the domain portion of the envelope sender is DNS verified. (Does the
envelope sender domain resolve? Is there an A or MX record in DNS for the envelope sender domain?)
A domain does not resolve if an attempt to look it up in the DNS encounters a temporary error condition
such as a timeout or DNS server failure. On the other hand, a domain does not exist if an attempt to look
it up returns a definitive “domain does not exist” status. This verification takes place during the SMTP
conversation whereas host DNS verification occurs before the conversation begins — it applies to the IP
address of connecting SMTP server.
envelope sender domain resolve? Is there an A or MX record in DNS for the envelope sender domain?)
A domain does not resolve if an attempt to look it up in the DNS encounters a temporary error condition
such as a timeout or DNS server failure. On the other hand, a domain does not exist if an attempt to look
it up returns a definitive “domain does not exist” status. This verification takes place during the SMTP
conversation whereas host DNS verification occurs before the conversation begins — it applies to the IP
address of connecting SMTP server.
In more detail: AsyncOS performs an MX record query for the domain of the sender address. AsyncOS
then performs an A record lookup based on the result of the MX record lookup. If the DNS server returns
“NXDOMAIN” (there is no record for this domain), AsyncOS treats that domain as non-existent. This
falls into the category of “Envelope Senders whose domain does not exist.” NXDOMAIN can mean that
the root name servers are not providing any authoritative name servers for this domain.
then performs an A record lookup based on the result of the MX record lookup. If the DNS server returns
“NXDOMAIN” (there is no record for this domain), AsyncOS treats that domain as non-existent. This
falls into the category of “Envelope Senders whose domain does not exist.” NXDOMAIN can mean that
the root name servers are not providing any authoritative name servers for this domain.
However, if the DNS server returns “SERVFAIL,” it is categorized as “Envelope Senders whose domain
does not resolve.” SERVFAIL means that the domain does exist but DNS is having transient problems
looking up the record.
does not resolve.” SERVFAIL means that the domain does exist but DNS is having transient problems
looking up the record.
A common technique for spammers or other illegitimate senders of mail is to forge the MAIL FROM
information (in the envelope sender) so that mail from unverified senders that is accepted will be
processed. This can lead to problems as bounce messages sent to the MAIL FROM address are
undeliverable. Using envelope sender verification, you can configure your appliance to reject mail with
malformed (but not blank) MAIL FROMs.
information (in the envelope sender) so that mail from unverified senders that is accepted will be
processed. This can lead to problems as bounce messages sent to the MAIL FROM address are
undeliverable. Using envelope sender verification, you can configure your appliance to reject mail with
malformed (but not blank) MAIL FROMs.
For each mail flow policy, you can:
•
Enable envelope sender DNS verification.
•
Offer custom SMTP code and response for malformed envelope sender. Malformed envelope
senders are blocked if you have enabled envelope sender DNS verification.
senders are blocked if you have enabled envelope sender DNS verification.
•
Offer custom response for envelope sender domains which do not resolve.
•
Offer custom response for envelope sender domains which do not exist in DNS.
You can use the sender verification exception table to store a list of domains or addresses from which
mail will be automatically allowed or rejected (see
mail will be automatically allowed or rejected (see
). The
sender verification exception table can be enabled independently of Envelope Sender verification. So,
for example, you can still reject special addresses or domains specified in the exception table without
enabling envelope sender verification. You can also always allow mail from internal or test domains,
even if they would not otherwise be verified.
for example, you can still reject special addresses or domains specified in the exception table without
enabling envelope sender verification. You can also always allow mail from internal or test domains,
even if they would not otherwise be verified.