Cisco Cisco Email Security Appliance C170 사용자 가이드

다운로드
페이지 324
 
4-38
Cisco IronPort AsyncOS 7.6 for Email Daily Management Guide
OL-25138-01
Chapter 4      Quarantines
Working with Safelists and Blocklists
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 
.
  •
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 
.
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.