Cisco Cisco Email Security Appliance C160 Mode D'Emploi
7-8
Cisco AsyncOS 9.1 for Email User Guide
Chapter 7 Defining Which Hosts Are Allowed to Connect Using the Host Access Table (HAT)
Defining Access Rules for Email Senders Using Mail Flow Policies
Note
Be sure to include brackets in the query in the CLI. Brackets are not necessary when specifying a DNS
List query in the GUI. Use the
List query in the GUI. Use the
dnslistconfig
command in the CLI to test a query, configure general
settings for DNL queries, or flush the current DNS list cache.
Note that this mechanism can be used to identify “good” connections as well as “bad” connections. For
example, a query to query.bondedsender.org will match on connecting hosts who have posted a financial
bond with Cisco Systems’ Bonded Sender™ program to ensure the integrity of their email campaign.
You could modify the default WHITELIST sender group to query the Bonded Sender program’s DNS
servers (which lists these legitimate email senders who have willingly posted bonds) and adjust the mail
flow policy accordingly.
example, a query to query.bondedsender.org will match on connecting hosts who have posted a financial
bond with Cisco Systems’ Bonded Sender™ program to ensure the integrity of their email campaign.
You could modify the default WHITELIST sender group to query the Bonded Sender program’s DNS
servers (which lists these legitimate email senders who have willingly posted bonds) and adjust the mail
flow policy accordingly.
Defining Access Rules for Email Senders Using Mail Flow
Policies
Policies
Mail flow policies allow you to control or limit the flow of email messages from a sender to the listener
during the SMTP conversation. You control SMTP conversations by defining the following types of
parameters in the mail flow policy:
during the SMTP conversation. You control SMTP conversations by defining the following types of
parameters in the mail flow policy:
•
Connection parameters, such as maximum number of messages per connection.
•
Rate limiting parameters, such as maximum number of recipients per hour.
•
Modify custom SMTP codes and responses communicated during the SMTP conversation.
•
Enable spam detection.
•
Enable virus protection.
•
Encryption, such as using TLS to encrypt the SMTP connection.
•
Authentication parameters, such as using DKIM to verify incoming mail.
Ultimately, mail flow policies perform one of the following actions on connections from remote hosts:
•
ACCEPT. Connection is accepted, and email acceptance is then further restricted by listener
settings, including the Recipient Access Table (for public listeners).
settings, including the Recipient Access Table (for public listeners).
•
REJECT. Connection is initially accepted, but the client attempting to connect gets a 4XX or 5XX
SMTP status code. No email is accepted.
SMTP status code. No email is accepted.
Note
You can also configure AsyncOS to perform this rejection at the message recipient level (RCPT
TO), rather than at the start of the SMTP conversation. Rejecting messages in this way delays
the message rejection and bounces the message, allowing AsyncOS to retain more detailed
information about the rejected messages. This setting is configured from the CLI
TO), rather than at the start of the SMTP conversation. Rejecting messages in this way delays
the message rejection and bounces the message, allowing AsyncOS to retain more detailed
information about the rejected messages. This setting is configured from the CLI
listenerconfig > setup
command. For more information, see
•
TCPREFUSE. Connection is refused at the TCP level.
•
RELAY. Connection is accepted. Receiving for any recipient is allowed and is not constrained by
the Recipient Access Table.
the Recipient Access Table.