IronPort - daily management guide - AsyncOS 7.6.1

Working with Safelists and Blocklists
4-38
Cisco IronPort AsyncOS 7.6 for Email Daily Management Guide
Chapter 4 Quarantines
For more information about working with safelists and blocklists on an M-Series appliance, see the
Cisco IronPort AsyncOS for Security Management User Guide .
Creating and Maintaining Safelists and Blocklists
The safelists and blocklists are created and maintained by end users. However, an administrator enables
the feature and configures delivery settings for email messages matching entries in the blocklist. To
create and maintain safelists and blocklists, the administrators and end-users complete the following
tasks:
Administrator tasks. Administrators enable and configure the Cisco IronPort Spam Quarantine,
enable the Safelist/Blocklist feature, backup and restore the Safelist/Blocklist database, synchronize
the Safelist/Blocklist database between different appliances, and troubleshoot safelist and blocklist
issues via logs, alerts, and custom headers. For more information about administrator tasks, see
Administrator Tasks for Creating and Maintaining Safelists and Blocklists, page 4-39.
End-user tasks. End-users create their safelist and blocklist settings via the end-user spam
quarantine. End users may need to log in (instead of clicking the link in the Cisco IronPort Spam
Quarantine notification) to access their safelist/blocklist settings. From the end-user spam
quarantine, end-users can create safelists and blocklists from the Options menu. Or, end-users can
create safelist settings from the list of quarantined emails. For details about end-user tasks, see End
User Tasks for Configuring Safelists and Blocklists, page 4-41.
Message Delivery For Safelists and Blocklists
When you enable safelists and blocklists, the Cisco IronPort appliance scans the messages against the
safelist/blocklist database immediately prior to anti-spam scanning. If the Cisco IronPort appliance
detects a sender or domain that matches an end user’s safelist/blocklist setting, the message will be
splintered if there are multiple recipients (and the recipients have different safelist/blocklist settings).
For example, a message is sent to both recipient A and recipient B. Recipient A has safelisted the sender,
whereas recipient B does not have an entry for the sender in either safelist or blocklist. In this case, the
message may be split into two messages with two message IDs. The message sent to recipient A is
marked as safelisted with an X-SLBL-Result-Safelist header, and skips anti-spam scanning, whereas the
message bound for recipient B is scanned with the anti-spam scanning engine. Both messages then
continue along the pipeline (through anti-virus scanning, content policies, etc.), and are subject to any
settings configured.
If a message sender or domain is blocklisted, the delivery behavior depends on the blocklist action
settings. Similar to safelist delivery, the message is splintered if there are different recipients with
different safelist/blocklist settings. The blocklisted message splinter is then quarantined or dropped,
depending on the blocklist action settings. If the blocklist action is configured for quarantine, the
message is scanned and eventually quarantined. If the blocklist action is configured as drop, the message
is dropped immediately after safelist/blocklist scanning.
Because the safelist and blocklists are maintained in the Cisco IronPort Spam Quarantine, delivery
behavior is also contingent on other anti-spam settings. For example, if you configure the “Accept” mail
flow policy in the HAT to skip anti-spam scanning, then users who receive mail on that listener will not
have their safelist and blocklist settings applied to mail received on that listener. Similarly, if you create
a mailflow policy that skips anti-spam scanning for certain message recipients, these recipients will not
have their safelist and blocklist settings applied.
OL-25138-01