Cisco ESA Admin Guide 14-0
Uploaded by
Samir AliyevCisco ESA Admin Guide 14-0
Uploaded by
Samir AliyevUser Guide for AsyncOS 14.
0 for Cisco Secure Email Gateway - GD
(General Deployment)
First Published: 2021-03-22
Last Modified: 2021-04-21
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of
the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.
Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:
https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (1721R)
© 2021 Cisco Systems, Inc. All rights reserved.
CONTENTS
CHAPTER 1 Getting Started with Cisco Secure Email Gateway 1
What's New in AsyncOS 14.0 1
Comparison of Web Interfaces, New Web Interface with Legacy Web Interface 13
Where to Find More Information 16
Documentation 16
Training 17
Cisco Notification Service 17
Knowledge Base 17
Cisco Support Community 17
Cisco Customer Support 18
Third Party Contributors 18
Cisco Welcomes Your Comments 18
Registering for a Cisco Account 18
Cisco Secure Email Gateway Overview 19
Supported Languages 20
CHAPTER 2 Accessing the Email Gateway 21
Web-based Graphical User Interface (GUI) 21
Browser Requirements 21
Accessing the GUI 22
Factory Default Username and Passphrase 22
Centralized Management 22
Enhanced User Experience using How-Tos Widget 23
Disabling How-Tos Widget on the Email Gateway 23
Changing Configuration Settings 24
Configuration Changes 24
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
iii
Contents
Commit or Abandoning Changes 24
Command Line Interface (CLI) 24
CHAPTER 3 Setup and Installation 25
Installation Planning 25
Review Information That Impacts Planning Decisions 25
Plan to Place the Email Gateway at the Perimeter of Your Network 25
Register the Email Security Appliance in DNS 26
Installation Scenarios 27
Configuration Overview 27
Incoming 27
Outgoing 27
Ethernet Interfaces 27
Hardware Ports 28
Advanced Configurations 28
Firewall Settings (NAT, Ports) 28
Physically Connecting the Email Gateway to the Network 28
Configuration Scenarios 29
Segregating Incoming and Outgoing Mail 29
Preparing for System Setup 32
Determine Method for Connecting to the Email Gateway 33
Connecting to the Email Gateway 33
Determining Network and IP Address Assignments 34
Default IP Addresses for Management and Data Ports 34
Choosing Network Connections to Receive and Deliver Email 34
Binding Logical IP Addresses to Physical Ethernet Ports 34
Choosing Network Settings for Your Connections 34
Gathering the Setup Information 35
Using the System Setup Wizard 38
Accessing the Web-Based Graphical User Interface (GUI) 38
Factory Default Username and Passphrase 39
Accessing the Legacy Web Interface 40
Accessing New Web Interface in Dusk Mode 40
Defining Basic Configuration Using the Web-Based System Setup Wizard 40
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
iv
Contents
Step 1: Start 41
Step 2: System 42
Step 3: Network 43
Step 4: Security 47
Step 5: Review 48
Setting up the Connection to Active Directory 48
Proceeding to the Next Steps 49
Accessing the Command Line Interface (CLI) 49
Factory Default Username and Passphrase 49
Running the Command Line Interface (CLI) System Setup Wizard 50
Change the Admin Passphrase 51
Accept the License Agreement 51
Set the Hostname 51
Assign and Configure Logical IP Interface(s) 52
Specify the Default Gateway 52
Enable the Web Interface 53
Configure the DNS Settings 53
Create a Listener 53
Enable Anti-Spam 60
Select a Default Anti-Spam Scanning Engine 61
Enable the Spam Quarantine 61
Enable Anti-Virus Scanning 61
Enable Outbreak Filters 61
Configure the Alert Settings and AutoSupport 62
Configure Scheduled Reporting 62
Configure Time Settings 62
Commit Changes 62
Test the Configuration 62
Immediate Alerts 63
Configuring your system as an Enterprise Gateway 63
Verifying Your Configuration and Next Steps 63
CHAPTER 4 Understanding the Email Pipeline 65
Overview of the Email Pipeline 65
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
v
Contents
Email Pipeline Flows 65
Incoming / Receiving 68
Host Access Table (HAT), Sender Groups, and Mail Flow Policies 68
Received: Header 69
Default Domain 69
Bounce Verification 69
Domain Map 69
Recipient Access Table (RAT) 69
Alias Tables 69
LDAP Recipient Acceptance 70
SMTP Call-Ahead Recipient Validation 70
Work Queue / Routing 70
Email Pipeline and Security Services 70
LDAP Recipient Acceptance 71
Masquerading or LDAP Masquerading 71
LDAP Routing 71
Message Filters 71
Email Security Manager (Per-Recipient Scanning) 72
Safelist/Blocklist Scanning 72
Anti-Spam 72
Anti-Virus 72
Graymail Detection and Safe Unsubscribing 73
File Reputation Scanning and File Analysis 73
Content Filters 73
Outbreak Filters 73
Quarantines 73
Delivery 74
Virtual gateways 74
Delivery Limits 74
Domain-Based Limits 74
Domain-Based Routing 74
Global Unsubscribe 75
Bounce Limits 75
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
vi
Contents
CHAPTER 5 Configuring the Gateway to Receive Email 77
Overview of Configuring the Gateway to Receive Email 77
Working with Listeners 78
Configuring Global Settings for Listeners 80
Settings for Messages Containing Multiple Encodings 82
Listening for Connection Requests by Creating a Listener Using Web Interface 83
Partial Domains, Default Domains, and Malformed MAIL FROMs 87
Listening for Connection Requests by Creating a Listener Using CLI 88
Advanced HAT Parameters 89
Enterprise Gateway Configuration 90
CHAPTER 6 IP Reputation Filtering 93
Overview of Sender IP Reputation Filtering 93
IP Reputation Service 93
IP Reputation Score 94
How Sender IP Reputation Filters Work 95
Recommended Settings for Different Sender IP Reputation Filtering Approaches 95
Editing IP Reputation Filtering Score Thresholds for a Listener 96
Testing IP Reputation Filtering Using the IP Reputation Scores 97
Entering Low IP Reputation Scores in the Message Subject 98
CHAPTER 7 Defining Which Hosts Are Allowed to Connect Using the Host Access Table 101
Overview of Defining Which Hosts Are Allowed to Connect 101
Default HAT Entries 102
Defining Remote Hosts into Sender Groups 102
Sender Group Syntax 103
Sender Groups Defined by Network Owners, Domains, and IP Addresses 104
Setting Policies Based on the HAT 105
Defining Sender Groups by IP Reputation Score 106
Sender Groups Defined by Querying DNS Lists 107
Defining Access Rules for Email Senders Using Mail Flow Policies 107
HAT Variable Syntax 108
Using HAT Variables 109
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
vii
Contents
Testing HAT Variables 110
Understanding Predefined Sender Groups and Mail Flow Policies 110
Handling Messages from a Group of Senders in the Same Manner 112
Creating a Sender Group for Message Handling 113
Adding a Sender to an Existing Sender Group 114
Rearranging the Order of the Rules to Perform for Incoming Connections 114
Searching for Senders 115
Defining Rules for Incoming Messages Using a Mail Flow Policy 115
Defining Default Values for Mail Flow Policies 120
Working with the Host Access Table Configuration 121
Exporting the Host Access Table Configuration to an External File 121
Importing the Host Access Table Configuration from an External File 121
Using a List of Sender Addresses for Incoming Connection Rules 122
SenderBase Settings and Mail Flow Policies 123
HAT Significant Bits Feature 123
HAT Configuration 124
Significant Bits HAT Policy Option 124
Injection Control Periodicity 124
Verifying Senders 125
Sender Verification: Host 125
Sender Verification: Envelope Sender 126
Partial Domains, Default Domains, and Malformed MAIL FROMs 127
Custom SMTP Code and Response 127
Sender Verification Exception Table 127
Implementing Sender Verification — Example Settings 128
Throttling Messages from Unverified Senders Using the SUSPECTLIST Sender Group 129
Implementing More Stringent Throttling Settings for Unverified Senders 129
Defining Messages to Send to Unverified Senders Using the ACCEPTED Mail Flow Policy 129
Excluding Unverified Senders from Sender Verification Rules Based on Sender’s Email Address
130
Searching for Addresses within the Sender Verification Exception Table 130
Testing Your Settings for Messages from Unverified Senders 130
Sending a Test Message with a Malformed MAIL FROM Sender Address 131
Sending a Message from an Address That is Excluded from Sender Verification Rules 131
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
viii
Contents
Sender Verification and Logging 132
Envelope Sender Verification 132
CHAPTER 8 Accepting or Rejecting Connections Based on Domain Name or Recipient Address 133
Overview of Accepting or Rejecting Connections Based on the Recipient’s Address 133
Overview of the Recipient Access Table (RAT) 134
Accessing the RAT using the GUI 134
Accessing the RAT using the CLI 134
Editing the Default RAT Entry 134
Domains and Users 135
Adding Domains and Users For Which to Accept Messages 135
Defining Recipient Addresses 136
Bypassing LDAP Accept for Special Recipients 136
Bypassing Throttling for Special Recipients 137
Rearranging the Order of Domains and Users in the Recipient Access Table 137
Exporting the Recipient Access Table to an External File 138
Importing the Recipient Access Table from an External File 138
CHAPTER 9 Using Message Filters to Enforce Email Policies 139
Overview 139
Components of a Message Filter 140
Message Filter Rules 140
Message Filter Actions 140
Message Filter Example Syntax 141
Message Filter Processing 142
Message Filter Order 143
Message Header Rules and Evaluation 143
Message Bodies vs. Message Attachments 143
Thresholds for Matches in Content Scanning 144
Threshold Syntax 145
Threshold Scoring for Message Bodies and Attachments 145
Threshold Scoring Multipart/Alternative MIME Parts 145
Threshold Scoring for Content Dictionaries 146
AND Test and OR Tests in Message Filters 147
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
ix
Contents
Message Filter Rules 147
Filter Rules Summary Table 148
Regular Expressions in Rules 158
Using Regular Expressions to Filter Messages 160
Guidelines for Using Regular Expressions 160
Regular Expression and Non-ASCII Character Sets 161
n Tests 161
Case-sensitivity 161
Writing Efficient Filters 161
PDFs and Regular Expressions 162
Smart Identifiers 162
Smart Identifier Syntax 163
Description and Examples of Message Filter Rules 164
True Rule 165
Valid Rule 165
Subject Rule 165
Envelope Recipient Rule 166
Envelope Recipient in Group Rule 166
Envelope Sender Rule 167
Envelope Sender in Group Rule 167
Sender Group Rule 167
Body Size Rule 168
Remote IP Rule 169
Receiving Listener Rule 169
Receiving IP Interface Rule 169
Date Rule 169
Header Rule 170
Random Rule 170
Recipient Count Rule 171
Address Count Rule 171
Body Scanning Rule 172
Body Scanning 172
Encryption Detection Rule 173
Attachment Type Rule 173
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
x
Contents
Attachment Filename Rule 174
DNS List Rule 175
IP Reputation Rule 175
Dictionary Rules 176
SPF-Status Rule 177
SPF-Passed Rule 179
S/MIME Gateway Message Rule 179
S/MIME Gateway Verified Rule 180
Workqueue-count Rule 180
SMTP Authenticated User Match Rule 180
Signed Rule 182
Signed Certificate Rule 182
Header Repeats Rule 185
URL Reputation Rules 186
URL Category Rule 187
Corrupt Attachment Rule 188
Message Language Rule 188
Macro Detection Rule 189
Forged Email Detection Rule 190
Duplicate Boundaries Verification Rule 190
Malformed MIME Header Detection Rule 191
Geolocation Rule 191
Domain Reputation Rule for ETF 191
Domain Reputation Rule for SDR 192
Message Filter Actions 194
Filter Actions Summary Table 194
Attachment Groups 201
Action Variables 203
Non-ASCII Character Sets and Message Filter Action Variables 205
Matched Content Visibility 205
Description and Examples of Message Filter Actions 206
Skip Remaining Message Filters Action 207
Drop Action 207
Bounce Action 208
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xi
Contents
Encrypt Action 208
S/MIME Sign or Encrypt on Delivery Action 208
S/MIME Sign or Encrypt Action 208
Notify and Notify-Copy Actions 209
Blind Carbon Copy Actions 211
Quarantine and Duplicate Actions 213
Alter Recipient Action 214
Alter Delivery Host Action 214
Alter Source Host (Virtual Gateway address) Action 215
Archive Action 215
Strip Header Action 216
Insert Header Action 216
Edit Header Text Action 217
Edit Body Text Action 217
HTML Convert Action 218
Bounce Profile Action 219
Bypass Anti-Spam System Action 219
Bypassing Graymail Actions 220
Bypass Anti-Virus System Action 220
Bypass File Reputation Filtering and File Analysis System Actions 221
Bypass Outbreak Filter Scanning Action 221
Add Message Tag Action 221
Add Log Entry Action 222
URL Reputation Actions 222
URL Category Actions 224
No Operation 225
Forged Email Detection Action 225
Attachment Scanning 225
Message Filters for Scanning Attachments 227
Image Analysis 228
Configuring the Image Analysis Scanning Engine 228
Tuning Image Analysis Settings 229
Configuring the Message Filter to Perform Actions Based on Image Analysis Results 230
Creating Content Filters to Strip Attachments Based on Image Analysis Verdicts 231
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xii
Contents
Configuring an Action Based on Image Analysis Verdicts 231
Notifications 232
Examples of Attachment Scanning Message Filters 232
Inserting Headers 233
Dropping Attachments by File Type 233
Dropping Attachments by Dictionary Matches 234
Quarantining Protected Attachments 235
Detecting Unprotected Attachments 235
Detecting Malicious Files in Messages Attachments Using Message Filter 235
Using the CLI to Manage Message Filters 236
Creating a New Message Filter 238
Deleting a Message Filter 238
Moving a Message Filter 238
Activating and Deactivating a Message Filter 238
Activating or Deactivating a Message Filter 241
Importing Pre-Policy Filters 241
Exporting Message Filters 242
Viewing Non-ASCII Character Sets 242
Displaying a Message Filter List 242
Displaying Message Filter Details 243
Configuring Filter Log Subscriptions 243
Changing Message Encoding 244
Sample Message Filters 246
Message Filter Examples 251
Open-Relay Prevention Filter 251
Policy Enforcement Filters 251
Notify Based on Subject Filter 252
BCC and Scan Mail Sent to Competitors 252
Block Specific User Filter 252
Archive and Drop Messages Filter 252
Large “To:” Header Filter 253
Blank “From:” Filter 253
IP Reputation Filter 254
Alter IP Reputation Filter 254
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xiii
Contents
Filename Regex Filter 254
Show IP Reputation Score in Header Filter 254
Insert Policy into Header Filter 254
Too Many Recipients Bounce Filter 255
Routing and Domain Spoofing 255
Using Virtual Gateways Filter 255
Same Listener for Deliver and Listener Filter 255
Single Listener Filter 256
Drop Spoofed Domain Filter (Single Listener) 256
Drop Spoofed Domain Filter (Multiple Listeners) 256
Another Drop Spoofed Domain Filter 257
Detect Looping Filter 257
Drop Message Attachments that match File SHA-256 Filter 258
Drop Messages if Attachment matches File SHA-256 Filter 258
Configuring Scan Behavior 258
Configuring Message Handling Actions for Unscannable Messages 263
Delivering the Message 263
Sending Message to Policy Quarantine 264
CHAPTER 10 Mail Policies 267
Overview of Mail Policies 267
How to Enforce Mail Policies on a Per-User Basis 268
Handling Incoming and Outgoing Messages Differently 269
Matching Users to a Mail Policy 269
First Match Wins 270
Examples of Policy Matching 270
Example 1 271
Example 2 271
Example 3 271
Message Splintering 271
Managed Exceptions 273
Configuring Mail Policies 273
Configuring the Default Mail Policy for Incoming or Outgoing Messages 273
Creating a Mail Policy for a Group of Senders and Recipients 274
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xiv
Contents
Defining Senders and Recipients for Mail Policies 274
Examples 276
Finding Which Policies Apply to a Sender or Recipient 277
Managed Exceptions 277
Setting Priority for Message Headers 278
CHAPTER 11 Content Filters 281
Overview of Content Filters 281
How Content Filters Work 281
How to Scan Message Content Using a Content Filter 282
Content Filter Conditions 282
Content Filter Actions 290
Action Variables 297
How to Filter Messages Based on Content 299
Creating a Content Filter 299
Enabling Content Filters for All Recipients by Default 300
Applying the Content Filter to Messages for a Certain User Group 301
Notes on Configuring Content Filters in the GUI 301
CHAPTER 12 Configuring Email Gateway to Consume External Threat Feeds 305
Overview of External Threat Feeds 305
How to Configure Email Gateway to Consume External Threat Feeds 306
Obtaining External Threat Feeds Feature Key 306
Enabling External Threat Feeds Engine on Email Gateway 308
Configuring an External Threat Feed Source 308
Handling Messages Containing Threats 311
Configuring a Sender Group for Handling Messages containing Threats 312
Configuring Content or Message Filters for Handling Messages Containing Threats 312
Detecting Malicious Domains in Messages Using Content Filter 313
Creating Domain Exception List 313
Detecting Malicious Domains in Messages Using Message Filter 314
Detecting Malicious URLs in Messages Using Content Filter 314
Detecting Malicious URLs in Messages Using Message Filter 316
Detecting Malicious Files in Message Attachments Using Content Filter 317
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xv
Contents
Creating File Hash List 318
Detecting Malicious Files in Messages Attachments Using Message Filter 318
Attaching Content Filter to Incoming Mail Policy 319
External Threat Feeds and Clusters 319
Monitoring External Threat Feeds Engine Updates 319
Viewing Alerts 320
Displaying Threat Details in Message Tracking 320
CHAPTER 13 Sender Domain Reputation Filtering 323
Overview of Sender Domain Reputation Filtering 323
SDR Verdicts 323
How to Filter Messages based on Sender Domain Reputation 325
Enabling Sender Domain Reputation Filtering on Email Gateway 326
Configuring Message or Content Filter for Handling Messages based on Sender Domain Reputation
327
Filtering Messages based on Sender Domain Reputation using Message Filter 327
Filtering Messages based on Sender Domain Reputation using Content Filter 329
Creating Domain Exception List 330
Attaching Content Filter to Incoming Mail Policy 330
Sender Domain Reputation Filtering and Clusters 331
Displaying Sender Domain Reputation Details in Message Tracking 331
Viewing Alerts 332
Viewing Logs 332
Examples of SDR Filtering Log Entries 332
Sender Domain Reputation Authentication Failure 332
Sender Domain Reputation Request Timeout 333
Sender Domain Reputation Invalid Host 333
Sender Domain Reputation General Errors 333
CHAPTER 14 Integrating with Cisco SecureX Threat Response 335
Integrating your Email Gateway with Cisco SecureX Threat Response 335
How to Integrate your Email Gateway with Cisco SecureX Threat Response 336
Prerequisites 337
Enabling Cisco Cloud Services Portal on Email Gateway 338
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xvi
Contents
Registering Email Gateway with Cisco Cloud Services Portal 339
Confirm Whether the Registration was Successful 339
Enabling Cisco SecureX Threat Response on Email Gateway 339
Performing Threat Analysis using Cisco SecureX Ribbon 340
Accessing the Cisco SecureX Ribbon 340
Adding Observable to Casebook for Threat Analysis using Cisco SecureX Ribbon and Pivot Menu
342
Performing Remedial Actions on Messages in Cisco SecureX Threat Response 344
Improving User Experience of Email Gateway using Cisco Success Network 345
Enabling CSN on Email Gateway 346
Disabling CSN on Email Gateway 346
CHAPTER 15 Configuring Email Gateway to Safe Print Message Attachments 347
Overview 347
How to Configure Email Gateway to Safe Print Message Attachments 348
Configuring Safe Print Settings on Email Gateway 348
Configuring Content Filter to Safe Print Message Attachments 349
Attaching Content Filter to Incoming Mail Policy 351
Safe Print Settings and Clusters 352
Monitoring Messages with Safe-Printed Attachments 352
Viewing Logs 352
Examples of Safe Print Log Entries 352
Unable to Create Temporary Directory 353
Unable to Create Safe-printed PDF Attachment 353
Corrupt File 353
Encrypted File 353
Timeout Error 353
Displaying Safe Print Details in Message Tracking 353
CHAPTER 16 Integrating Email Gateway with Cisco Secure Awareness Cloud Service 355
Overview 355
How to Integrate Email Gateway with Cisco Secure Awareness Cloud Service 356
Creating Cisco Secure Awareness Cloud Service Account 357
Configuring Firewall Settings to Access Cisco Secure Awareness Cloud Service 357
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xvii
Contents
Creating Sender Group to Allow Simulated Phishing Messages in Email Gateway 358
Obtaining Authentication Token from Cisco Secure Awareness Cloud Service 359
Enabling Cisco Secure Awareness Cloud Service on Email Gateway 360
Create Custom Incoming Mail Policy for End Users Categorized as Repeat Clickers 360
Cisco Secure Awareness Cloud Service and Clusters 361
Viewing Logs 361
Viewing Alerts 363
CHAPTER 17 Anti-Virus 365
Anti-Virus Scanning Overview 365
Evaluation Key 366
Scanning Messages with Multiple Anti-Virus Scanning Engines 366
Sophos Anti-Virus Filtering 366
Virus Detection Engine 367
Virus Scanning 367
Detection Methods 367
Pattern Matching 367
Heuristics 368
Emulation 368
Virus Descriptions 368
Sophos Alerts 368
When a Virus is Found 368
McAfee Anti-Virus Filtering 369
Pattern-Matching Virus Signatures 369
Encrypted Polymorphic Virus Detection 369
Heuristics Analysis 369
When a Virus is Found 370
How to Configure the Email Gateway to Scan for Viruses 370
Enabling Virus Scanning and Configuring Global Settings 371
Configuring Virus Scanning Actions for Users 371
Message Scanning Settings 372
Message Handling Settings 372
Configuring Settings for Message Handling Actions 373
Configuring the Anti-Virus Policies for Different Groups of Senders and Recipients 376
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xviii
Contents
Notes on Anti-Virus Configurations 377
Flow Diagram for Anti-Virus Actions 378
Sending an Email to the Email Gateway to Test Anti-Virus Scanning 379
Updating Virus Definitions 381
About Retrieving Anti-Virus Updates via HTTP 381
Configuring Update Server Settings 381
Monitoring and Manually Checking for Anti-Virus Updates 381
Manually Updating Anti-Virus Engines 381
Verifying Anti-Virus Files Have Updated on the Email Gateway 382
CHAPTER 18 Managing Spam and Graymail 383
Overview of Anti-Spam Scanning 383
Anti-Spam Solutions 384
How to Configure the Email Gateway to Scan Messages for Spam 384
IronPort Anti-Spam Filtering 386
Evaluation Key 386
Cisco Anti-Spam: an Overview 386
Configuring IronPort Anti-Spam Scanning 387
Configuring Intelligent Multi-Scan and Graymail Detection 388
Configuring Cisco Intelligent Multi-Scan 388
Managing Graymail 389
Overview of Graymail 390
Graymail Management Solution in Email Gateway 390
How Graymail Management Solution Works 391
Configuring Graymail Detection and Safe Unsubscribing 393
Troubleshooting Graymail Detection and Safe Unsubscribing 398
Configuring Global Settings for Intelligent Multi-Scan and Graymail Detection 398
Defining Anti-Spam Policies 399
Understanding Positive and Suspect Spam Thresholds 401
Configuration Examples: Actions for Positively Identified versus Suspected Spam 402
Unwanted Marketing Messages From Legitimate Sources 402
Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy:
Configuration Example 403
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xix
Contents
Enabling Different Anti-Spam Scanning Engines in Different Mail Policies: Configuration Example
404
Protecting Email Gateway-Generated Messages From the Spam Filter 405
Headers Added During Anti-Spam Scanning 406
Reporting Incorrectly Classified Messages to Cisco 406
How to Report Incorrectly Classified Messages to Cisco 406
How to Report Incorrectly Classified Messages to Cisco 408
Using Cisco Email Security Plug-In 409
Forwarding Incorrectly Classified Message as an Attachment 409
How to Track Your Submissions 411
Determining Sender IP Address In Deployments with Incoming Relays 411
Example Environments with Incoming Relays 412
Configuring the Email Gateway to Work with Incoming Relays 413
Enabling the Incoming Relays Feature 413
Adding an Incoming Relay 414
Message Headers for Relayed Messages 415
How Incoming Relays Affect Functionality 418
Incoming Relays and Filters 418
Incoming Relays, HAT, IP Reputation Score, and Sender Groups 419
Incoming Relays and Directory Harvest Attack Prevention 419
Incoming Relays and Trace 419
Incoming Relays and Email Security Monitor (Reporting) 419
Incoming Relays and Message Tracking 419
Incoming Relays and Logging 419
Configuring Logs to Specify Which Headers Are Used 420
Monitoring Rules Updates 420
Testing Anti-Spam 421
Sending an Email to the Email Gateway to Test Cisco Anti-Spam 422
Testing Anti-Spam Configuration: Example Using SMTP 422
Ways Not to Test Anti-Spam Efficacy 423
CHAPTER 19 Outbreak Filters 425
Overview of Outbreak Filters 425
How Outbreak Filters Work 425
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xx
Contents
Delaying, Redirecting, and Modifying Messages 426
Threat Categories 426
Virus Outbreaks 427
Phishing, Malware Distribution, and Other Non-Viral Threats 427
Cisco Security Intelligence Operations 427
Context Adaptive Scanning Engine 428
Delaying Messages 428
Redirecting URLs 429
Modifying Messages 430
Types of Rules: Adaptive and Outbreak 430
Outbreak Rules 430
Adaptive Rules 430
Outbreaks 431
Threat Levels 431
Guidelines for Setting Your Quarantine Threat Level Threshold 431
Containers: Specific and Always Rules 432
How the Outbreak Filters Feature Works 432
Message Scoring 433
Dynamic Quarantine 433
Outbreak Lifecycle and Rules Publishing 434
Managing Outbreak Filters 435
Configuring Outbreak Filters Global Settings 436
Enabling the Outbreak Filters Feature 437
Enabling Adaptive Rules 437
Enabling Alerts for Outbreak Filters 437
Enabling Logging of URLs and Message Tracking Details for URLs 437
Outbreak Filters Rules 438
Managing Outbreak Filter Rules 439
The Outbreak Filters Feature and Mail Policies 439
Setting a Quarantine Level Threshold 440
Maximum Quarantine Retention 440
Bypassing File Extension Types 440
Message Modification 441
The Outbreak Filters Feature and the Outbreak Quarantine 443
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxi
Contents
Monitoring the Outbreak Quarantine 444
Outbreak Quarantine and the Manage by Rule Summary View 444
Monitoring Outbreak Filters 445
Outbreak Filters Report 446
Outbreak Filters Overview and Rules Listing 446
Outbreak Quarantine 446
Alerts, SNMP Traps, and Outbreak Filters 446
Troubleshooting The Outbreak Filters Feature 446
Reporting Incorrectly Classified Messages to Cisco 447
Multiple Attachments and Bypassed Filetypes 447
Message and Content Filters and the Email Pipeline 447
CHAPTER 20 Protecting Against Malicious or Undesirable URLs 449
URL-Related Protections and Controls 449
Which URLs Are Evaluated 450
Setting Up URL Filtering 450
Requirements for URL Filtering 450
Enable URL Filtering 451
About the Connection to Talos Intelligence Services 452
Certificates for URL Filtering Features 452
Web Interaction Tracking 452
Configuring Web Interaction Tracking 453
About the Connection to Cisco Aggregator Server 453
URL Filtering in Cluster Configurations 453
Creating Allowed Lists for URL Filtering 453
Importing a URL List 454
Customizing the Notification That End Users See If a Site Is Malicious 455
Taking Action Based on the Reputation or Category of URLs in Messages 456
Using URL-Related Conditions (Rules) and Actions 456
Filtering by URL Reputation or URL Category: Conditions and Rules 457
Modifying URLs in Messages: Using URL Reputation and URL Category Actions in Filters 458
Redirected URLs: What Does the End User Experience? 459
Handling Unscannable Messages for URL Filtering 460
Detecting Malicious URLs in Messages Using Content Filter 460
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxii
Contents
Detecting Malicious URLs in Messages Using Message Filter 462
Monitoring URL Filtering Results 463
Displaying URL Details in Message Tracking 463
Troubleshooting URL Filtering 463
Viewing Logs 464
Alert: Beaker Connector: Error Fetching Enrollment Certificate 464
Alert: Beaker Connector: Certificate Is Invalid 464
Unable to Connect to Talos Intelligence Services 465
Alert: Unable to Connect to the Cisco Aggregator Server 465
Alert: Unable to Retrieve Web Interaction Tracking Information from the Cisco Aggregator Server
465
Using the websecurityadvancedconfig Command 466
Message Tracking Search Does Not Find Messages with Specified Category 466
Malicious URLs and Marketing Messages Are Not Caught by Anti-Spam or Outbreak Filters 466
URLs in a Filtered Category Are Not Handled Correctly 466
End User Reaches Malicious Site via Rewritten URL 467
Manually Configuring a Certificate for Communication with Talos Intelligence Services 467
About URL Categories 467
URL Category Descriptions 468
Determining the Category of a URL 480
Reporting Uncategorized and Misclassified URLs 480
Future URL Category Set Changes 480
CHAPTER 21 File Reputation Filtering and File Analysis 481
Overview of File Reputation Filtering and File Analysis 481
File Threat Verdict Updates 481
File Processing Overview 482
Supported Files for File Reputation and Analysis Services 483
Archive or Compressed File Processing 484
Privacy of Information Sent to the Cloud 485
Configuring File Reputation and Analysis Features 485
Requirements for Communication with File Reputation and Analysis Services 485
Configuring an On-premises File Reputation Server 486
Configuring an On-Premises File Analysis Server 486
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxiii
Contents
Enabling and Configuring File Reputation and Analysis Services 487
Integrating the Appliance with AMP for Endpoints Console 491
Important! Changes Needed in File Analysis Setting 493
(Public Cloud File Analysis Services Only) Configuring Appliance Groups 494
Which Appliances Are In the Analysis Group? 494
Configuring the Mail Policy for File Reputation Scanning and File Analysis 495
Quarantining Messages with Attachments Sent for Analysis 497
Using the File Analysis Quarantine 498
Edit File Analysis Quarantine Settings 499
Manually Processing Messages in the File Analysis Quarantine 500
Centralized File Analysis Quarantine 500
X-Headers for File Reputation and Analysis 500
Sending Notifications to End Users about Dropped Messages or Attachments 501
Advanced Malware Protection and Clusters 501
Ensuring That You Receive Alerts About Advanced Malware Protection Issues 501
Configuring Centralized Reporting for Advanced Malware Protection Features 502
File Reputation and File Analysis Reporting and Tracking 502
Identifying Files by SHA-256 Hash 502
File Reputation and File Analysis Report Pages 503
Viewing File Reputation Filtering Data in Other Reports 504
About Message Tracking and Advanced Malware Protection Features 504
Taking Action When File Threat Verdicts Change 505
Troubleshooting File Reputation and Analysis 505
Log Files 505
Using Trace 506
Several Alerts About Failure to Connect to File Reputation or File Analysis Servers 506
API Key Error (On-Premises File Analysis) 506
Files are Not Uploaded As Expected 507
Alerts about File Types That Can Be Sent for Analysis 507
CHAPTER 22 Data Loss Prevention 509
Overview of Data Loss Prevention 509
Overview of the DLP Scanning Process 509
How Data Loss Prevention Works 510
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxiv
Contents
System Requirements for Data Loss Prevention 511
How to Set Up Data Loss Prevention 511
Enabling Data Loss Prevention (DLP) 512
Policies for Data Loss Prevention 512
DLP Policy Description 513
Predefined DLP Policy Templates 513
Setting Up DLP Prevention Using a Wizard 513
Creating a DLP Policy Using a Predefined Template 515
Creating a Custom DLP Policy (Advanced) 516
About Defining Disallowed Content Using Content Matching Classifiers 517
Content Matching Classifier Examples 518
Creating a Content Matching Classifier for Custom DLP Policies 519
Classifier Detection Rules for Identifying Sensitive Content (Custom DLP Policies Only) 520
Regular Expressions for Identifying Identification Numbers 521
Using Custom Dictionaries of Sensitive DLP Terms (Custom DLP Policies Only) 522
Determiners of the Risk Factor of a Suspected Violation 524
Using Minimum Score for Entity-based Rules (Custom DLP Policies Only) 526
Viewing the Policies in Which Custom Content Classifiers are Used 527
Filtering Messages for DLP Policies 527
About Assessing Violation Severity 528
Adjusting the Severity Scale 528
Arranging the Order of the Email DLP Policies for Violation Matching 529
Associating DLP Policies with Outgoing Mail Policies 529
Associating DLP Policies with the Default Outgoing Mail Policy 529
Using Outgoing Mail Policies to Assign DLP Policies to Senders and Recipients 529
Important Information About Editing or Deleting DLP Policies 530
Message Actions 530
Defining Actions to Take for DLP Violations (Message Actions) 531
Viewing and Editing Message Actions 532
Drafting DLP Notifications 533
DLP Notification Template Variable Definitions 534
Displaying Sensitive DLP Data in Message Tracking 535
About Updating the DLP Engine and Content Matching Classifiers 536
Determining the Current Version of the DLP Engine 536
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxv
Contents
Updating the DLP Engine and Content Matching Classifiers Manually 536
Enabling Automatic Updates (Not Recommended) 537
DLP Updates on Centralized (Clustered) Email Gateways 537
Working with DLP Incident Messages and Data 537
Troubleshooting Data Loss Prevention 538
DLP Fails to Detect Violations in Email Attachments 538
CHAPTER 23 Cisco Email Encryption 539
Overview of Cisco Email Encryption 539
How to Encrypt Messages with a Local Key Server 540
Encryption Workflow 540
Encrypting Messages using the Email Gateway 541
Enabling Message Encryption on the Email Gateway 542
Configuring How a Key Service Handles Encrypted Messages 542
Configuring the Default Locale of the Envelope 545
Updating to the Latest Version of the PXE Engine 546
Determining Which Messages to Encrypt 546
Using a TLS Connection as an Alternative to Encryption 546
Encrypting and Immediately Delivering Messages using a Content Filter 547
Encrypting a Message upon Delivery using a Content Filter 548
Inserting Encryption Headers into Messages 549
Encryption Headers 550
Encryption Headers Examples 551
Enabling Envelope Key Caching for Offline Opening 552
Enabling JavaScript-Free Envelopes 552
Enabling Message Expiration 552
Disabling the Decryption Applet 552
CHAPTER 24 S/MIME Security Services 553
Overview of S/MIME Security Services 553
S/MIME Security Services in Email Gateway 553
Understanding How S/MIME Security Services Works 554
Scenario: Business-to-Business 554
Scenario: Business-to-Consumer 556
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxvi
Contents
Signing, Encrypting, or Signing and Encrypting Outgoing Messages using S/MIME 557
S/MIME Signing and Encryption Workflow in Email Gateway 557
S/MIME Signing Workflow 557
S/MIME Encryption Workflow 557
How to Sign, Encrypt, or Sign and Encrypt Outgoing Messages using S/MIME 558
Setting Up Certificates for S/MIME Signing 559
Creating a Self-Signed S/MIME Certificate 559
Importing an S/MIME Signing Certificate 560
Setting Up Public Keys for S/MIME Encryption 561
Adding a Public Key for S/MIME Encryption 561
S/MIME Harvested Public Keys 562
Harvesting Public Keys 562
Managing S/MIME Sending Profiles 563
Create an S/MIME Sending Profile for Signing, Encrypting, or Signing and Encrypting Messages
564
Edit an S/MIME Sending Profile 565
Determining Which Messages to Sign, Encrypt, or Sign and Encrypt 565
Signing, Encrypting, or Signing and Encrypting and Immediately Delivering Messages using a
Content Filter 566
Signing, Encrypting, or Signing and Encrypting a Message upon Delivery using a Content Filter
566
Verifying, Decrypting, or Decrypting and Verifying Incoming Messages using S/MIME 567
S/MIME Verification and Decryption Workflow in Email Gateway 567
S/MIME Verification Workflow 568
S/MIME Decryption Workflow 568
How to Verify, Decrypt, or Decrypt and Verify Incoming Messages Using S/MIME 568
Setting Up Certificates for Decrypting Messages 569
Setting Up Public Keys for Verifying Signed Messages 570
Adding a Public Key for S/MIME Verification 570
Harvesting Public Keys for S/MIME Verification 570
Enabling Public Key Harvesting 571
Adding a Harvested Public Key for S/MIME Verification 571
Enabling S/MIME Decryption and Verification 572
Configuring an Action for S/MIME Decrypted or Verified Message 572
S/MIME Certificate Requirements 573
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxvii
Contents
Certificate Requirements for Signing 573
Certificate Requirements for Encryption 574
Managing Public Keys 574
Adding a Public Key 575
Importing Public Keys from an Existing Export File 575
Exporting Public Keys 576
CHAPTER 25 Remediating Messages in Mailboxes 577
Overview 577
Workflow 578
How the Email Gateway Performs Auto-Remedial Actions 579
Performing Remedial Actions on Messages in Mailboxes 580
Performing Remedial Actions on Messages in Microsoft Exchange Online Mailboxes 581
How to Configure Remedial Action on Messages in Microsoft Exchange Online Mailboxes 581
Performing Remedial Actions on Messages in Microsoft Exchange On-Premise Mailboxes 583
How to Configure Remedial Actions on Messages in Microsoft Exchange On-Premise Mailboxes
583
Performing Remedial Actions on Messages in Mailboxes on Hybrid Deployment 584
How to Perform Remedial Actions on Messages in Mailboxes on Hybrid Deployment 584
Configuring Mailbox Remediation on Email Gateway 586
Prerequisites 586
Prerequisites for Remediating Messages in Microsoft Exchange Online Mailboxes 586
Prerequisites for Remediating Messages in an On-Premise Account 587
Registering Your Email Gateway as an Application on Azure AD 588
Enabling Account Settings on Email Gateway 590
Creating an Account Profile 591
Creating a Chained Profile 592
Mapping Domains to the Account Profile 593
Configure Auto-Remedial Actions on Messages in the Mailboxes 594
Search and Remediate Messages in the Mailboxes 594
Upgrading to AsyncOS 13.0 and Later Releases 596
Monitoring Mailbox Remediation Results 596
Viewing Mailbox Remediation Details in Message Tracking 596
Troubleshooting Mailbox Remediation 596
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxviii
Contents
Connection Errors 597
Viewing Logs 598
Alerts 599
Configured Remedial Actions Are Not Performed 599
CHAPTER 26 Email Authentication 601
Email Authentication Overview 601
DomainKeys and DKIM Authentication 601
DomainKeys and DKIM Authentication Workflow 602
DomainKeys and DKIM Signing in AsyncOS 602
Configuring DomainKeys and DKIM Signing 603
Signing Keys 604
Exporting and Importing Signing Keys 604
Public Keys 604
Domain Profiles 605
Exporting and Importing Domain Profiles 606
Enabling Signing for Outgoing Mail 606
Enabling Signing for Bounce and Delay Messages 606
Configuring DomainKeys/DKIM Signing (GUI) 607
Creating Domain Profiles for DomainKeys Signing 608
Creating a New Domain Profile for DKIM Signing 608
Creating or Editing a Signing Key 610
Exporting Signing Keys 611
Importing or Entering Existing Signing Keys 611
Deleting Signing Keys 612
Generating a DNS Text Record 613
Testing Domain Profiles 613
Exporting Domain Profiles 614
Importing Domain Profiles 614
Deleting Domain Profiles 614
Searching Domain Profiles 615
Editing DKIM Global Settings 615
Domain Keys and Logging 616
How to Verify Incoming Messages Using DKIM 616
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxix
Contents
DKIM Verification Checks Performed by AsyncOS 617
Managing DKIM Verification Profiles 617
Creating a DKIM Verification Profile 618
Exporting DKIM Verification Profiles 619
Importing DKIM Verification Profiles 619
Deleting DKIM Verification Profiles 619
Searching DKIM Verification Profiles 620
Configuring DKIM Verification on the Mail Flow Policy 620
DKIM Verification and Logging 621
Configuring an Action for DKIM Verified Mail 621
Overview of SPF and SIDF Verification 622
A Note About Valid SPF Records 622
Valid SPF Records 623
Valid SIDF Records 623
Testing Your SPF Records 623
How to Verify Incoming Messages Using SPF/SIDF 623
Enabling SPF and SIDF 624
Enabling SPF and SIDF via the CLI 625
The Received-SPF Header 627
Determining the Action to Take for SPF/SIDF Verified Mail 628
Verification Results 629
Using the spf-status Filter Rule in the CLI 629
spf-status Content Filter Rule in the GUI 630
Using the spf-passed Filter Rule 631
Testing the SPF/SIDF Results 631
Basic Granularity Test of SPF/SIDF Results 631
Greater Granularity Test of SPF/SIDF Results 632
DMARC Verification 632
DMARC Verification Workflow 633
How to Verify Incoming Messages Using DMARC 633
Managing DMARC Verification Profiles 634
Configure Global DMARC Settings 637
Configuring DMARC Verification on the Mail Flow Policy 638
Configure a Return Address for DMARC Feedback Reports 638
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxx
Contents
DMARC Aggregate Reports 639
Forged Email Detection 640
Setting Up Forged Email Detection 640
Monitoring Forged Email Detection Results 641
Displaying Forged Email Detection Details in Message Tracking 642
CHAPTER 27 Text Resources 643
Overview of Text Resources 643
Content Dictionaries 643
Text Resources 644
Message Disclaimer Stamping 644
Content Dictionaries 644
Dictionary Content 645
Word Boundaries and Double-byte Character Sets 646
Importing and Exporting Dictionaries as Text Files 646
Adding Dictionaries 647
Deleting Dictionaries 648
Importing Dictionaries 648
Exporting Dictionaries 649
Using and Testing the Content Dictionaries Filter Rules 649
Dictionary Match Filter Rule 649
Example Dictionary Entries 650
Testing Content Dictionaries 650
Understanding Text Resources 651
Importing and Exporting Text Resources as Text Files 651
Overview of Text Resource Management 652
Adding Text Resources 652
Deleting Text Resources 652
Importing Text Resources 653
Exporting Text Resources 653
Overview of HTML-Based Text Resources 654
Importing and Exporting HTML-Based Text Resources 654
Using Text Resources 655
Disclaimer Template 655
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxi
Contents
Adding Disclaimer Text via a Listener 656
Adding Disclaimers via Filters 656
Disclaimers and Filter Action Variables 656
Disclaimer Stamping and Multiple Encodings 658
Notification Templates 660
Anti-Virus Notification Templates 661
Custom Anti-Virus Notification Templates 661
Bounce and Encryption Failure Notification Templates 663
Bounce and Encryption Failure Notification Variables 664
Encryption Notification Templates 664
CHAPTER 28 Validating Recipients Using an SMTP Server 667
Overview of SMTP Call-Ahead Recipient Validation 667
SMTP Call-Ahead Recipient Validation Workflow 667
How to Validate Recipients Using an External SMTP Server 669
Configuring the Call-Ahead Server Profile 669
SMTP Call-Ahead Server Profile Settings 670
Call Ahead Server Responses 671
Enabling a Listener to Validate Incoming Mail Via the SMTP Server 672
Configuring LDAP Routing Query Settings 672
SMTP Call-Ahead Query Routing 673
Bypassing SMTP Call-Ahead Validation for Certain Users or Groups 674
CHAPTER 29 Encrypting Communication with Other MTAs 675
Overview of Encrypting Communication with Other MTAs 675
How to Encrypt SMTP Conversations using TLS 675
Working with Certificates 676
Deploying a Signed Certificate 677
Deploying Self-Signed Certificates 677
Certificates and Centralized Management 678
Intermediate Certificates 678
Creating a Self-Signed Certificate 678
About Sending a Certificate Signing Request (CSR) to a Certificate Authority 679
Uploading a Certificate Signed by a Certificate Authority 680
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxii
Contents
Importing a Certificate 680
Exporting a Certificate 681
Enabling TLS on a Listener’s HAT 681
Assigning a Certificate to a Public or Private Listener for TLS Connections Using the GUI 682
Assigning a Certificate to a Public or Private Listener for TLS Connections Using the CLI 683
Logging 683
GUI Example: Changing the TLS setting for Listeners HAT 683
CLI Example: Changing the TLS Setting for Listeners HAT 683
Enabling TLS and Certificate Verification on Delivery 684
Sending Alerts When a Required TLS Connection Fails 686
Enabling TLS Connection Alerts 687
Logging 687
DNS-based Authentication of Named Entities 687
Overview of SMTP DNS-based Authentication of Named Entities 688
SMTP DANE Workflow 688
Creating TLSA Record 689
Enabling TLS for Delivery with DANE Support 690
Sending Alerts When DANE Fails 691
Enabling DANE Alerts 691
Managing Lists of Certificate Authorities 691
Viewing the Pre-Installed list of Certificate Authorities 692
Disabling the System Certificate Authority List 692
Importing a Custom Certificate Authority List 693
Exporting a Certificate Authorities List 693
Certificate Updates 694
Managing Trusted Root Certificates 694
Enabling a Certificate for HTTPS 694
CHAPTER 30 Configuring Routing and Delivery Features 697
Routing Email for Local Domains 697
SMTP Routes Overview 698
Default SMTP Route 698
Defining an SMTP Route 699
SMTP Routes Limits 699
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxiii
Contents
SMTP Routes and DNS 699
SMTP Routes and Alerts 700
SMTP Routes, Mail Delivery, and Message Splintering 700
SMTP Routes and Outbound SMTP Authentication 700
Managing SMTP Routes to Send Outbound Email Using the GUI 700
Adding SMTP Routes 700
Exporting SMTP Routes 701
Importing SMTP Routes 701
Rewriting Addresses 702
Creating Alias Tables 703
Configuring an Alias Table from the Command Line 703
Exporting and Importing an Alias Table 704
Deleting Entries from the Alias Table 705
Example Alias Table 705
Example aliasconfig Command 707
Configuring Masquerading 710
Masquerading and altsrchost 711
Configuring Static Masquerading Tables 711
Sample Masquerading Table for a Private Listener 712
Importing a Masquerading Table 713
Example Masquerading 713
The Domain Map Feature 720
Importing and Exporting a Domain Map Table 725
Directing Bounced Email 726
Handling Undeliverable Email 727
Notes on Soft and Hard Bounces 727
Bounce Profile Parameters 728
Hard Bounces and the status Command 731
Conversational Bounces and SMTP Routes Message Filter actions 731
Example Bounce Profiles 731
Delivery Status Notification Format 732
Delay Warning Messages 732
Delay Warning Messages and Hard Bounces 732
Creating a New Bounce Profile 733
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxiv
Contents
Editing the Default Bounce Profile 733
Example of a Minimalist Bounce Profile 733
Applying Bounce Profiles to Listeners 733
Controlling Email Delivery Using Destination Controls 734
Rate Limiting 735
TLS 735
Bounce Verification 735
Bounce Profile 735
Determining Which Interface is Used for Mail Delivery 735
Default Delivery Limits 736
Working with Destination Controls 736
Controlling the Version of Internet Protocol Addresses 736
Controlling the Number of Connections, Messages, and Recipients to a Domain 736
Controlling TLS 738
Controlling Bounce Verification Tagging 738
Controlling Bounces 738
Adding a New Destination Control Entry 738
Importing and Exporting Destination Control Configurations 739
Destination Controls and the CLI 742
Bounce Verification 742
Overview: Tagging and Bounce Verification 743
Handling Incoming Bounce Messages 743
Bounce Verification Address Tagging Keys 744
Accepting Legitimate Untagged Bounced Messages 744
Preventing a Bounced Message Storm Using Bounce Verification 744
Configuring Bounce Verification Address Tagging Keys 745
Configuring Bounce Verification Settings 745
Configuring Bounce Verification Using the CLI 746
Bounce Verification and Cluster Configuration 746
Set Email Delivery Parameters 746
Default Delivery IP Interface 746
Possible Delivery Feature 747
Default Maximum Concurrency 747
deliveryconfig Example 747
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxv
Contents
Configuring Mail Gateways for all Hosted Domains Using Virtual Gateway™ Technology 749
Overview 749
Setting Up Virtual Gateway Addresses 749
Creating New IP Interfaces for Use with Virtual Gateways 750
Mapping Messages to IP Interfaces for Delivery 752
Importing an altsrchost File 753
altsrchost Limits 754
Example Text File with Valid Mappings for the altsrchost Command 754
Adding an altsrchost Mapping through the CLI 754
Monitoring the Virtual Gateway Addresses 756
Managing Delivery Connections per Virtual Gateway Address 757
Using Global Unsubscribe 757
Adding a Global Unsubscribe Address Using The CLI 758
Exporting and Importing a Global Unsubscribe File 760
Review: Email Pipeline 760
CHAPTER 31 Integrating the Email Gateway with Cisco Advanced Phishing Protection 765
Overview of Cisco Advanced Phishing Protection 765
Benefits of Cisco Advanced Phishing Protection 766
Workflow 766
How to Integrate Email Gateway with the Cisco Advanced Phishing Protection Cloud Service 766
Prerequisites 767
Activating the Account for Cisco Advanced Phishing Protection Cloud Service 767
Installing Sensors on the Cisco Advanced Phishing Protection Cloud Service 767
Obtaining the Provisioning Key from the Cisco Advanced Phishing Protection Cloud Service 768
Registering the Cisco Advanced Phishing Protection Sensor on the Email Gateway 768
Enabling Advanced Phishing Protection on the Email Gateway 769
Obtaining API Access Keys from Cisco Advanced Phishing Protection Cloud Service 770
Configuring Incoming Mail Policies to Enable Forwarding of Message Metadata 771
Monitoring Message Metadata on the Cisco Advanced Phishing Protection Cloud Service 772
Advanced Phishing Protection and Clusters 773
Advanced Phishing Protection Report Page 773
Monitoring Message Metadata on the Cisco Advanced Phishing Protection Cloud Service 774
Displaying Messages Submitted to the Cisco Advanced Phishing Protection Cloud Service 774
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxvi
Contents
CHAPTER 32 LDAP Queries 775
Overview of LDAP Queries 775
Understanding LDAP Queries 776
Understanding How LDAP Works with AsyncOS 777
Configuring the Email Gateway to Work with an LDAP Server 778
Creating LDAP Server Profiles to Store Information About the LDAP Server 778
Testing LDAP Servers 780
Enabling LDAP Queries to Run on a Particular Listener 780
Configuring Global Settings for LDAP Queries 781
Example of Creating an LDAP Server Profile 781
Enabling LDAP Queries on a Public Listener 782
Enabling LDAP Queries on a Private Listener 783
Enhanced Support for Microsoft Exchange 5.5 783
Working with LDAP Queries 785
Types of LDAP Queries 785
Base Distinguishing Name (DN) 786
LDAP Query Syntax 786
Tokens: 786
Secure LDAP (SSL) 787
Routing Queries 787
Allowing Clients to Bind to the LDAP Server Anonymously 787
Anonymous Authentication Setup 788
Anonymous Bind Setup for Active Directory 789
Notes for Active Directory Implementations 790
Testing LDAP Queries 790
Troubleshooting Connections to LDAP Servers 791
Using Acceptance Queries For Recipient Validation 792
Sample Acceptance Queries 792
Configuring Acceptance Queries for Lotus Notes 793
Using Routing Queries to Send Mail to Multiple Target Addresses 793
Sample Routing Queries 793
Routing: MAILHOST and MAILROUTINGADDRESS 794
Using Masquerading Queries to Rewrite the Envelope Sender 794
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxvii
Contents
Sample Masquerading Queries 795
Masquerading “Friendly Names” 795
Using Group LDAP Queries to Determine if a Recipient is a Group Member 796
Sample Group Queries 796
Configuring a Group Query 797
Example: Using a Group Query to Skip Spam and Virus Checking 798
Using Domain-based Queries to Route to a Particular Domain 799
Creating a Domain-Based Query 800
Using Chain Queries to Perform a Series of LDAP Queries 801
Creating a Chain Query 801
Using LDAP For Directory Harvest Attack Prevention 802
Directory Harvest Attack Prevention within the SMTP Conversation 802
Directory Harvest Attack Prevention within the Work Queue 803
Configuring Directory Harvest Prevention in the Work Queue 804
Configuring AsyncOS for SMTP Authentication 804
Configuring SMTP Authentication 805
Specifying a Passphrase as Attribute 805
Configuring an SMTP Authentication Query 806
SMTP Authentication via Second SMTP Server (SMTP Auth with Forwarding) 807
SMTP Authentication with LDAP 807
Enabling SMTP Authentication on a Listener 808
Authenticating SMTP Sessions Using Client Certificates 811
Outgoing SMTP Authentication 811
Logging and SMTP Authentication 812
Configuring External LDAP Authentication for Users 812
User Accounts Query 813
Group Membership Queries 813
Authenticating End-Users of the Spam Quarantine 815
Sample Active Directory End-User Authentication Settings 815
Sample OpenLDAP End-User Authentication Settings 816
Spam Quarantine Alias Consolidation Queries 816
Sample Active Directory Alias Consolidation Settings 817
Sample OpenLDAP Alias Consolidation Settings 817
Sample User Distinguished Name Settings 818
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxviii
Contents
Configuring AsyncOS To Work With Multiple LDAP Servers 818
Testing Servers and Queries 819
Failover 819
Configuring the Email Gateway for LDAP Failover 819
Load Balancing 820
Configuring the Email Gateway for Load Balancing 820
CHAPTER 33 Authenticating SMTP Sessions Using Client Certificates 823
Overview of Certificates and SMTP Authentication 823
How to Authenticate a User with a Client Certificate 824
How to Authenticate a User with an SMTP Authentication LDAP Query 824
How to Authenticate a User with an LDAP SMTP Authentication Query if the Client Certificate is
Invalid 825
Checking the Validity of a Client Certificate 825
Authenticating a User Using an LDAP Directory 826
Authenticating an SMTP Connection Over TLS Using a Client Certificate 827
Establishing a TLS Connection from the Email Gateway 827
Updating a List of Revoked Certificates 828
Authenticating a User’s SMTP Session With a Client Certificate 829
Authenticating a User’s SMTP Session with the SMTP AUTH Command 829
Authenticating a User’s SMTP Session with Either a Client Certificate or SMTP AUTH 830
CHAPTER 34 Using Email Security Monitor 833
Email Security Monitor Overview 833
Email Security Monitor and Centralized Management 834
Email Security Monitor Pages 834
Searching and Email Security Monitor 836
Viewing Details of Messages Included in Reports 836
My Dashboard Page 837
Overview Page 838
System Overview 838
Incoming and Outgoing Summary and Graph 839
Categorizing Email 840
How Messages are Categorized 841
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xxxix
Contents
Incoming Mail Page 841
Incoming Mail 842
Incoming Mail Details Listing 843
Reporting Pages Populated with Data: Sender Profile Pages 845
Sender Groups Report 846
Sender Domain Reputation Page 846
Outgoing Destinations 847
Outgoing Senders 847
Geo Distribution Page 848
Delivery Status Page 848
Retrying Delivery 849
Delivery Status Details Page 849
Internal Users Page 849
Internal User Details 850
Searching for a Specific Internal User 850
DLP Incidents Page 850
DLP Incidents Details 851
DLP Policy Detail Page 851
Content Filters Page 851
Content Filter Details 852
DMARC Verification Page 852
Macro Detection Page 852
External Threat Feeds Page 853
Outbreak Filters Page 853
Virus Types Page 855
URL Filtering Page 855
Web Interaction Tracking Page 856
Forged Email Matches Report 857
File Reputation and File Analysis Reports 857
Mailbox Auto Remediation Report 857
TLS Connections Page 857
Inbound SMTP Authentication Page 858
Rate Limits Page 859
System Capacity Page 859
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xl
Contents
System Capacity- Workqueue 860
System Capacity- Incoming Mail 861
System Capacity-Outgoing Mail 861
System Capacity-System Load 861
Note about Memory Page Swapping 862
System Capacity- All 862
System Status Page 862
System Status 863
Gauges 863
Rates 863
Counters 864
High Volume Mail Page 864
Message Filters Page 864
Safe Print Page 865
Retrieving CSV Data 865
Retrieving CSV Data Via Automated Processes 865
Email Security Monitor Pages on the New Web Interface 867
Searching and the Interactive Email Report Pages 869
Viewing Details of Messages Included in Reports 869
Time Range for Reports 870
My Favorite Reports Page 870
Modules That Cannot Be Added to the My Reports Page 871
Adding Reports on the My Favorite Reports Page 872
Mail Flow Summary Page 872
How Email Messages Are Categorized by the Email Gateways 875
Incoming and Outgoing Summary and Graph 875
Categorizing Email Messages on the Mail Flow Summary Page 876
Using Counters to Filter Data on the Trend Graphs 878
System Capacity Page 878
System Capacity- Workqueue 879
System Capacity- Incoming Mail 879
System Capacity-Outgoing Mail 879
System Capacity-System Load 880
Note about Memory Page Swapping 880
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xli
Contents
System Capacity- All 881
Reporting Data Availability 881
Advanced Malware Protection Page 881
Advanced Malware Protection – Summary 882
Advanced Malware Protection – AMP Reputation 882
Advanced Malware Protection – File Analysis 883
Advanced Malware Protection – File Retrospection 884
Advanced Malware Protection – Mailbox Auto Remediation 884
Identifying Files by SHA-256 Hash 885
Viewing File Reputation Filtering Data in Other Reports 885
Virus Filtering Page 885
Macro Detection Page 886
DMARC Verification Page 886
URL Filtering Page 887
Outbreak Filtering Page 887
Forged Email Detection Page 889
Sender Domain Reputation Page 889
External Threat Feeds Page 890
Mail Flow Details Page 890
Views Within the Mail Flow Details Page 891
Incoming Mails Table 893
Sender Profile Pages 896
Sender Details Table 897
Sender Groups Report 898
Outgoing Destinations 898
TLS Encryption Page 898
Inbound SMTP Authentication Page 899
Rate Limits Page 900
Connections by Country Page 900
User Mail Summary Page 901
User Mail Flow Details 901
Searching for a Specific Internal User 902
DLP Incident Summary Page 902
DLP Incident Details 903
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xlii
Contents
DLP Policy Detail Page 903
Web Interaction Page 903
Remediation Report Page 904
Message Filters Page 905
High Volume Mail Page 906
Content Filters Page 906
Content Filter Details 906
Safe Print Page 907
Advanced Phishing Protection Report Page 907
Mail Policy Details Report Page 907
Reporting Overview 908
Scheduled or Archived Report Types 908
Notes on Reports 909
Setting the Return Address for Reports 909
Managing Reports 909
Scheduled Reports 910
Scheduling a Report to be Generated Automatically 910
Editing Scheduled Reports 911
Deleting Scheduled Reports 911
Archived Reports 911
Generating On-Demand Reports 912
Troubleshooting Email Reports 912
Link to Message Tracking Gives Unexpected Results 912
File Analysis Details in the Cloud Are Incomplete 913
CHAPTER 35 Tracking Messages 915
Message Tracking Overview 915
Enabling Message Tracking 915
Searching for Messages on the Legacy Interface 916
Searching for Email Messages on the New Web Interface 919
Working with Message Tracking Search Results 921
Message Tracking Details 922
Checking Message Tracking Data Availability 924
About Message Tracking and Upgrades 925
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xliii
Contents
Troubleshooting Message Tracking 925
Attachments Do Not Appear in Search Results 925
Expected Messages Are Missing from Search Results 925
CHAPTER 36 Policy, Virus, and Outbreak Quarantines 927
Overview of Policy, Virus, and Outbreak Quarantines 927
Quarantine Types 928
Managing Policy, Virus, and Outbreak Quarantines 929
Disk Space Allocation for Policy, Virus, and Outbreak Quarantines 929
Retention Time for Messages in Quarantines 930
Default Actions for Automatically Processed Quarantined Messages 931
Checking the Settings of System-Created Quarantines 931
Configuring Policy, Virus, and Outbreak Quarantines 931
About Editing Policy, Virus, and Outbreak Quarantine Settings 933
Determining the Filters and Message Actions to Which a Policy Quarantine Is Assigned 933
About Deleting Policy Quarantines 934
Monitoring Quarantine Status, Capacity, and Activity 934
Policy Quarantine Performance 935
Alerts About Quarantine Disk-Space Usage 936
Policy Quarantines and Logging 936
About Distributing Message Processing Tasks to Other Users 936
Which User Groups Can Access Policy, Virus, and Outbreak Quarantines 936
About Policy, Virus, and Outbreak Quarantines in Cluster Configurations 937
About Centralized Policy, Virus, and Outbreak Quarantines 937
Working with Messages in Policy, Virus, or Outbreak Quarantines 937
Viewing Messages in Quarantines 938
Quarantined Messages and International Character Sets 938
Finding Messages in Policy, Virus, and Outbreak Quarantines 938
Manually Processing Messages in a Quarantine 939
Sending a Copy of the Message 940
About Moving Messages Between Policy Quarantines 940
Messages in Multiple Quarantines 941
Message Details and Viewing Message Content 941
Viewing Matched Content 942
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xliv
Contents
Downloading Attachments 943
Testing for Viruses 943
About Rescanning of Quarantined Messages 943
The Outbreak Quarantine 944
Rescanning Messages in an Outbreak Quarantine 944
Manage by Rule Summary Link 945
Reporting False Positives or Suspicious Messages to Cisco Systems 945
CHAPTER 37 Spam Quarantine 947
Overview of the Spam Quarantine 947
Local Versus External Spam Quarantine 947
Setting Up the Local Spam Quarantine 948
Enabling and Configuring the Spam Quarantine on the Legacy Web Interface 949
Configuring the IP Interface for Browser Access to the Spam Quarantine 950
Configuring Administrative User Access to the Spam Quarantine 951
Configuring a Mail Policy to Quarantine Spam 952
Limiting Which Recipients Have Mail Quarantined 952
Ensuring That Message Text Displays Correctly 952
Specifying a Default Encoding 952
Spam Quarantine Language 953
Using Safelists and Blocklists to Control Email Delivery Based on Sender 953
Message Processing of Safelists and Blocklists 953
Enabling Safelists and Blocklists on the Legacy Web Interface 954
External Spam Quarantine and Safelist/Blocklists 955
Adding Senders and Domains to Safelists and Blocklists (Administrators) 955
Syntax for Safelists and Blocklist Entries 959
Clearing All Safelists and Blocklists 960
About End-User Access to Safelists and Blocklists 960
Adding Entries to Safelists (End Users) 960
Adding Senders to Blocklists (End Users) 961
Synchronizing Safelists or Blocklists on Multiple Email Gateways (Deployments Without a Cisco
Secure Email and Web Manager) 962
Backing Up and Restoring the Safelist/Blocklist 962
Troubleshooting Safelists and Blocklists 963
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xlv
Contents
Message from Safelisted Sender Was Not Delivered 963
Configuring Spam Management Features for End Users 964
Authentication Options for End Users Accessing Spam Management Features 964
LDAP Authentication Process 965
IMAP/POP Authentication Process 965
Setting Up End-User Access to the Spam Quarantine via Web Browser 966
Configuring End-User Access to the Spam Quarantine 966
Determining the URL for End-User Access to the Spam Quarantine 967
Which Messages an End User Sees 968
Notifying End Users About Quarantined Messages 968
Recipient Email Mailing List Aliases and Spam Notifications 971
Testing Notifications 971
Troubleshooting Spam Notifications 971
Managing Messages in the Spam Quarantine 972
Accessing the Spam Quarantine (Administrative Users) 972
Searching for Messages in the Spam Quarantine 973
Searching Very Large Message Collections 973
Viewing Messages in the Spam Quarantine 973
Delivering Messages in the Spam Quarantine 974
Deleting Messages from the Spam Quarantine 974
Disk Space for the Spam Quarantine 974
About Disabling the External Spam Quarantine 975
Troubleshooting Spam Quarantine Features 975
CHAPTER 38 Distributing Administrative Tasks 977
Working with User Accounts 977
User Roles 978
Managing Users 979
Adding Users 980
Editing Users 980
Force Users To Change Their Passphrases 981
Deleting Users 981
Controlling Access to Sensitive Information in Message Tracking 981
Managing Custom User Roles for Delegated Administration 982
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xlvi
Contents
Account Privileges Page 983
Assigning Access Privileges 984
Mail Policies and Content Filters 984
DLP Policies 985
Email Reporting 986
Message Tracking 987
Trace 987
Quarantines 987
Encryption Profiles 987
Log Subscription 988
Defining a Custom User Role 988
Defining a Custom User Role When Adding a User Account 988
Updating Responsibilities for a Custom User Role 989
Editing a Custom User Role 989
Duplicating a Custom User Role 989
Deleting a Custom User Role 990
Passphrases 990
Changing Your Passphrase 990
Locking and Unlocking a User Account 991
Configuring Restrictive User Account and Passphrase Settings 991
External Authentication 992
Enabling LDAP Authentication 992
Enabling RADIUS Authentication 993
Enable SAML Authentication 995
Two-Factor Authentication 995
Enabling Two-Factor Authentication 996
Disabling Two-Factor Authentication 996
Configuring Access to the Email Gateway 997
Configuring IP-Based Network Access 997
Direct Connections 997
Connecting Through a Proxy 997
Important Precautions When Restricting Network Access 998
Creating the Access List 998
Configuring Session Timeouts 999
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xlvii
Contents
Configuring the Web UI Session Timeout 999
Configuring the CLI Session Timeout 1000
Displaying Messages to Administrative Users 1001
Displaying a Message Before Login 1001
Displaying a Message After Login 1001
Managing Secure Shell (SSH) Keys 1001
Example: Install a New Public Key 1002
Example: Edit SSH Server Configuration 1002
Remote SSH Command Execution 1003
Monitoring Administrative User Access 1004
CHAPTER 39 System Administration 1005
Management of the Email Gateway 1006
Shutting Down or Rebooting the Email Gateway 1006
Suspending Email Receiving and Delivery 1006
Resuming Suspended Email Receiving and Delivery 1007
Resetting to Factory Defaults 1007
Next Steps 1008
Displaying the Version Information for AsyncOS 1008
Email Gateway Licensing 1008
Feature Keys 1008
Adding and Managing Feature Keys 1008
Automating Feature Key Download and Activation 1009
Expired Feature Keys 1010
Smart Software Licensing 1010
Overview 1010
Enabling Smart Software Licensing 1012
Registering the Email Gateway with Cisco Smart Software Manager 1012
Requesting for Licenses 1013
Deregistering the Email Gateway from Smart Cisco Software Manager 1014
Reregistering the Email Gateway with Smart Cisco Software Manager 1014
Changing Transport Settings 1015
Renewing Authorization and Certificate 1015
Alerts 1015
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xlviii
Contents
Updating Smart Agent 1016
Smart Licensing in Cluster Mode 1016
Virtual Email Gateway License 1017
Virtual Email Gateway License Expiration 1017
Managing the Configuration File 1017
Managing Multiple Email Gateways with XML Configuration Files 1018
Managing Configuration Files 1018
Saving and Exporting the Current Configuration File 1019
Mailing the Configuration File 1019
Loading a Configuration File 1019
Resetting the Current Configuration 1022
Viewing the Configuration File 1022
Configuration File Page 1022
Managing Disk Space 1023
(Virtual Email Gateways Only) Increasing Available Disk Space 1023
Viewing and Allocating Disk Space Usage 1023
Managing Disk Space for the Miscellaneous Quota 1024
Ensuring That You Receive Alerts About Disk Space 1024
Disk Space and Centralized Management 1024
Managing Security Services 1025
Manually Updating the Engines 1025
Rollback to Previous Version of Engine 1026
Viewing Logs 1026
Service Updates 1026
Setting Up to Obtain Upgrades and Updates 1027
Options for Distributing Upgrades and Updates 1027
Configuring Your Network to Download Upgrades and Updates from the Cisco Servers 1027
Configuring the Email Gateway for Upgrades and Updates in Strict Firewall Environments 1028
Upgrading and Updating from a Local Server 1028
Hardware and Software Requirements for Upgrading and Updating from a Local Server 1029
Hosting an Upgrade Image on a Local Server 1030
UpdatesThrough a Proxy Server 1030
Configuring Server Settings for Downloading Upgrades and Updates 1030
Configuring Automatic Updates 1032
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
xlix
Contents
Configuring the Email Gateway to Verify the Validity of Updater Server Certificate 1033
Configuring the Appliance to Trust Proxy Server Communication 1034
Upgrading AsyncOS 1034
About Upgrading Clustered Systems 1035
About Batch Commands for Upgrade Procedures 1035
Notifications of Available Upgrades 1035
Notifications of Available Upgrades 1035
Preparing to Upgrade AsyncOS 1036
Downloading and Installing the Upgrade 1036
Viewing Status of, Canceling, or Deleting a Background Download 1038
Enabling Remote Power Cycling 1038
Reverting to a Previous Version of AsyncOS 1039
Reversion Impact 1040
Reverting AsyncOS on Virtual Email Gateways May Impact the License 1040
Reverting AsyncOS 1040
Configuring the Return Address for Email Gateway Generated Messages 1041
Setting Thresholds for System Health Parameters 1041
Checking the Health of Email Gateway 1043
Alerts 1043
Alert Severities 1043
AutoSupport 1044
Alert Delivery 1044
Example Alert Message 1044
Adding Alert Recipients 1045
Configuring Alert Settings 1045
Alert Settings 1046
Viewing Recent Alerts 1046
Alert Descriptions 1047
Anti-Spam Alerts 1047
Anti-Virus Alerts 1048
Directory Harvest Attack Prevention (DHAP) Alerts 1048
Hardware Alerts 1049
Spam Quarantine Alerts 1050
Safelist/Blocklist Alerts 1051
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
l
Contents
System Alerts 1051
Updater Alerts 1062
Outbreak Filter Alerts 1063
Clustering Alerts 1063
Changing Network Settings 1066
Changing the System Hostname 1066
Configuring Domain Name System (DNS) Settings 1067
Specifying DNS Servers 1067
Multiple Entries and Priority 1067
Using the Internet Root Servers 1068
Reverse DNS Lookup Timeout 1068
DNS Alert 1068
Clearing the DNS Cache 1068
Configuring DNS Settings via the Graphical User Interface 1069
Configuring TCP/IP Traffic Routes 1069
Configuring the Default Gateway 1070
Configuring SSL Settings 1070
Single Sign-On (SSO) Using SAML 2.0 1071
About Single Sign-On (SSO) and SAML 2.0 1071
SAML 2.0 SSO Workflow 1071
Guidelines and Limitations for SAML 2.0 1072
General 1072
Logout 1073
Limitations 1073
How to Configure SSO on your Email Gateway 1073
Prerequisites 1073
Configuring Email Gateway as a Service Provider 1074
Configuring the Identity Provider to Communicate with Email Gateway 1077
Configure Identity Provider Settings on Email Gateway 1079
Configuring OpenID Connect 1.0 on Email Gateway for AsyncOS APIs 1080
Overview 1080
Workflow 1081
Sample Access Token 1081
Prerequisites 1082
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
li
Contents
Configuring OpenID Connect on Email Gateway 1082
System Time 1083
Selecting a Time Zone 1083
Selecting a GMT Offset 1084
Editing Time Settings 1084
(Recommended) Setting Email Gateway System Time Using the Network Time Protocol (NTP)
1084
Setting Email Gateway System Time Manually 1085
Customizing Your View 1085
Using Favorite Pages 1085
Setting User Preferences 1085
General Settings 1086
Overriding Internet Explorer Compatibility Mode 1086
Collecting Usage Statistics of the Email Gateway on the New Web Interface 1087
Configuring Maximum HTTP Header Size 1087
Restarting and Viewing Status of Service Engines 1087
Receiving and Delivering Messages with Internationalised Domain Names (IDNs) 1088
Prerequisites 1088
Features Configurable using IDN Domains in Email Gateway 1088
CHAPTER 40 Managing and Monitoring Using the CLI 1091
Overview of Managing and Monitoring Using the CLI 1091
Reading the Available Components of Monitoring 1092
Reading the Event Counters 1092
Reading the System Gauges 1094
Reading the Rates of Delivered and Bounced Messages 1096
Monitoring Using the CLI 1097
Monitoring the Email Status 1097
Example 1098
Monitoring Detailed Email Status 1098
Example 1099
Monitoring the Status of a Mail Host 1100
Virtual Gateway 1101
Example 1101
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lii
Contents
Determining the Make-up of the Email Queue 1102
Example 1102
Displaying Real-time Activity 1103
Example 1103
Example 1104
Monitoring Inbound Email Connections 1104
Example 1105
Checking the DNS Status 1105
Example 1106
Resetting Email Monitoring Counters 1106
Example 1106
Identifying Active TCP/IP Services 1107
Managing the Email Queue 1107
Deleting Recipients in Queue 1107
Example 1107
Bouncing Recipients in Queue 1108
Example 1108
Redirecting Messages in Queue 1109
Example 1109
Showing Messages Based on Recipient in Queue 1110
Example 1110
Suspending Email Delivery 1110
Example 1111
Resuming Email Delivery 1111
Syntax 1111
Suspending Receiving Email 1111
Syntax 1111
Resuming Receiving Email 1112
Syntax 1112
Resuming Delivery and Receiving of Email 1112
Syntax 1112
Scheduling Email for Immediate Delivery 1112
Syntax 1112
Pausing the Work Queue 1113
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
liii
Contents
Locating and Archiving Older Messages 1114
Syntax 1114
Syntax 1114
Tracking Messages Within the System 1115
Monitoring System Health and Status Using SNMP 1116
MIB Files 1117
Hardware Objects 1117
Hardware Traps 1117
SNMP Traps 1118
Example: snmpconfig Command 1118
CHAPTER 41 Improving Phishing Detection Efficacy using Service Logs 1121
Overview 1121
Enabling Service Logs on Email Gateway 1121
Disabling Service Logs on Email Gateway 1122
Frequently Asked Questions 1122
What data do I share? 1122
What does Cisco do to make sure that the data I share is secure? 1123
Will sharing data impact the performance of my Cisco email gateways? 1124
Are there other ways I can share data? 1124
CHAPTER 42 Other Tasks in the GUI 1125
The Graphical User Interface (GUI) 1125
Enabling the GUI on an Interface 1125
System Information in the GUI 1126
Gathering XML status from the GUI 1126
CHAPTER 43 Advanced Network Configuration 1127
Media Settings on Ethernet Interfaces 1127
Using etherconfig to Edit Media Settings on Ethernet Interfaces 1127
Example of Editing Media Settings 1127
Network Interface Card Pairing/Teaming 1128
NIC Pairing and VLANs 1129
NIC Pair Naming 1129
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
liv
Contents
NIC Pairing and Existing Listeners 1129
Enabling NIC Pairing via the etherconfig Command 1129
Virtual Local Area Networks (VLANs) 1131
About Configuring VLANs 1131
Managing VLANs 1132
Creating a New VLAN via the etherconfig Command 1132
Creating an IP Interface on a VLAN via the interfaceconfig Command 1133
Configuring VLANs Using the Web Interface 1135
Direct Server Return 1135
Enabling Direct Server Return 1135
Enabling the Loopback Interface via the etherconfig Command 1136
Creating an IP Interface on Loopback via the interfaceconfig Command 1137
Creating a Listener on the New IP Interface 1138
Ethernet Interface’s Maximum Transmission Unit 1139
Accept or Reject ARP Replies with a Multicast Address 1140
CHAPTER 44 Logging 1141
Overview 1141
Understanding Log Files and Log Subscriptions 1141
Log Types 1141
Log Type Characteristics 1146
Log Retrieval Methods 1149
Log Filenames and Directory Structure 1150
Log Rollover and Transfer Schedule 1151
Logs Enabled by Default 1151
Log Types 1151
Timestamps in Log Files 1152
Using Text Mail Logs 1152
Interpreting a Text Mail Log 1153
Examples of Text Mail Log Entries 1154
Message received based on Sender’s Country of Origin 1160
Maximum URLs in Message Attachments Exceeds URL Scan Limit 1161
Maximum URLs in Message Body Exceeds URL Scan Limit 1161
Malicious Shortened URL redirected to Cisco Proxy Server 1161
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lv
Contents
Unable to Expand Shortened URL in Message 1161
Log Entry for Malicious URL in Message Attachment 1162
Message marked as Unscannable due to Extraction Failure 1162
Message marked as Unscannable due to RFC Violation 1162
Log Entries for Generated or Re-Written Messages 1162
Messages Sent to the Spam Quarantine 1163
Example of External Threat Feeds Mail Logs 1163
Examples of SDR Filtering Log Entries 1163
Cisco Advanced Phishing Protection Cloud Service Expired 1165
Reminder about Cisco Advanced Phishing Protection Cloud Service Expiry Date 1165
No API Access UID and API Access Secret Key 1165
Invalid API Access UID or API Access Secret Key 1166
Using Delivery Logs 1166
Examples of Delivery Log Entries 1167
Using Bounce Logs 1168
Examples of Bounce Log Entries 1169
Using Status Logs 1169
Reading Status Logs 1169
Using Domain Debug Logs 1172
Domain Debug Log Example 1173
Using Injection Debug Logs 1173
Injection Debug Log Example 1173
Using System Logs 1174
System Log Example 1174
Using CLI Audit Logs 1175
CLI Audit Log Example 1175
Using FTP Server Logs 1175
FTP Server Log Example 1175
Using HTTP Logs 1176
HTTP Log Example 1176
Using NTP Logs 1177
NTP Log Example 1177
Using Scanning Logs 1177
Scanning Log Example 1178
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lvi
Contents
Using Anti-Spam Logs 1178
Anti-Spam Log Example 1178
Using Graymail Logs 1178
Graymail Log Example 1179
Using Anti-Virus Logs 1179
Anti-Virus Log Example 1179
Using AMP Engine Logs 1179
Examples of AMP Engine Log Entries 1180
Using Spam Quarantine Logs 1184
Spam Quarantine Log Example 1185
Using Spam Quarantine GUI Logs 1185
Spam Quarantine GUI Log Example 1185
Using LDAP Debug Logs 1186
LDAP Debug Log Example 1186
Using Safelist/Blocklist Logs 1187
Safelist/Blocklist Log Example 1187
Using Reporting Logs 1188
Reporting Log Example 1188
Using Reporting Query Logs 1189
Reporting Query Log Example 1189
Using Updater Logs 1190
Updater Log Example 1190
Updater Log Example 1191
Understanding Tracking Logs 1191
Using Authentication Logs 1191
Authentication Log Example 1192
Example of Two-Factor Authentication Login Failure due to incorrect passcode 1192
Example of Two-Factor Authentication Login Failure due to time-out 1192
Example of Two-Factor Authentication Login Success 1192
Using Configuration History Logs 1192
Configuration History Log Example 1193
Using External Threat Feeds Engine Logs 1193
Example of External Threat Feeds Engine Logs 1193
Using Consolidated Event Logs 1194
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lvii
Contents
Using CSN Logs 1201
Using Advanced Phishing Protection Logs 1202
Using Audit Logs 1202
Using CSA Logs 1205
Log Subscriptions 1206
Configuring Log Subscriptions 1206
Log Levels 1207
Creating a Log Subscription in the GUI 1208
Editing Log Subscriptions 1208
Configuring Global Settings for Logging 1209
Logging Message Headers 1210
Configuring Global Settings for Logging Using the GUI 1210
Rolling Over Log Subscriptions 1211
Rollover By File Size 1211
Rollover By Time 1211
Rolling Over Log Subscriptions on Demand 1213
Viewing Recent Log Entries in the GUI 1213
Viewing Recent Log Entries in the CLI (tail Command) 1213
Example 1214
Configuring Host Keys 1215
CHAPTER 45 Centralized Management Using Clusters 1219
Overview of Centralized Management Using Clusters 1219
Cluster Requirements 1220
Cluster Organization 1220
Initial Configuration Settings 1221
Creating and Joining a Cluster 1222
The clusterconfig Command 1222
Joining an Existing Cluster 1223
Joining an Existing Cluster over SSH 1223
Joining an Existing Cluster over CCS 1225
Joining an Existing Cluster over SSH with Pre-Shared Keys 1227
Adding Groups 1228
Managing Clusters 1229
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lviii
Contents
Administering a Cluster from the CLI 1229
Copying and Moving Settings 1229
Experimenting with New Configurations 1230
Leaving a Cluster Permanently (Removal) 1231
Upgrading Machines in a Cluster 1231
CLI Command Support 1232
All Commands Are Cluster-aware 1232
The commit and clearchanges Commands 1232
New Operation Added 1232
Restricted Commands 1233
Administering a Cluster from the GUI 1234
Cluster Communication 1236
DNS and Hostname Resolution 1237
Clustering, Fully Qualified Domain Names, and Upgrading 1237
Cluster Communication Security 1237
Cluster Consistency 1238
Disconnect/Reconnect 1238
Interdependent Settings 1239
Loading a Configuration in Clustered Email Gateway 1241
Best Practices and Frequently Asked Questions 1242
Best Practices 1242
Copy vs Move 1243
Good CM Design Practices 1243
Best Practices for Accessing Spam or Policy Quarantines in Cluster Setup 1244
Procedures: Configuring an Example Cluster 1244
Summary of GUI Options for Using CM Settings Other Than the Cluster Default 1245
Setup and Configuration Questions 1246
General Questions 1246
Network Questions 1246
Planning and Configuration 1247
CHAPTER 46 Testing and Troubleshooting 1249
Debugging Mail Flow Using Test Messages: Trace 1249
Using the Listener to Test the Email Gateway 1255
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lix
Contents
Example 1256
Troubleshooting the Network 1259
Testing the Network Connectivity of the Email Gateway 1259
Troubleshooting 1260
Troubleshooting the Listener 1264
Troubleshooting Email Delivery From the Appliance 1265
Troubleshooting Performance 1267
Web Interface Appearance and Rendering Issues 1268
Responding to Alerts 1268
Troubleshooting Alerts That Miscellaneous Disk Usage is Approaching the Quota 1268
Troubleshooting Hardware Issues 1268
Remotely Resetting Email Gateway Power 1269
Working with Technical Support 1269
Technical Support for Virtual Email Gateway 1270
Opening or Updating a Support Case From the Email Gateway 1270
Enabling Remote Access for Cisco Technical Support Personnel 1271
Enabling Remote Access to Email Gateways With an Internet Connection 1271
Enabling Remote Access to Email Gateways Without a Direct Internet Connection 1271
Disabling a Tech Support Tunnel 1272
Disabling Remote Access 1272
Checking the Status of the Support Connection 1273
Running a Packet Capture 1273
CHAPTER 47 Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode 1275
Feature Summary: D-Mode for Optimized Outbound Delivery 1275
Features Unique to D-Mode-Enabled Email Gateways 1275
Standard Features Disabled in D-Mode-Enabled Email Gateways 1276
Standard Features Applicable to D-Mode-Enabled Email Gateways 1276
Setting Up the Email Gateway for Optimized Outbound Mail Delivery 1277
Configuring Resource-Conserving Bounce Settings 1277
Example of Enabling Resource-Conserving Bounce Settings 1277
Sending Bulk Mail Using IronPort Mail Merge (IPMM) 1278
Overview of IronPort Mail Merge 1278
Benefits of the Mail Merge Function 1278
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lx
Contents
Using Mail Merge 1279
SMTP Injection 1279
Variable Substitution 1279
Reserved Variables 1279
Example Message 1 1280
Part Assembly 1280
Example Message 2, Part 1 1280
Example Message 2, Part 2 1281
IPMM and DomainKeys Signing 1281
Command Descriptions 1281
XMRG FROM 1281
XDFN 1281
XPRT 1281
Notes on Defining Variables 1282
Example IPMM Conversation 1282
Example Code 1284
CHAPTER 48 Centralizing Services on a Cisco Secure Email and Web Manager (M-Series) 1285
Overview of Cisco Secure Email and Web Manager Services 1285
Network Planning 1286
Working with an External Spam Quarantine 1286
Mail Flow and External Spam Quarantine 1286
Migrating from a Local Spam Quarantine to an External Quarantine 1287
Enabling an External Spam Quarantine and External Safelist/Blocklist 1288
Disabling the Local Spam Quarantine to Activate the External Quarantine 1289
Troubleshooting an External Spam Quarantine 1289
About Centralizing Policy, Virus, and Outbreak Quarantines 1289
Centralized Policy, Virus, and Outbreak Quarantines 1289
Restrictions and Limitations of Centralized Policy, Virus, and Outbreak Quarantines 1290
Requirements for Centralized Policy, Virus, and Outbreak Quarantines in Cluster Configurations
1290
About Migration of Policy, Virus, and Outbreak Quarantines 1290
Centralizing Policy, Virus, and Outbreak Quarantines 1291
About Disabling Centralized Policy, Virus, and Outbreak Quarantines 1292
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lxi
Contents
Disabling Centralized Policy, Virus, and Outbreak Quarantines 1293
Troubleshooting Centralized Policy, Virus, and Outbreak Quarantines 1293
Configuring Centralized Reporting 1294
Requirements for Advanced Malware Protection Reporting 1294
Availability of Reporting Information after Changing to Centralized Reporting 1294
About Disabling Centralized Reporting 1294
Configuring Centralized Message Tracking 1295
Using Centralized Services 1295
APPENDIX A FTP, SSH, and SCP Access 1297
IP Interfaces 1297
How AsyncOS Selects Default IP Interface 1298
Configuring FTP Access to the Email Gateway 1298
Secure Copy (scp) Access 1300
Accessing the Email Gateway via a Serial Connection 1301
Pinout Details for the Serial Port in 80- and 90- Series Hardware 1301
Pinout Details for the Serial Port in 70-Series Hardware 1302
APPENDIX B Assigning Network and IP Addresses 1303
Ethernet Interfaces 1303
Selecting IP Addresses and Netmasks 1303
Sample Interface Configurations 1304
IP Addresses, Interfaces, and Routing 1304
Summary 1305
Strategies for Connecting Your Email Gateway 1305
APPENDIX C Example of Mail Policies and Content Filters 1307
Overview of Incoming Mail Policies 1307
Accessing Mail Policies 1307
Enabled, Disabled, and “Not Available” 1308
Configuring the Default Anti-Spam Policies for Incoming Messages 1309
Creating a Mail Policy for a Group of Sender and Recipients 1310
Default, Custom, and Disabled 1313
Creating Mail Policies for Different Groups of Senders and Recipients 1313
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lxii
Contents
Creating Mail Policies for Different Groups of Senders and Recipients 1314
Finding Senders or Recipients in Mail Policies 1316
Managed Exceptions 1316
Filtering Messages Based on Content 1317
Quarantining Message with “Confidential” in the Subject 1317
Stripping MP3 Attachments from Messages 1318
Bouncing Messages Sent to a Former Employee 1318
Applying Individual Content Filters to Different Groups of Recipients 1319
Enabling Content Filters for All Recipients by Default 1320
Allowing MP3 Attachments for Recipients in Engineering 1320
Notes on Configuring Content Filters in the GUI 1321
APPENDIX D Firewall Information 1325
Firewall Information 1325
Protecting Email Gateway from Network Attacks 1329
APPENDIX E End User License Agreement 1331
Cisco Systems End User License Agreement 1331
Supplemental End User License Agreement for Cisco Systems Content Security Software 1337
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lxiii
Contents
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
lxiv
CHAPTER 1
Getting Started with Cisco Secure Email Gateway
This chapter contains the following sections:
• What's New in AsyncOS 14.0, on page 1
• Comparison of Web Interfaces, New Web Interface with Legacy Web Interface , on page 13
• Where to Find More Information, on page 16
• Cisco Secure Email Gateway Overview, on page 19
What's New in AsyncOS 14.0
Table 1: Whats New in AsyncOS 14.0
Feature Description
Integrating the Cisco Secure Email The Cisco Secure Awareness cloud service allows you to
Gateway with Cisco Secure Awareness effectively deploy phishing simulations, awareness training, or
Cloud Service both to measure and report results. It empowers the security
operations team to focus on real-time threats and not end-user
mitigation.
The Cisco Secure Awareness cloud service provides reports of
Repeat Clickers - users who repeatedly click on any URL or
attachment sent through emails. These users are identified via a
phishing simulation campaign defined by the Cisco Secure
Awareness cloud service.
The ability to integrate your email gateway with the Cisco Secure
Awareness cloud service helps an organization to:
• Improve user awareness towards real-world phishing attacks.
• Allow email administrators to configure stringent policies
for set of users identified as “Repeat Clickers” by the Cisco
Secure Awareness cloud service.
For more information, see Integrating Email Gateway with Cisco
Secure Awareness Cloud Service, on page 355.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Improved Phishing Detection in Email The following are the enhancements made to improve phishing
Gateway detection in your email gateway:
• Sender Domain Reputation Filtering Enhancement
• Default Scanning of URLs in Message Attachments
Sender Domain Reputation Filtering Enhancement: You can
configure your email gateway to block messages based on the
SDR (Sender Domain Reputation) verdict at the SMTP
conversation level.
You can enable or disable SDR verification using the Mail Flow
Policy configuration settings.
Note By default, SDR verification is enabled for incoming
mail flow policies and disabled for outgoing mail flow
policies.
Default Scanning of URLs in Message Attachments: By default,
the email gateway scans URLs in message attachments for any
malicious content early in the email pipeline (before the
Anti-Spam engine).
The ability to block messages based on the SDR verdict at the
SMTP conversation level and default scanning of URLs in
message attachments helps an organization to:
• Improve efficacy detection in phishing and domain spoofing.
• Detect phishing attacks early in the email pipeline based on
the default action taken on the SDR reputation verdict.
For more information, see Sender Domain Reputation Filtering,
on page 323 and Defining Which Hosts Are Allowed to Connect
Using the Host Access Table , on page 101.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
2
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Scanning Password-Protected Attachments You can configure the Content Scanner in your email gateway
in Messages to scan the contents of password-protected attachments in
incoming or outgoing messages.
The ability to scan password-protected message attachments in
the email gateway helps an organization to:
• Detect phishing campaigns that use malware as attachments
in messages with password-protection to target limited
cyber-attacks.
• Analyze messages that contain password-protected
attachments for malicious activity and data privacy.
The following languages are supported for this feature - English,
Italian, Portuguese, Spanish, German, and French.
You can create user-defined passphrases to open
password-protected attachments in incoming or outgoing
messages in any one of the following ways:
• Security Services > Scan Behavior page in the web interface.
• scanconfig > protectedattachmentconfig sub command
in the CLI.
In this release, the Content Scanner can scan the contents of
password-protected attachments of the following file types only:
• Adobe Portable Document Format (PDF) files.
• MS Office file types:
• Word - .doc file format that supports 2002 to 2004
version and .docx file format that supports 2007 to 2016
version.
• Excel - .xls and .xlsx file formats that support 2007 to
2016 version.
• PowerPoint - .ppt or .pptx file formats that support 2007
to 2016 version.
• Archive file types - .zip format.
For more information, see Using Message Filters to Enforce Email
Policies, on page 139.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
3
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Simple Network Management Protocol The following are the enhancements made to the SNMP
(SNMP) Enhancementss configuration settings:
• Added new SNMP MIBs for additional monitoring.
• Support for SNMPv3 traps:
• SNMPv3 supports all the three security levels –
noAuthNoPriv, authNoPriv and authPriv.
• When both SNMPv3 and SNMPv2 are enabled, you
need to select the required version for traps.
• A new option is added under snmpconfig CLI command
to select the trap version when both SNMPv2 and
SNMPv3 are enabled.
For more information, see Managing and Monitoring Using the
CLI, on page 1091 .
New Report for mail policy details A new report – Mail Policy Details is added in the new web
interface of your email gateway. Use this report to view the
number of messages that match a configured mail policy.
For more information, see Using Email Security Monitor, on page
833.
New Message Tracking Filter for mail A new message tracking filter -Mail Policy is added in the
policy details Message Tracking > Advanced Search > Message Event option
in the new web interface of your email gateway. Use this option
to search for incoming or outgoing messages that match the
configured mail policy name entered in the ‘Mail Policy Name’
field.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
4
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Enhanced Overview and Incoming Mail The following are the enhancements made to the Overview and
reporting pages Incoming Mail reporting pages in the legacy web interface of
your email gateway:
Overview report page:
• Added new message category – Stopped by Domain
Reputation Filtering in the Incoming Mail Summary section.
• Changed Stopped by Reputation Filtering message category
name to Stopped by IP Reputation Filtering in the Incoming
Mail Summary section.
Incoming Mail report page:
• Added new column – Stopped by Domain Reputation
Filtering in the Incoming Mail Details section.
• Changed Stopped by Reputation Filtering column name to
Stopped by IP Reputation Filtering in the Incoming Mail
Details section.
For more information, see Using Email Security Monitor, on page
833.
Enhanced Mail Flow Summary and Mail The following are the enhancements made to the Mail Flow
Flow Details reporting pages Summary and Mail Flow Details reporting pages in the new web
interface of your email gateway:
Mail Flow Summary report page:
• Added new category – Stopped by Domain Reputation
Filtering in the Threat Messages graph section.
• Changed Stopped by Reputation Filtering category name to
Stopped by IP Reputation Filtering in the Threat Messages
graph section.
• Added new column – Stopped by Domain Reputation
Filtering in the Threat Detection Summary section.
• Changed Stopped by Reputation Filtering column name to
Stopped by IP Reputation Filtering in the Threat Detection
Summary section.
Mail Flow Details report page:
• Added new column – Stopped by Domain Reputation
Filtering in the Incoming Mails section for IP Addresses,
Domains, and Network Owners.
• Changed Stopped by Reputation Filtering column name to
Stopped by IP Reputation Filtering in the Incoming Mails
section for IP Addresses, Domains, and Network Owners.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
5
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Support for Internationalized Domain Cisco Secure Email Gateway can now receive and deliver
Name (IDN) messages with email addresses that contain IDN domains.
Currently, your email gateway provides support of IDN domains
for the following languages only:
• Indian Regional Languages: Hindi, Tamil, Telugu,
Kannada, Marati, Punjabi, Malayalam, Bengali, Gujarati,
Urdu, Assamese, Nepali, Bangla, Bodo, Dogri, Kashmiri,
Konkani, Maithili, Manipuri, Oriya, Sanskrit, Santali, Sindhi,
and Tulu.
• European and Asian Languages: French, Russian,
Japanese, German, Ukrainian, Korean, Spanish, Italian,
Chinese, Dutch, Thai, Arabic, and Kazakh.
For more information, see System Administration, on page 1005.
Security Enhancements AsyncOS 14.0 includes the following security enhancements:
• The email gateway now sends the Cisco Technical Support
requests over TLS. If your SMTP server is not using TLS,
the requests are sent as plain text.
• You can now configure your email gateway to send alerts
over TLS. Use the following subcommand in the CLI to
configure this functionality:
alertconfig > SETUP > Do you want to enable TLS
support to send alert messages?.
For more information, see the CLI Reference Guide associated
with this release.
New Remediation Report Status Widget A new widget - ’Remediation Report Status’ is added when you
search and remediate messages in the Message Tracking page of
the new web interface of your email gateway.
Use this widget to check the status of the Remediation Report
generation. For more information, see Remediating Messages in
Mailboxes, on page 577
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
6
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Support for New Content Matching You can create a DLP policy using any one of the following new
Classifiers - National Identification content matching classifiers - National Identification Numbers
Numbers for Southeast Asian countries for Southeast Asian countries:
• Indonesia KTP
• Malaysia MyKad
• Thailand ID
• Philippines UMID
• Singapore NRIC
You can select the new content matching classifiers in the
following pages of the web interface in your email gateway:
• Go to Mail Policies > DLP Policy Manager > Add Custom
Policy page > Predefined Custom Classifiers > Policy
Matching Details option.
• Go to Mail Policies > DLP Policy Manager > Add Custom
Policy page > Create Custom Classifier > Entity rule option.
• Go to Mail Policies > DLP Policy Manager >Add DLP
Policy page > Privacy Protection template option.
• Go to Mail Policies > DLP Policy Customizations > Add
Custom Classifier page > Entity rule option.
Bias-Free Terminology Usage in Product We have removed the bias terms in the product and related
and Related Documentation documentation.
The following are the list of bias terms replaced with the new
bias-free terms:
• whitelist' term replaced with 'allowed list' term
• blacklist' term replaced with 'blocked list' term
• master' term replaced with 'primary' term
• slave' term replaced with 'secondary' term
• blackhole' term replaced with 'sink hole' term
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
7
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Rebranded Product and Related We have rebranded the product and related documentation as
Documentation follows:
• Cisco Email Security Appliance changed to Cisco Secure
Email Gateway
• Cisco Cloud Email Security Appliance changed to Cisco
Secure Email Cloud Gateway
• Cisco Content Security Management Appliance changed to
Cisco Secure Email and Web Manager
AMP Upstream Proxy Settings for File You can now configure an upstream proxy for file analysis.
Analysis
For more information, see File Reputation Filtering and File
Analysis, on page 481
Performing Remedial Actions on In Cisco SecureX Threat Response, you can now investigate and
Messages in Cisco SecureX Threat apply the following remedial actions on messages processed by
Response your email gateway:
• Delete
• Forward
• Forward and Delete
For more information, see Integrating with Cisco SecureX Threat
Response, on page 335
Content Filter - Attachment File Info A new option - File Hash List is added in the Content Filters -
condition and Strip by Attachment File “Attachment File Info” condition and “Strip by Attachment File
Info action Enhancements Info” action.
Use this option to configure a content filter to take action on
message attachments that match a specific file SHA-256 value
in the selected file hash list.
Note You can also configure this functionality using
message filters.
For more information, see Content Filters, on page 281 and Using
Message Filters to Enforce Email Policies, on page 139.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
8
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Smart Software Licensing Enhancements AsyncOS 14.0 includes the following smart software licensing
enhancements:
• In a clustered configuration, you can now enable smart
software licensing and register all the machines
simultaneously with the Cisco Smart Software Manager.
• After you enabled smart software licensing and registered
your email gateway with the Cisco Smart Software Manager,
the Cisco Cloud Services portal is automatically enabled
and registered on your email gateway.
• If the Cisco Cloud Services certificate is expired, you can
now download a new certificate from the Cisco Talos
Intelligence Services portal using the cloudserviceconfig
> fetchcertificate sub command in the CLI.
• You can view details of the smart account created in the
Cisco Smart Software Manager portal using the
smartaccountinfo command in the CLI.
For more information, see System Administration, on page 1005
and Integrating with Cisco SecureX Threat Response, on page
335.
No Support for Sender Domain Age There will be no support for the Sender Domain Age functionality
functionality post AsyncOS 14.0 Release post the AsyncOS 14.0 release. The Sender Domain Age
functionality will be replaced with the Sender Maturity feature.
Sender Maturity represents the Cisco Talos view of how mature
a domain is as an email sender. The maturity value is tuned to
enable threat detection regarding emails and generally does not
reflect the domain age represented in “Whois-based domain age.”
Sender Maturity is set to a limit of 90 days, and beyond this limit,
a domain is considered mature as an email sender, and no further
details is provided.
Sender Maturity is used to calculate the sender reputation.
Immature domains are assigned lower reputation. Cisco Talos
recommends you rely on sender reputation only for determining
policy actions. Sender Maturity is exposed to fine-tune filters for
specific, non-standard scenarios.
Note Cisco Talos does not manually adjust maturity for
domains but relies on automated systems and sensors
to determine the most appropriate value.
Alert or Notification Banner for You will now receive an alert or notification banner message on
End-of-Life (EOL) or End-of-Service your email gateway web interface or CLI, if your email gateway
(EOS) AsyncOS Version or Hardware is running on an End-of-Life (EOL) or End-of-Service (EOS)
Model AsyncOS version or hardware model.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
9
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Office 365 or Hybrid (Graph API) You can now validate the client credentials for the Office 365 or
Remediation Account Profile Hybrid (Graph API) remediation account profile using the Client
Configuration Enhancement Secret value of the application generated on the Azure
Management Portal.
For more information, see Remediating Messages in Mailboxes,
on page 577
.
Virtual Email Gateway Support for You can deploy Cisco Secure Email Virtual Gateway on Amazon
Amazon Web Services (AWS) Elastic Compute Cloud (EC2) on Amazon Web Services (AWS).
Contact your Cisco sales representative with your AWS account
details (username and region) to provision an AMI image.
Consolidated Event Logs Enhancement Following are the enhancements made to the 'Consolidated Event
Logs' log type:
• A new log field - Message Size is added in the Consolidated
Event Logs log type to view the message size in the single
log line output.
• You can now view the size of the attachment in the message
in a single log line output
Steps:
1. Select the 'File(s) Details' log field when configuring
the log subscription for the Consolidated Event Logs.
2. Configure a message filter rule as follows :
Custom_ Log_Entry: if (true) {
log-entry("$filesizes"); }
OR
Configure the Add Log Entry content filter action by
adding the customized text as ‘$filesizes.'
Support for Cloud Connector Logging The email gateway now supports a new type of log subscription
- Cloud Connector Logs. Use this log subscription to view
information about Web Interaction Tracking data from Cisco
Aggregator Server. Most of the information is present at the Info
or Warning Level
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
10
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
Enhancement for Request Retry Method You can now set the reputation query timeout value within the
of File Reputation Service range of 20–30 seconds while configuring the file reputation and
analysis services (Security Services > File Reputation and
Analysis). The default value is 20, which is the minimum value.
During the configured query timeout, the email gateway sends
the file reputation queries to the AMP server. If the email gateway
fails to receive response from the AMP server, it retries by
sending the query again to the AMP server. The query timeout
includes the time taken for the first query request and the retry
request.
The retry method enables the email gateway to receive responses
when there are network latencies, issues related to the AMP
server, and so on.
New Cisco Talos Email Status Portal The Cisco Talos Email Status Portal replaces the legacy Cisco
Email Submission and Tracking Portal.
The Cisco Talos Email Status Portal is a web-based tool for
monitoring the status of email submissions from end-users.
Important • Users of the legacy portal can still access their
previous submissions in the new portal
• You will not be able to submit samples of spam,
phish, ham, marketing or non-marketing emails
that may have been misidentified by your email
gateway in the new portal. For more information
on how to submit email samples, see the How to
Submit Email Messages to Cisco document at
https://www.cisco.com/c/en/us/support/docs/
security/email-security-appliance/
214133-how-to-submit-email-messages-to-cisco.html.
For more information, see Managing Spam and
Graymail, on page 383.
Authentication Logs Enhancement You can now view the user privilege role details (for example,
‘admin,’, ‘operator,’ and so on) of the logged-in user in the
authentication logs.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
11
Getting Started with Cisco Secure Email Gateway
What's New in AsyncOS 14.0
Feature Description
New Passphrase Rule for defining login A new passphrase rule is added in your email gateway to define
passphrases your login passphrase:
Avoid usage of passphrases that contain three or more
repetitive or sequential characters, (for example,
‘AAA@124,’ ‘Abc@123,’ and so on.)
You can configure this passphrase rule in any one of the following
ways:
• System > Administration > Users > Local User Account &
Passphrase Settings > Reject three or more repetitive or
sequential characters in passphrases check box in the web
interface.
• userconfig > POLICY > PASSWORDSTRENGTH > Reject
passphrases that contain three or more repetitive
or sequential characters? [Y]> command in the CLI
Creating system-generated passphrases In addition to creating a login passphrase manually, you can now
also create a system-generated passphrase to log in to your email
gateway.
You can configure the system-generated passphrase in any one
of the following ways:
• Options > Change Passphrase page in the web interface.
• System Administration > System Setup Wizard page in the
web interface.
• System Administration > Users > Add Local User page in
the web interface.
• passphrase or passwd commands in the CLI
For more information, see Setup and Installation, on page 25.
Performing FQDN Validation for You can configure your email gateway to perform FQDN
Certificates validation for certificates in the following scenarios:
• Importing a custom certificate.
• Creating a self-signed S/MIME certificate.
• Creating a self-signed certificate.
• Importing a custom Certificate Authority (CA) list.
Note You can also perform FQDN validation for email
gateway certificates that contain IDN domains.
For more information, see S/MIME Security Services, on page
553 and Encrypting Communication with Other MTAs, on page
675.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
12
Getting Started with Cisco Secure Email Gateway
Comparison of Web Interfaces, New Web Interface with Legacy Web Interface
Feature Description
Performing FQDN Validation for Peer You can configure your email gateway to perform FQDN
Certificate during SSL Communication validation for peer certificate in System Administration > SSL
Configuration page in the web interface.
The FQDN validation is applicable for the following services:
• Outbound SMTP
• LDAP
• Updater
• Alert over TLS
Note You can perform FQDN validation for peer certificates
that contain IDN domains for the Outbound SMTP
services only.
For more information, see System Administration, on page 1005.
Performing x509 Validation for Peer You can configure your email gateway to perform x509 validation
Certificate during SSL Communication for peer certificate in System Administration > SSL Configuration
page in the web interface.
The x509 validation is applicable for the following services:
• Outbound SMTP
• LDAP
• Updater
• Alert over TLS
For more information, see System Administration, on page 1005.
Comparison of Web Interfaces, New Web Interface with Legacy
Web Interface
The following table shows the comparison of the new web interface with the legacy interface:
Table 2: Comparison of New Web Interface with legacy interface
Web Interface Page or Element New Web Interface Legacy Web Interface
Landing Page After you log in to the email After you log in to the email
gateway, the Mail Flow Summary gateway, the My Dashboard page
page is displayed. is displayed.
Reports Drop-down You can view reports for your You can view reports for your
email gateways from the Reports email gateway from the Monitor
drop-down. menu.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
13
Getting Started with Cisco Secure Email Gateway
Comparison of Web Interfaces, New Web Interface with Legacy Web Interface
Web Interface Page or Element New Web Interface Legacy Web Interface
My Reports Page Choose My Reports from the You can view the My Reports page
Reports drop-down. from Monitor > My Dashboard.
Mail Flow Summary Page The Mail Flow Summary page The Incoming Mail includes
includes trend graphs and summary graphs and summary tables for the
tables for incoming and outgoing incoming and outgoing messages.
messages.
Advanced Malware Protection The following sections are The email gateway has the
Report Pages available on the Advanced following Advanced Malware
Malware Protection report page Protection report pages under
of the Reports menu: Montior menu:
• Summary • Advanced Malware Protection
• AMP File Reputation • AMP File Analysis
• File Analysis • AMP Verdict Updates
• File Retrospection • Mailbox Auto Remediation
• Mailbox Auto Remediation
Outbreak Filters Page The Past Year Virus Outbreaks and The Monitor > Outbreak Filters
Past Year Virus Outbreak Summary page displays the Past Year Virus
are not available in the Outbreak Outbreaks and Past Year Virus
Filtering report page of the new Outbreak Summary.
web interface.
Spam Quarantines (Administrative Click Quarantine > Spam You can view spam quarantine
and End Users) Quarantine > Search in the new from the Monitor > Spam
web interface. Quarantine menu.
The end users can access the spam
quarantine using the URL:
https://example.com:<https-api-port>/euq-login
where example.com is the appliance
hostname and <https-api-port>
is the AsyncOS API HTTPS port
opened on the firewall.
Policy, Virus and Outbreak Click Quarantine > Other You can view, configure and
Quarantines Quarantine in the new web modify the Policy, Virus and
interface. Outbreak Quarantines on the email
gateway using the Monitor >
You can only view Policy, Virus
Policy, Virus and Outbreak
and Outbreak Quarantines in the
Quarantines.
new web interface.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
14
Getting Started with Cisco Secure Email Gateway
Comparison of Web Interfaces, New Web Interface with Legacy Web Interface
Web Interface Page or Element New Web Interface Legacy Web Interface
Select All Action for Messages in You can select multiple (or all) You cannot select multiple
Quarantine messages and perform a message messages to perform a message
action such as delete, delay, release, action.
move, etc.
Maximum Download Limit for The maximum limit for -
Attachments downloading attachments of a
quarantined message is restricted
to 25 MB.
Rejected Connections To search for rejected connections, -
click Tracking > Search >
Rejected Connection tab on the .
Query Settings The Query Settings field of the You can set the query timeout in
Message Tracking feature is not the Query Settings field of the
available on the . Message Tracking feature.
Message Tracking Data Click the gear icon on the upper You can view the missing-data
Availability right side of the page the web intervals for your email gateway.
interface to access Message
Tracking Data Availability page.
Show Additional Details of You can view additional details of -
Messages a message such as Verdict Charts,
Last State, Sender Groups, Sender
IP, IP Reputation Score and Policy
Match details.
Verdict Charts and Last State Verdict Chart displays information Verdict Charts and Last State
Verdicts of the various possible verdicts Verdicts of the messages are not
triggered by each engine in your available.
email gateway.
Last State of the message
determines the final verdict
triggered after all the possible
verdicts of the engine.
Message Attachments and Host Message attachments and host Message attachments and host
Names in Message Details names are not displayed in the names are displayed in the Message
Message Details section of the Details section of the message.
message on the email gateway.
Sender Groups, Sender IP, IP Sender Groups, Sender IP, IP Sender Groups, Sender IP, IP
Reputation Score and Policy Match Reputation Score, and Policy Match Reputation Score, and Policy Match
in Message Details details of the message is displayed of the message is not available in
in the Message Details section, on the Message Details section of the
the email gateway. message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
15
Getting Started with Cisco Secure Email Gateway
Where to Find More Information
Web Interface Page or Element New Web Interface Legacy Web Interface
Direction of the Message Direction of the message (incoming Direction of the message (incoming
(Incoming or Outgoing) or outgoing) is displayed in the or outgoing) is not displayed in the
message tracking results page, on message tracking results page.
the email gateway.
Where to Find More Information
Cisco offers the following resources to learn more about your email gateway:
• Documentation , on page 16
• Training, on page 17
• Cisco Notification Service , on page 17
• Knowledge Base, on page 17
• Cisco Support Community, on page 17
• Cisco Customer Support, on page 18
• Third Party Contributors, on page 18
• Cisco Welcomes Your Comments, on page 18
• Registering for a Cisco Account , on page 18
Documentation
You can access the online help version of this user guide directly from the appliance GUI by clicking Help
and Support in the upper-right corner.
The documentation set for the Cisco Secure Email Gateway includes the following documents and books:
• Release Notes
• Quick Start Guide for your Cisco Email Security Appliance model
• Hardware Installation or Hardware installation and maintenance guide for your model or series
• Cisco Content Security Virtual Appliance Installation Guide
• User Guide for AsyncOS for Cisco Secure Email Gateway (this book)
• CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway
• AsyncOS API for Cisco Secure Email Gateway - Getting Started Guide
Documentation for all Cisco Content Security products is available from:
Documentation For Cisco Content Security Location
Products
Hardware and virtual appliances See the applicable product in this table.
Cisco Email Security http://www.cisco.com/c/en/us/support/security/
email-security-appliance/tsd- products-support-series-home.html
Cisco Web Security http://www.cisco.com/c/en/us/support/security/
web-security-appliance/tsd-products- support-series-home.html
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
16
Getting Started with Cisco Secure Email Gateway
Training
Documentation For Cisco Content Security Location
Products
Cisco Content Security Management http://www.cisco.com/c/en/us/support/
security/content-security-management- appliance/tsd-
products-support-series-home.html
CLI reference guide for Cisco Content http://www.cisco.com/c/en/us/support/security/
Security appliances email-security-appliance/products-command-reference-list.html
Cisco IronPort Encryption http://www.cisco.com/c/en/us/support/security/
email-security-appliance/products-command-reference-list.html
Training
More information about training is available from:
• http://www.cisco.com/c/en/us/training-events/training-certifications/supplemental-
training/email-and-web-security.html
• http://www.cisco.com/c/en/us/training-events/training-certifications/overview.html
Cisco Notification Service
Sign up to receive notifications relevant to your Cisco Content Security Appliances, such as Security Advisories,
Field Notices, End of Sale and End of Support statements, and information about software updates and known
issues.
You can specify options such as notification frequency and types of information to receive. You should sign
up separately for notifications for each product that you use.
To sign up, visit http://www.cisco.com/cisco/support/notifications.html
A Cisco.com account is required. If you do not have one, see Registering for a Cisco Account , on page 18.
Knowledge Base
Procedure
Step 1 Go to the main product page (http://www.cisco.com/c/en/us/support/security/
email-security-appliance/tsd-products-support-series-home.html)
Step 2 Look for links with TechNotes in the name.
Cisco Support Community
The Cisco Support Community is an online forum for Cisco customers, partners, and employees. It provides
a place to discuss general email and web security issues, as well as technical information about specific Cisco
products. You can post topics to the forum to ask questions and share information with other Cisco users.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
17
Getting Started with Cisco Secure Email Gateway
Cisco Customer Support
Access the Cisco Support Community on the Customer Support Portal at the following URLs:
• For email security and associated management:
https://supportforums.cisco.com/community/5756/email-security
• For web security and associated management:
https://supportforums.cisco.com/community/5786/web-security
Cisco Customer Support
Cisco TAC: http://www.cisco.com/c/en/us/support/web/tsd-cisco-worldwide-contacts.html
Support site for legacy IronPort: http://www.cisco.com/c/en/us/services/acquisitions/ironport.html
For non-critical issues, you can also access customer support from the email gateway. For instructions, see
the User Guide or online help.
Third Party Contributors
See Open Source licensing information for your release on this page:
http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-release-notes-list.html .
Some software included within Cisco AsyncOS is distributed under the terms, notices, and conditions of
software license agreements of FreeBSD, Inc., Stichting Mathematisch Centrum, Corporation for National
Research Initiatives, Inc., and other third party contributors, and all such terms and conditions are incorporated
in Cisco license agreements.
The full text of these agreements can be found here:
https://support.ironport.com/3rdparty/AsyncOS_User_Guide-1-1.html.
Portions of the software within Cisco AsyncOS is based upon the RRDtool with the express written consent
of Tobi Oetiker.
Portions of this document are reproduced with permission of Dell Computer Corporation. Portions of this
document are reproduced with permission of McAfee, Inc. Portions of this document are reproduced with
permission of Sophos Plc.
Cisco Welcomes Your Comments
The Cisco Technical Publications team is interested in improving the product documentation. Your comments
and suggestions are always welcome. You can send comments to the following email address:
[email protected]
Please include the product name, release number, and document publication date in the subject of your message.
Registering for a Cisco Account
Access to many resources on Cisco.com requires a Cisco account.
If you do not have a Cisco.com User ID, you can register for one here: https://idreg.cloudapps.cisco.com/
idreg/register.do
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
18
Getting Started with Cisco Secure Email Gateway
Cisco Secure Email Gateway Overview
Related Topics
• Cisco Notification Service , on page 17
• Knowledge Base, on page 17
Cisco Secure Email Gateway Overview
The AsyncOS™ operating system includes the following features:
• Anti-Spam at the gateway, through the unique, multi-layer approach of SenderBase Reputation Filters
and Cisco Anti-Spam integration.
• Anti-Virus at the gateway with the Sophos and McAfee Anti-Virus scanning engines.
• Outbreak Filters™, Cisco’s unique, preventive protection against new virus, scam, and phishing outbreaks
that can quarantine dangerous messages until new updates are applied, reducing the window of
vulnerability to new message threats.
• Policy, Virus, and Outbreak Quarantines provide a safe place to store suspect messages for evaluation
by an administrator.
• Spam Quarantine either on-box or off, providing end user access to quarantined spam and suspected
spam.
• Email Authentication. Cisco AsyncOS supports various forms of email authentication, including Sender
Policy Framework (SPF), Sender ID Framework (SIDF), and DomainKeys Identified Mail (DKIM)
verification of incoming mail, as well as DomainKeys and DKIM signing of outgoing mail.
• Cisco Email Encryption. You can encrypt outgoing mail to address HIPAA, GLBA and similar regulatory
mandates. To do this, you configure an encryption policy on the email gateway and use a local key server
or hosted key service to encrypt the message.
• Email Security Manager, a single, comprehensive dashboard to manage all email security services and
applications on the email gateway. Email Security Manager can enforce email security based on user
groups, allowing you to manage Cisco Reputation Filters, Outbreak Filters, Anti-Spam, Anti-Virus, and
email content policies through distinct inbound and outbound policies.
• On-box message tracking. AsyncOS for Email includes an on-box message tracking feature that makes
it easy to find the status of messages that the E email gateway processes.
• Mail Flow Monitoring of all inbound and outbound email that provides complete visibility into all email
traffic for your enterprise.
• Access control for inbound senders, based upon the sender’s IP address, IP address range, or domain.
• Extensive message and content filtering technology allows you to enforce corporate policy and act on
specific messages as they enter or leave your corporate infrastructure. Filter rules identify messages
based on message or attachment content, information about the network, message envelope, message
headers, or message body. Filter actions allow messages to be dropped, bounced, archived, blind carbon
copied, or altered, or to generate notifications.
• Message encryption via secure SMTP over Transport Layer Security ensures messages traveling
between your corporate infrastructure and other trusted hosts are encrypted.
• Virtual Gateway™ technology allows the email gateway to function as several email gateways within
a single server, which allows you to partition email from different sources or campaigns to be sent over
separate IP addresses. This ensures that deliverability issues affecting one IP address do not impact others.
• Protection against malicious attachments and links in email messages, provided by multiple services.
• Use Data Loss Prevention to control and monitor the information that leaves your organization.
AsyncOS supports RFC 2821-compliant Simple Mail Transfer Protocol (SMTP) to accept and deliver messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
19
Getting Started with Cisco Secure Email Gateway
Supported Languages
Most reporting, monitoring, and configuration commands are available through both the web-based GUI via
HTTP or HTTPS. In addition, an interactive Command Line Interface (CLI) which you access from a Secure
Shell (SSH) or direct serial connection is provided for the system.
You can also set up a Cisco Secure Email and Web Manager to consolidate reporting, tracking, and quarantine
management for multiple E email gateways.
Related Topics
• Supported Languages, on page 20
Supported Languages
AsyncOS can display its GUI and CLI in any of the following languages:
• English
• French
• Spanish
• German
• Italian
• Korean
• Japanese
• Portuguese (Brazil)
• Chinese (traditional and simplified)
• Russian
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
20
CHAPTER 2
Accessing the Email Gateway
This chapter contains the following sections:
• Web-based Graphical User Interface (GUI) , on page 21
• Changing Configuration Settings, on page 24
• Command Line Interface (CLI), on page 24
Web-based Graphical User Interface (GUI)
You can administer the email gateway using both the web-based Graphical User Interface (GUI) and Command
Line Interface (CLI). The GUI contains most of the functionality you need to configure and monitor the
system. However, not all CLI commands are available in the GUI; some features are only available through
the CLI.
• Browser Requirements, on page 21
• Accessing the GUI, on page 22
Browser Requirements
To access the web-based UI, your browser must support and be enabled to accept JavaScript and cookies, and
it must be able to render HTML pages containing Cascading Style Sheets (CSS).
Browser Operating System
Internet Explorer 11.0 Microsoft Windows 7 and 10
Safari 7.0 and later Mac OS X
Firefox 39.0 and later Microsoft Windows 7 and 10, Mac OS X
Chrome 44.0 and later Microsoft Windows 7 and 10, Mac OS X
Do not use multiple browser windows or tabs simultaneously to make changes to the email gateway. Do not
use concurrent GUI and CLI sessions. Doing so will cause unexpected behavior and is not supported.
You may need to configure your browser’s pop-up blocking settings in order to use the web interface because
some buttons or links in the interface will cause additional windows to open.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
21
Accessing the Email Gateway
Accessing the GUI
Accessing the GUI
To access the GUI on a brand new system, access the following URL:
http://192.168.42.42/
When the login page is displayed, log in to the system using the default username and passphrase.
Related Topics
• Factory Default Username and Passphrase, on page 22
• Centralized Management, on page 22
Factory Default Username and Passphrase
• Username: admin
• Passphrase: ironport
On brand new (not upgraded from previous releases of AsyncOS) systems, you will automatically be redirected
to the System Setup Wizard.
During the initial system setup, you choose IP addresses for interfaces and whether to run HTTP and/or HTTPS
services for those interfaces. When HTTP and/or HTTPS services have been enabled for an interface, you
can use any supporting browser to view the GUI by entering the IP address or hostname of the IP interface
as a URL in the location field (“address bar”) of the browser.
For example:
http://192.168.1.1 or
https://192.168.1.1 or
http://mail3.example.com or
https://mail3.example.com
Note If HTTPS has been enabled for an interface (and HTTP requests are not being redirected to the secure service),
remember to access the GUI using the “ https:// ” prefix.
Related Topics
• Adding Users , on page 980
Centralized Management
If you have created a cluster, you can browse machines in the cluster, create, delete, copy, and move settings
among clusters, groups, and machines (that is, perform the equivalent of the clustermode and clusterset
commands) from within the GUI.
For more information, see Administering a Cluster from the GUI, on page 1234.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
22
Accessing the Email Gateway
Enhanced User Experience using How-Tos Widget
Enhanced User Experience using How-Tos Widget
The How-Tos is a contextual widget that provides in-app assistance to users in the form of walkthroughs to
accomplish complex tasks on your email gateway. To view a list of walkthroughs supported in this release,
see Lis of Walkthroughs.
You can access the walkthroughs by clicking the How-Tos widget on the web interface of your email gateway.
By default, the How-Tos widget is enabled on your email gateway. The contents of the How-Tos widget are
cloud-updateable.
For each walkthrough, there are recommended settings for specific configurable values categorized as follows:
• Conservative Settings - Cautious, configuration of not excessive limits
• Moderate Settings - Average, configuration within reasonable limits
• Aggressive Settings- Forceful, configuration of assertive limits
Note • The current set of walkthroughs is limited to the following users: admin, cloud-admin, and operator.
• If you are using Internet Explorer version 11 to access the web interface of your email gateway, you may
not be able to view the How-Tos widget. Go to System Administration > General Settings page on
your web interface and enable the Override IE Compatibility Mode option to view the How-Tos widget.
Disabling How-Tos Widget on the Email Gateway
Use the adminaccessconfig > how-tos sub command in the CLI if you want to disable the How-Tos widget
on your email gateway.
Example: Disabling How-Tos widget on the Email Gateway
mail.example.com> adminaccessconfig
Choose the operation you want to perform:
- BANNER - Configure login message (banner) for appliance administrator login.
- WELCOME - Configure welcome message (post login message) for appliance administrator
login.
- IPACCESS - Configure IP-based access for appliance administrative interface.
- CSRF - Configure web UI Cross-Site Request Forgeries protection.
- XSS - Configure Cross-Site Scripting Attack protection.
- HOSTHEADER - Configure option to use host header in HTTP requests.
- TIMEOUT - Configure GUI and CLI session inactivity timeout.
- MAXHTTPHEADERFIELDSIZE - Configure maximum HTTP header Field size.
- HOW-TOS - Configure How-Tos feature.
[]> how-tos
How-Tos consists of a list of generic walkthroughs to assist the users in completing
a particular task (for example, "enabling and configuring a service engine on the appliance").
Would you like to enable How-Tos? [Y]> no
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
23
Accessing the Email Gateway
Changing Configuration Settings
Changing Configuration Settings
• Configuration Changes, on page 24
• Commit or Abandoning Changes , on page 24
Configuration Changes
You can make configuration changes while email operations proceed normally.
Commit or Abandoning Changes
You must explicitly save most configuration changes.
When changes are pending a commit, the Commit Changes button turns orange.
To clear or commit these changes, click Commit Changes.
Command Line Interface (CLI)
The Command Line Interface is accessible via SSH on IP interfaces that have been configured with these
services enabled, or via terminal emulation software on the serial port. By factory default, SSH is configured
on the Management port. Use the interfaceconfig command to disable these services.
For more information about CLI commands and conventions, see the CLI Reference Guide for AsyncOS for
Cisco Secure Email Gateway.
Note The factory default username and passphrase for accessing CLI is same as that of the web interface. See
Factory Default Username and Passphrase, on page 22.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
24
CHAPTER 3
Setup and Installation
This chapter contains the following sections:
• Installation Planning, on page 25
• Physically Connecting the Email Gateway to the Network, on page 28
• Preparing for System Setup, on page 32
• Using the System Setup Wizard , on page 38
• Verifying Your Configuration and Next Steps , on page 63
Installation Planning
• Review Information That Impacts Planning Decisions , on page 25
• Plan to Place the Email Gateway at the Perimeter of Your Network, on page 25
• Register the Email Security Appliance in DNS, on page 26
• Installation Scenarios, on page 27
Review Information That Impacts Planning Decisions
• If you are configuring a virtual email gateway, please see the Cisco Content Security Virtual Appliance
Installation Guide before continuing with this chapter.
• If you are configuring an M-Series Cisco Secure Email and Web Manager, please see Centralizing
Services on a Cisco Secure Email and Web Manager (M-Series), on page 1285.
• We recommend reviewing Understanding the Email Pipeline, on page 65 before installing, as some
features and functions may affect the placement of the email gateway within your infrastructure.
Plan to Place the Email Gateway at the Perimeter of Your Network
Your email gateway is designed to serve as your SMTP gateway, also known as a mail exchange (MX). For
best results, some features require the email gateway to be the first machine with an IP address that is directly
accessible to the Internet (that is, it is an external IP address) for sending and receiving email.
The per-recipient reputation filtering, anti-spam, anti-virus, and Virus Outbreak Filter features (see IronPort
Anti-Spam Filtering, on page 386, Sophos Anti-Virus Filtering, on page 366, and Outbreak Filters, on page
425) are designed to work with a direct flow of messages from the Internet and from your internal network.
You can configure the email gateway for policy enforcement (Overview of Defining Which Hosts Are Allowed
to Connect, on page 101) for all email traffic to and from your enterprise.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
25
Setup and Installation
Register the Email Security Appliance in DNS
Ensure that the email gateway is both accessible via the public Internet and is the “first hop” in your email
infrastructure. If you allow another MTA to sit at your network’s perimeter and handle all external connections,
then the email gateway will not be able to determine the sender’s IP address. The sender’s IP address is needed
to identify and distinguish senders in the Mail Flow Monitor, to query the IP Reputation Service for the
sender’s IP Reputation Score, and to improve the efficacy of the Anti-Spam and Outbreak Filters features.
Note If you cannot configure the email gateway as the first machine receiving email from the Internet, you can still
exercise some of the security services available on the email gateway. For more information, see Determining
Sender IP Address In Deployments with Incoming Relays , on page 411.
When you use the email gateway as your SMTP gateway:
• The Mail Flow Monitor feature (see Using Email Security Monitor, on page 833) offers complete visibility
into all email traffic for your enterprise from both internal and external senders.
• LDAP queries (see LDAP Queries, on page 775) for routing, aliasing, and masquerading can consolidate
your directory infrastructure and provide for simpler updates.
• Familiar tools like alias tables (see Creating Alias Tables, on page 703), domain-based routing (The
Domain Map Feature, on page 720), and masquerading (Configuring Masquerading, on page 710) make
the transition from Open-Source MTAs easier.
Register the Email Security Appliance in DNS
Malicious email senders actively search public DNS records to hunt for new victims. In order to utilize the
full capabilities of Anti-Spam, Outbreak Filters, McAfee Antivirus and Sophos Anti-Virus, ensure that the
email gatewayis registered in DNS.
To register the email gateway in DNS, create an A record that maps the email gateway's hostname to its IP
address, and an MX record that maps your public domain to the email gateway's hostname. You must specify
a priority for the MX record to advertise the email gateway as either a primary or backup MTA for your
domain.
In the following example, the email gateway (ironport.example.com) is a backup MTA for the domain
example.com, since its MX record has a higher priority value (20). In other words, the higher the numeric
value, the lower the priority of the MTA.
$ host -t mx example.com
example.com mail is handled (pri=10) by mail.example.com
example.com mail is handled (pri=20) by ironport.example.com
By registering the email gateway in DNS, you will attract spam attacks regardless of how you set the MX
record priority. However, virus attacks rarely target backup MTAs. Given this, if you want to evaluate an
anti-virus engine to its fullest potential, configure the email gateway to have an MX record priority of equal
or higher value than the rest of your MTAs.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
26
Setup and Installation
Installation Scenarios
Installation Scenarios
You can install your email gateway into your existing network infrastructure in several ways.
Most customers’ network configurations are represented in the following scenarios. If your network
configuration varies significantly and you would like assistance planning an installation, please contact Cisco
Customer Support (see Cisco Customer Support, on page 18).
• Configuration Overview, on page 27
• Incoming, on page 27
• Outgoing, on page 27
• Ethernet Interfaces, on page 27
• Advanced Configurations, on page 28
• Firewall Settings (NAT, Ports) , on page 28
Configuration Overview
The following figure shows the typical placement of the email gateway in an enterprise network environment:
In some scenarios, the email gateway resides inside the network “DMZ,” in which case an additional firewall
sits between the email gateway and the groupware server.
The following network scenarios are described:
• Behind the Firewall: two listeners configuration (Figure - Behind the Firewall Scenario / 2 Listeners
Configuration)
Choose the configuration that best matches your infrastructure. Then proceed to the next section, Preparing
for System Setup, on page 32.
Incoming
• Incoming mail is accepted for the local domains you specify.
• All other domains are rejected.
• External systems connect directly to the email gateway to transmit email for the local domains, and the
email gateway relays the mail to the appropriate groupware servers (for example, Exchange™,
Groupwise™, Domino™) via SMTP routes. (See Routing Email for Local Domains, on page 697.)
Outgoing
• Outgoing mail sent by internal users is routed by the groupware server to the email gateway.
• The email gateway accepts outbound email based on settings in the Host Access Table for the private
listener. (For more information, see Working with Listeners, on page 78.)
Ethernet Interfaces
Only one of the available Ethernet interfaces on the email gateway is required in these configurations. However,
you can configure two Ethernet interfaces and segregate your internal network from your external Internet
network connection.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
27
Setup and Installation
Hardware Ports
For more information about assigning multiple IP addresses to the available interfaces, see Configuring Mail
Gateways for all Hosted Domains Using Virtual Gateway™ Technology, on page 749 and Assigning Network
and IP Addresses, on page 1303.
Hardware Ports
The number and type of ports on your hardware appliance depend on the model:
Ports Type C190 C390 C690 C690F C195 C395 C695 C695F
Management Ethernet 0 1 1 1 0 1 1 1
Data Ethernet 2* 5 5 3 2* 5 5 3
Console Serial RJ-45 RJ-45 RJ-45 RJ-45 RJ-45 RJ-45 RJ-45 RJ-45
Remote Ethernet Y Y Y Y Y Y Y Y
Power
Management
(RPC)
* For appliances without a dedicated management port, use the Data1 port for management purposes.
For more information about ports, see the Hardware Installation Guide for your appliance model.
Related Topics
• Configuring Network Interfaces, on page 43
• Accessing the Email Gateway via a Serial Connection, on page 1301
• Enabling Remote Power Cycling , on page 1038
Advanced Configurations
In addition to the configurations shown in Figure - Behind the Firewall Scenario / 2 Listeners Configuration
and Figure One Listener Configuration, you can also configure:
• Multiple email gateways using the Centralized Management feature. See Centralized Management Using
Clusters, on page 1219
• Redundancy at the network interface card level by “teaming” two of the Ethernet interfaces on email
gateways using the NIC Pairing feature. See Advanced Network Configuration, on page 1127
Firewall Settings (NAT, Ports)
SMTP and DNS services must have access to the Internet. Other services may also require open firewall ports.
For details, see Firewall Information, on page 1325.
Physically Connecting the Email Gateway to the Network
• Configuration Scenarios, on page 29
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
28
Setup and Installation
Configuration Scenarios
Configuration Scenarios
The typical configuration scenario for the email gateway is as follows:
• Interfaces - Only one of the three available Ethernet interfaces on the email gateway is required for most
network environments. However, you can configure two Ethernet interfaces and segregate your internal
network from your external Internet network connection.
• Public Listener (incoming email) - The public listener receives connections from many external hosts
and directs messages to a limited number of internal groupware servers.
• Accepts connections from external mail hosts based on settings in the Host Access Table (HAT).
By default, the HAT is configured to ACCEPT connections from all external mail hosts.
• Accepts incoming mail only if it is addressed for the local domains specified in the Recipient Access
Table (RAT). All other domains are rejected.
• Relays mail to the appropriate internal groupware server, as defined by SMTP Routes.
• Private Listener (outgoing email) - The private listener receives connections from a limited number of
internal groupware servers and directs messages to many external mail hosts.
• Internal groupware servers are configured to route outgoing mail to the Cisco C- or X-Series email
gateway.
• The email gateway accepts connections from internal groupware servers based on settings in the
HAT. By default, the HAT is configured to RELAY connections from all internal mail hosts.
Related Topics
• Segregating Incoming and Outgoing Mail, on page 29
Segregating Incoming and Outgoing Mail
You can segregate incoming and outgoing email traffic over separate listeners and on separate IP addresses.
You can use Internet Protocol version 4 (IPv4) and version 6 (IPv6) addresses. However, the System Setup
Wizard on the email gateway supports initial configuration of the following configurations:
• 2 separate listeners on 2 logical IPv4 and 2 IPv6 addresses configured on separate physical interfaces
• segregates incoming and outgoing traffic
• you can assign an IPv4 and an IPv6 address to each listener
• 1 listener on 1 logical IPv4 address configured on one physical interface
• combines both incoming and outgoing traffic
• you can assign both an IPv4 and an IPv6 address to the listener
Configuration worksheets for both one and two listener configurations are included below (see Gathering the
Setup Information, on page 35). Most configuration scenarios are represented by one of the following three
figures.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
29
Setup and Installation
Segregating Incoming and Outgoing Mail
Figure 1: Behind the Firewall Scenario / 2 Listeners Configuration
Notes:
• 2 Listeners
• 2 IPv4 addresses
• 2 IPv6 addresses
• 1 or 2 Ethernet interfaces (only 1 interface shown)
• SMTP routes configured
Inbound Listener: “InboundMail” (public)
• IPv4 address: 1.2.3.4
• IPv6 address: 2001:0db8:85a3::8a2e:0370:7334
• Listener on the Data2 interface listens on port 25
• HAT (accept ALL)
• RAT (accept mail for local domains; reject ALL)
Outbound Listener: “OutboundMail” (private)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
30
Setup and Installation
Segregating Incoming and Outgoing Mail
• IP address: 1.2.3.5
• IPv6 address: 2001:0db8:85a3::8a2e:0370:7335
• Listener on the Data2 interface listens on port 25
• HAT (relay for local domains; reject ALL)
DNS can be configured to use Internet Root servers or internal DNS servers
SMTP routes direct mail to proper groupware server
Firewall ports opened for appropriate services to and from the email gateway
Figure 2: One Listener Configuration
Notes:
• 1 Listener
• 1 IP addresses
• 1 Ethernet interface
• SMTP routes configured
Inbound Listener: “InboundMail” (public)
• IP address: 1.2.3.4
• Listener on the Data2 interface listens on port 25
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
31
Setup and Installation
Preparing for System Setup
• HAT (accept ALL) includes entries for Groupware servers in RELAYLIST
• RAT (accept mail for local domains; reject ALL)
DNS can be configured to use Internet Root servers or internal DNS servers
SMTP routes direct mail to proper groupware server
Firewall ports opened for appropriate services to and from the email gateway.
Preparing for System Setup
• Determine Method for Connecting to the Email Gateway, on page 33
• Determining Network and IP Address Assignments, on page 34
• Gathering the Setup Information, on page 35
Procedure
Command or Action Purpose
Step 1 Determine how you will connect to the email See Determine Method for Connecting to the
gateway. Email Gateway, on page 33
Step 2 Determine network and IP address assignments. See
• If you have already cabled your email Determine Method for Connecting to the Email
gateway to your network, ensure that the Gateway, on page 33 and Determining Network
default IP address for the email and IP Address Assignments, on page 34
gatewaydoes not conflict with other IP
addresses on your network.
Step 3 Gather information about your system setup. See Gathering the Setup Information, on page
35.
Step 4 Review the latest product release notes for your Release notes are available from the link in
email gateway. Documentation , on page 16.
Step 5 Unpack the email gateway, physically install it See Quickstart Guide for your email gateway.
in a rack, and turn it on. This guide is available from the link in
Documentation , on page 16.
Step 6 If you will run the setup wizard using the See Running the Command Line Interface (CLI)
command line interface (CLI), access the CLI. System Setup Wizard, on page 50)
Step 7 If you will run the setup wizard using the web a. (Virtual appliances ONLY) Access the
interface: command-line interface and enable HTTP
and/or HTTPS using the interfaceconfig
command.
b. Launch a web browser and enter the IP
address of the email gateway.
Step 8 If you are setting up a virtual email gateway, Use the loadlicense command. For more
load your virtual email gateway license. information, see the Cisco Content Security
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
32
Setup and Installation
Determine Method for Connecting to the Email Gateway
Command or Action Purpose
Virtual Appliance Installation Guide available
from the link in Documentation , on page 16.
Step 9 Configure basic settings for your system. See Using the System Setup Wizard , on page
38
Determine Method for Connecting to the Email Gateway
To successfully set up the email gateway in your environment, you must gather important network information
from your network administrator about how you would like to connect the email gateway to your network.
Related Topics
• Connecting to the Email Gateway, on page 33
Connecting to the Email Gateway
During the initial setup, you can connect to the email gateway in one of two ways:
Table 3: Options for Connecting to the Email Gateway
Ethernet An Ethernet connection between a PC and the network and between the network and
the Management port. The IPv4 address that has been assigned to the Management
port by the factory is 192.168.42.42 . This is the easiest way to connect if it works
with your network configuration.
Serial A serial communications connection between the PC and the Serial Console port. If
you cannot use the Ethernet method, a straight serial-to- serial connection between
the computer and the email gateway will work until alternate network settings can be
applied to the Management port. For pinout information, see Accessing the Email
Gateway via a Serial Connection, on page 1301. The communications settings for the
serial port are:
Bits per second: 9600
Data bits: 8
Parity: None
Stop bits: 1
Flow control: Hardware
Note Keep in mind that the initial connection method is not final. This process applies only for the initial
configuration. You can change network settings at a later time to allow different connection methods. (See
FTP, SSH, and SCP Access, on page 1297 for more information.) You can also create multiple user accounts
with differing administrative privileges to access the email gateway. (For more information, see Adding Users
, on page 980.)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
33
Setup and Installation
Determining Network and IP Address Assignments
Determining Network and IP Address Assignments
You can use both IPv4 and IPv6 addresses.
• Default IP Addresses for Management and Data Ports , on page 34
• Choosing Network Connections to Receive and Deliver Email , on page 34
• Binding Logical IP Addresses to Physical Ethernet Ports, on page 34
• Choosing Network Settings for Your Connections, on page 34
Default IP Addresses for Management and Data Ports
The IP address that is pre-configured on the Management port (the Data 1 port on C170 and C190 email
gateways) is 192.168.42.42 .
Choosing Network Connections to Receive and Deliver Email
Most users take advantage of the two Data Ethernet ports on the email gateway by connecting to two networks
from the email gateway:
• The private network accepts and delivers messages to your internal systems.
• The public network accepts and delivers messages to the Internet.
Other users may want to use only one Data port serving both functions. Although the Management Ethernet
port can support any function, it is preconfigured for access to the graphical user interface and the command
line interface.
Binding Logical IP Addresses to Physical Ethernet Ports
You can segregate incoming and outgoing email traffic over separate listeners and on separate IP addresses.
You can use Internet Protocol version 4 (IPv4) and version 6 (IPv6) addresses. However, the System Setup
Wizard on the email gateway supports initial configuration of the following configurations:
• 2 separate listeners on 2 logical IPv4 and 2 IPv6 addresses configured on separate physical interfaces
• segregates incoming and outgoing traffic
• you can assign an IPv4 and an IPv6 address to each listener
• 1 listener on 1 logical IPv4 address configured on one physical interface
• combines both incoming and outgoing traffic
• you can assign both an IPv4 and an IPv6 address to the listener
The email gateway can support both IPv4 and IPv6 addresses on single listener. The listener will accept mail
on both the addresses. All settings on a listener apply to both IPv4 and IPv6 addresses.
Choosing Network Settings for Your Connections
You will need the following network information about each Ethernet port that you choose to use:
• IP address (IPv4 or IPv6 or both)
• Netmask for IPv4 address in CIDR format
• Prefix for IPv6 address in CIDR format
In addition, you will need the following information about your overall network:
• IP address of the default router ( gateway) on your network
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
34
Setup and Installation
Gathering the Setup Information
• IP address and hostname of your DNS servers (not required if you want to use Internet root servers)
• Hostname or IP address of your NTP servers (not required if you want to use Cisco’s time servers)
See Assigning Network and IP Addresses, on page 1303 for more information.
Note If you are running a firewall on your network between the Internet and the email gateway, it may be necessary
to open specific ports for the email gateway to work properly. See Firewall Information, on page 1325 for more
information.
Gathering the Setup Information
Now that you understand the requirements and strategies when making the necessary selections in the System
Setup Wizard, use the following tables to gather information about your system setup while reading this
section.
See Assigning Network and IP Addresses, on page 1303 for more detailed information on network and IP
addresses. See Centralizing Services on a Cisco Secure Email and Web Manager (M-Series), on page 1285 if
you are configuring a Cisco Secure Email and Web Manager.
Table 4: System Setup Worksheet: 2 Listeners for Segregating Email Traffic
System Settings
Default System Hostname:
Email System Alerts To:
Deliver Scheduled Reports To:
Time Zone Information:
NTP Server:
Admin Passphrase:
SenderBase Network Participation: Enable / Disable
AutoSupport: Enable / Disable
Network Integration
Gateway:
DNS (Internet or Specify Own):
Interfaces
Data 1 Port
IPv4 Address / Netmask:
IPv6 Address / Prefix:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
35
Setup and Installation
Gathering the Setup Information
System Settings
Fully Qualified Hostname:
Accept Incoming Mail: Domain Destination
Relay Outgoing Mail: System
Data 2 Port
IPv4 Address / Netmask:
IPv6 Address / Prefix:
Fully Qualified Hostname:
Accept Incoming Mail: Domain Destination
Relay Outgoing Mail: System
Management Port
IP Address:
Network Mask:
IPv6 Address:
Prefix:
Fully Qualified Hostname:
Accept Incoming Mail: Domain Destination
Relay Outgoing Mail: System
Message Security
IP Reputation Filtering: Enable / Disable
Anti-Spam Scanning Engine None / IronPort
McAfee Anti-Virus Scanning Enable / Disable
Engine
Sophos Anti-Virus Scanning Enable / Disable
Engine
Outbreak Filters Enable / Disable
Table 5: System Setup Worksheet: 1 Listener for All Email Traffic
System Settings
Default System Hostname:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
36
Setup and Installation
Gathering the Setup Information
System Settings
Email System Alerts To:
Deliver Scheduled Reports To:
Time Zone:
NTP Server:
Admin Passphrase:
SenderBase Network Participation: Enable / Disable
AutoSupport: Enable / Disable
Network Integration
Gateway:
DNS (Internet or Specify Own):
Interfaces
Data2 Port
IPv4 Address / Netmask:
IPv6 Address / Prefix:
Fully Qualified Hostname:
Accept Incoming Mail: Domain Destination
Relay Outgoing Mail: System
Data1 Port
IPv4 Address / Netmask:
IPv6 Address / Prefix:
Fully Qualified Hostname:
Message Security
IP Reputation Filtering: Enable / Disable
Anti-Spam Scanning Engine None / IronPort
McAfee Anti-Virus Scanning Enable / Disable
Engine
Sophos Anti-Virus Scanning Enable / Disable
Engine
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
37
Setup and Installation
Using the System Setup Wizard
System Settings
Outbreak Filters Enable / Disable
Using the System Setup Wizard
• Accessing the Web-Based Graphical User Interface (GUI), on page 38
• Defining Basic Configuration Using the Web-Based System Setup Wizard , on page 40
• Setting up the Connection to Active Directory, on page 48
• Proceeding to the Next Steps, on page 49
• Accessing the Command Line Interface (CLI), on page 49
• Running the Command Line Interface (CLI) System Setup Wizard, on page 50
• Configuring your system as an Enterprise Gateway , on page 63
You must use the System Setup Wizard for the initial setup in order to ensure a complete configuration. Later,
you can configure custom options not available in the System Setup Wizard.
You can run the System Setup Wizard using a browser or the command line interface (CLI). For more
information, see Accessing the Web-Based Graphical User Interface (GUI), on page 38 or Running the
Command Line Interface (CLI) System Setup Wizard, on page 50
Before you begin, complete the prerequisites at Preparing for System Setup, on page 32.
Caution If you are setting up a virtual email gateway, you will have to use the loadlicense command to load your
virtual email gateway license before running the System Setup Wizard. See the Cisco Content Security Virtual
Appliance Installation Guide for more information.
Caution The System Setup Wizard will completely reconfigure your system. You should only use the System Setup
Wizard the very first time you install the email gateway, or if you want to completely overwrite your existing
configuration.
Caution The email gateway ships with a default IP address of 192.168.42.42 on the Management port of all hardware
except C170 and C190 email gateways, which use the Data 1 port instead. Before connecting the email gateway
to your network, ensure that no other device’s IP address conflicts with this factory default setting. If you are
configuring a Cisco Secure Email and Web Manager, see Centralizing Services on a Cisco Secure Email and
Web Manager (M-Series), on page 1285.
If you are connecting multiple factory-configured content security appliances to your network, add them one
at a time, reconfiguring each appliance’s default IP address as you go.
Accessing the Web-Based Graphical User Interface (GUI)
The email gateway has a standard web-based graphical user interface, a new web-based interface for managing
the Email Security Monitor feature (Monitoring, Tracking, and Quarantine), and a command-line interface.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
38
Setup and Installation
Factory Default Username and Passphrase
To access the web-based Graphical User Interface (GUI), open your web browser and point it to 192.168.42.42.
[New Web Interface Only] You can access the new web interface in any one of the following ways:
Note The new web interface of your email gateway uses AsyncOS API HTTP/HTTPS ports (6080/6443) and
trailblazer HTTPS port (4431). You can use the trailblazerconfig command in the CLI to configure the
trailblazer HTTPS ports. Make sure that the trailblazer HTTPS port is opened on the firewall.
• When trailblazerconfig CLI command is enabled, use the following URL -
https://example.com:<trailblazer-https-port>/ng-login
where example.com is the email gateway host name and <trailblazer-https-port> is the trailblazer
HTTPS port configured on the email gateway.
For more information on the trailblazerconfig CLI command, see the Cisco Secure Email Command
Reference Guide.
• Log in to the legacy web interface and click Secure Email Gateway is getting a new look. Try it!! link
to access the new web interface.
Important Notes
• Make sure that AsyncOS API is enabled on the email gateway.
• Make sure that AsyncOS HTTPS API port is not enabled on multiple interfaces.
• You must login to the legacy web interface of the email gateway.
• If trailblazerconfig is enabled, the configured HTTPS port must be opened on the firewall. The default
HTTPS port is 4431.
Also ensure that your DNS server can resolve the hostname that you specified for accessing the email
gateway.
Related Topics
• Factory Default Username and Passphrase, on page 39
• Accessing New Web Interface in Dusk Mode, on page 40
Factory Default Username and Passphrase
If you install a new virtual or hardware email gateway, you must change the default passphrase to get complete
access to set up the email gateway. When you log in to the email gateway for the first time, the web interface
prompts you to change the default passphrase, and the CLI limits the access to the following commands till
you change the default passphrase.
• Commit
• Interfaceconfig
• passphrase
• Loadconfig
• Systemsetup
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
39
Setup and Installation
Accessing the Legacy Web Interface
• loadlicense (for virtual email gateways)
• feature key
• Ping
• Telnet
• netstat
• Username: admin
• Passphrase: ironport
For Example:
login: admin
passphrase: ironport
Note If your session times out, you will be asked to re-enter your username and passphrase. If your session times
out while you are running the System Setup Wizard, you will have to start over again.
Accessing the Legacy Web Interface
To access the legacy web interface from the new web interface, click on the gear icon as shown in the
following figure:
Figure 3: Accessing the Legacy Web Interface from the
The legacy web interface opens in a new browser window. You must log in again to access it.
If you want to log out of the appliance completely, you need to log out of both the new and legacy web
interfaces of your email gateway.
Accessing New Web Interface in Dusk Mode
Dusk Mode is a reversed color scheme that utilizes light-colored typography, UI elements, and iconography
on dark backgrounds.
You can now access the new web interface of your email gateway using the dusk mode.
To switch to the dusk mode, click on the user icon on the top-right corner of the new web interface and select
Dusk Theme.
Defining Basic Configuration Using the Web-Based System Setup Wizard
Procedure
Step 1 Launch the System Setup Wizard
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
40
Setup and Installation
Step 1: Start
• Log in to the graphical user interface as described in Accessing the Web-Based Graphical User Interface
(GUI), on page 38.
• On brand new (not upgraded from previous releases of AsyncOS) systems, your browser will automatically
be redirected to the System Setup Wizard.
• Otherwise, on the System Administration tab, click System Setup Wizard in the list of links on the left.
Step 2 Start. See Step 1: Start, on page 41.
• Read and accept the license agreement
Step 3 System. See Step 2: System, on page 42.
• Setting the hostname of the email gateway
• Configuring alert settings, report delivery settings, and AutoSupport
• Setting the system time settings, and NTP server
• Resetting the admin passphrase
• Enabling Service Logs
Step 4 Network. See Step 3: Network, on page 43.
• Defining the default router and DNS settings
• Enabling and configuring network interfaces, including:Configuring incoming mail (inbound
listener)Defining SMTP routes (optional) Configuring outgoing mail (outbound listener) and defining
systems allowed to relay mail through the email gateway (optional)
Step 5 Security. Se Step 4: Security, on page 47.
• Enabling IP Reputation Filtering
• Enabling the Anti-Spam service
• Enabling the Spam Quarantine
• Enabling the Anti-Virus service
• Enabling Advanced Malware Protection (file reputation and analysis services.)
• Enabling the Outbreak Filters service
Step 6 Review. See Step 5: Review, on page 48.
• Reviewing your setup and installing the configuration
• At the end of the process, you are prompted to
Step 7 Commit the changes you have made.
Your changes will not take effect until they have been committed.
Step 1: Start
Begin by reading the license agreement. Once you have read and agreed to the license agreement, check the
box indicating that you agree and then click Begin Setup to proceed.
You can also view the text of the agreement here: https://support.ironport.com/license/eula.html
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
41
Setup and Installation
Step 2: System
Step 2: System
• Setting the Hostname, on page 42
• Configuring System Alerts, on page 42
• Configuring Report Delivery, on page 42
• Setting the Time, on page 42
• Setting the Passphrase, on page 42
• Improving Phishing Detection Efficacy using Service Logs, on page 1121
• Enabling AutoSupport, on page 43
Setting the Hostname
Define the fully-qualified hostname for the email gateway. This name should be assigned by your network
administrator.
Configuring System Alerts
Cisco AsyncOS sends alert messages via email if there is a system error that requires the user’s intervention.
Enter the email address (or addresses) to which to send those alerts.
You must add at least one email address that receives System Alerts. Enter a single email address, or separate
multiple addresses with commas. The email recipients initially receive all types of alerts at all levels, except
for Directory Harvest Attack Prevention alerts. You can add more granularity to the alert configuration later.
For more information, see Alerts, on page 1043.
Configuring Report Delivery
Enter the address to which to send the default scheduled reports. If you leave this value blank, the scheduled
reports are still run. They will be archived on the email gateway rather than delivered.
Setting the Time
Set the time zone on the email gateway so that timestamps in message headers and log files are correct. Use
the drop-down menus to locate your time zone or to define the time zone via GMT offset (see Selecting a
GMT Offset, on page 1084 for more information).
You can set the system clock time manually later, or you can use the Network Time Protocol (NTP) to
synchronize time with other servers on your network or the Internet. By default, one entry to the Cisco Systems
time servers ( time.ironport.com ) to synchronize the time on your email gateway is already configured.
Setting the Passphrase
Set the passphrase for the admin account. This is a required step. When changing the passphrase for the Cisco
AsyncOS admin account, the new passphrase must be six characters or longer. Be sure to keep the passphrase
in a secure location.
In addition to creating a login passphrase manually, you can also create a system-generated passphrase to log
in to your email gateway.
Enabling Service Logs
The ‘Service Logs’ are sent to the Cisco Talos Cloud service to improve Phishing detection.
If you enable Service Logs, the Cisco Email Security gateway collects limited personal data from customer
emails and offers extensive useful threat detection capabilities that can be coupled with dedicated analysis
systems to collect, trend, and correlate observed threat activity. Cisco uses the personal data to improve your
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
42
Setup and Installation
Enabling AutoSupport
email gateway capabilities to analyze the threat landscape, provide threat classification solutions on malicious
emails, and to protect your email gateway from new threats such as spam, virus, and directory harvest attacks.
See Improving Phishing Detection Efficacy using Service Logs, on page 1121 for more information.
Enabling AutoSupport
The AutoSupport feature (enabled by default) keeps the Cisco Customer Support team aware of issues with
your email gateway so that we can provide better support to you. (For more information, see AutoSupport,
on page 1044.)
Click Next to continue.
Step 3: Network
In Step 3, you define the default router (gateway) and configure the DNS settings, and then set up the email
gateway to receive and or relay email by configuring the Data 1, Data 2, and Management interfaces.
• Configuring DNS and Default Gateway, on page 43
• Configuring Network Interfaces, on page 43
• Accepting Mail, on page 44
• Relaying Mail (Optional), on page 45
• C170 and C190 Installations, on page 46
Configuring DNS and Default Gateway
Type the IP address of the default router (gateway) on your network. You can use an IPv4 address, an IPv6
address, or both.
Next, configure the DNS (Domain Name Service) settings. Cisco AsyncOS contains a high-performance
internal DNS resolver/cache that can query the Internet’s root servers directly, or the system can use DNS
servers you specify. If you choose to use your own servers, you will need to supply the IP address and hostname
of each DNS server. You can enter up to four DNS servers via the System Setup Wizard. Please note that
DNS servers you enter will have an initial priority of 0. For more information, see Configuring Domain Name
System (DNS) Settings, on page 1067.
Note The email gateway requires access to a working DNS server in order to perform DNS lookups for incoming
connections. If you cannot specify a working DNS server that is reachable by the email gateway while you
are setting up the email gateway, a workaround is to either select “Use Internet Root DNS Servers” or to
specify, temporarily, the IP address of the Management interface so that you can complete the System Setup
Wizard.
Configuring Network Interfaces
Your email gateway has network interfaces that are associated with the physical Ethernet ports on the machine.
To use an interface, mark the “Enable” checkbox and then specify an IP address, network mask, and fully
qualified hostname. The IP address you enter should be the address intended for your inbound mail as reflected
in your DNS records. Typically this address would have an MX record associated with it in DNS. You can
use an IPv4 address, an IPv6 address, or both. If you use both, the interface will accept both types of
connections.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
43
Setup and Installation
Accepting Mail
Each interface can be configured to accept mail (incoming), relay email (outgoing), or appliance management.
During setup, you are limited to one of each. On most email gateways, you would typically use one interface
for incoming, one for outgoing, and one for appliance management. On the C170 and C190 email gateways,
you would typically use one interface for both incoming and outgoing mail, and the other interface for
management.
You must configure one interface to receive email.
Assign and configure a logical IP address to one of the physical Ethernet interfaces on the email gateway. If
you decide to use both the Data 1 Ethernet port and the Data 2 Ethernet port, you need this information for
both connections.
For C390, and C690 appliances: Cisco recommends using one of the physical Ethernet ports to connect
directly to the Internet for the purposes of receiving inbound email through public listeners, and using another
physical Ethernet port to connect directly to your internal network for the purposes of relaying outbound email
through private listeners.
For C190 appliances: Typically, the System Setup Wizard will configure only one physical Ethernet port
with one listener for both receiving inbound email and relaying outbound email.
See Binding Logical IP Addresses to Physical Ethernet Ports, on page 34.
The following information is required:
• The IP address assigned by your network administrator. This can be an IPv4 address, an IPv6 address,
or both.
• For IPv4 addresses: the netmask of the interface. AsyncOS only accepts a netmask in CIDR format. For
example, /24 for the 255.255.255.0 subnet.
For IPv6 addresses: the prefix in CIDR format. For example /64 for a 64-bit prefix.
• (optional) A fully-qualified hostname for the IP address.
Note IP addresses within the same subnet cannot be configured on separate physical Ethernet interfaces. See
Assigning Network and IP Addresses, on page 1303 for more detailed information on Network and IP Address
configuration.
Accepting Mail
When configuring your interfaces to accept mail, you define:
• the domain for which to accept mail
• destination (SMTP Route) for each domain, this is optional
Mark the checkbox for Accept Incoming Mail to configure the interface to accept mail. Enter the name of the
domain for which to accept mail.
Enter the Destination. This is the SMTP Route or name of the machine(s) where you would like to route email
for the domains specified.
This is the first SMTP Routes entry. The SMTP Routes table allows you to redirect all email for each domain
(also known as a Recipient Access Table (RAT) entry) you enter to a specific mail exchange (MX) host. In
typical installations, the SMTP Routes table defines the specific groupware (for example, Microsoft Exchange)
server or the “next hop” in the email delivery for your infrastructure.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
44
Setup and Installation
Relaying Mail (Optional)
For example, you can define a route that specifies that mail accepted for the domain example.com and all of
its subdomains .example.com is routed the to the groupware server exchange.example.com .
You can enter multiple domains and destinations. Click Add Row to add another domain. Click the trash can
icon to remove a row.
Note Configuring SMTP Routes in this step is optional. If no SMTP routes are defined, the system will use DNS
to lookup and determine the delivery host for the incoming mail received by the listener. (See Routing Email
for Local Domains, on page 697.)
You must add at least one domain to the Recipient Access Table. Enter a domain — example.com , for example.
To ensure that mail destined for any subdomain of example.net will match in the Recipient Access Table,
enter .example.net as well as the domain name. For more information, see Defining Recipient Addresses,
on page 136.
Relaying Mail (Optional)
When configuring your interfaces to relay mail, you define the systems allowed to relay email through the
email gateway.
These are entries in the RELAYLIST of the Host Access Table for a listener. See Sender Group Syntax, on
page 103 for more information.
Mark the check box for Relay Outgoing Mail to configure the interface to relay mail. Enter the hosts that may
relay mail through the email gateway.
When you configure an interface to relay outbound mail, the System Setup Wizard turns on SSH for the
interface as long as no public listeners are configured to use the interface.
In the following example, two interfaces with IPv4 addresses are created:
• 192.168.42.42 remains configured on the Management interface.
• 192.168.1.1 is enabled on the Data 1 Ethernet interface. It is configured to accept mail for domains ending
in .example.com and an SMTP route is defined for exchange.example.com.
• 192.168.2.1 is enabled on the Data 2 Ethernet interface. It is configured to relay mail from
exchange.example.com.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
45
Setup and Installation
C390, and C690 Installations
C390, and C690 Installations
Figure 4: Network Interfaces: 2 Interfaces in Addition to Management (Segregated Traffic)
C170 and C190 Installations
For C170 and C190 appliances, the Data 2 interface is typically configured for both incoming and outgoing
mail while the Data 1 interface is used for appliance management.
When configuring a single IP address for all email traffic (nonsegregated traffic), step 3 of the System Setup
Wizard will look like this:
Figure 5: Network Interfaces: 1 IP Address for Incoming and Outgoing (Nonsegregated) Traffic
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
46
Setup and Installation
Step 4: Security
Click Next to continue.
Step 4: Security
In step 4, you configure anti-spam and anti-virus settings. The anti-spam options include IP Reputation Filtering
and selecting an anti-spam scanning engine. For anti-virus, you can enable Outbreak Filters and Sophos or
McAfee anti-virus scanning.
• Enabling IP Reputation Filtering, on page 47
• Enabling Anti-Spam Scanning, on page 47
• Enabling Anti-Virus Scanning, on page 47
• Enabling Advanced Malware Protection (File Reputation and Analysis Services) , on page 47
• Enabling Outbreak Filters, on page 48
Enabling IP Reputation Filtering
The IP Reputation Service can be used as a stand-alone anti-spam solution, but it is primarily designed to
improve the effectiveness of a content-based anti-spam system such as Anti-Spam.
The IP Reputation Service provides an accurate, flexible way for users to reject or throttle suspected spam
based on the connecting IP address of the remote host. The IP Reputation Service returns a score based on
the probability that a message from a given source is spam. The IP Reputation Service is unique in that it
provides a global view of email message volume and organizes the data in a way that makes it easy to identify
and group related sources of email. Cisco strongly suggests that you enable IP Reputation Filtering.
Once enabled, IP Reputation Filtering is applied on the incoming (accepting) listener.
Enabling Anti-Spam Scanning
Your email gateway may ship with a 30-day evaluation key for Anti-Spam software. During this portion of
the System Setup Wizard, you can choose to enable Anti-Spam globally on the email gateway. You can also
elect to not enable the service.
If you choose to enable the anti-spam service, you can configure AsyncOS to send spam and suspected spam
messages to the local Spam Quarantine. The Spam Quarantine serves as the end-user quarantine for the email
gateway. Only administrators can access the quarantine until end-user access is configured.
See Managing Spam and Graymail, on page 383 for all of the Anti-Spam configuration options available on
the email gateway. See Policy, Virus, and Outbreak Quarantines, on page 927.
Enabling Anti-Virus Scanning
Your email gateway may ship with a 30-day evaluation key for the Sophos Anti-Virus or McAfee Anti-Virus
scanning engines. During this portion of the System Setup Wizard, you can choose to enable an anti-virus
scanning engine globally on the email gateway.
If you choose to enable an anti-virus scanning engine, it is enabled for both the default incoming and default
outgoing mail policies. The email gateway scans mail for viruses, but it does not repair infected attachments.
The email gateway drops infected messages.
See Anti-Virus, on page 365 for all of the anti-virus configuration options available on the email gateway.
Enabling Advanced Malware Protection (File Reputation and Analysis Services)
Advanced Malware Protection obtains reputation information about attached files from a cloud-based service.
For more information, see File Reputation Filtering and File Analysis, on page 481
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
47
Setup and Installation
Enabling Outbreak Filters
Enabling Outbreak Filters
Your email gateway may ship with a 30-day evaluation key for Outbreak Filters. Outbreak Filters provide a
“first line of defense” against new virus outbreaks by quarantining suspicious messages until traditional
anti-virus security services can be updated with a new virus signature file.
See Outbreak Filters, on page 425 for more information.
Click Next to continue.
Step 5: Review
A summary of the configuration information is displayed. You can edit the System Settings, Network
Integration, and Message Security information by clicking the Previous button or by clicking the corresponding
Edit link in the upper-right of each section. When you return to a step to make a change, you must proceed
through the remaining steps until you reach this review page again. All settings you previously entered will
be remembered.
Once you are satisfied with the information displayed click Install This Configuration.
A confirmation dialog is displayed. Click Install to install the new configuration.
Your email gateway is now ready to send email.
Note Clicking Install will cause the connection to the current URL (http://192.168.42.42) to be lost if you changed
the IP address of the interface you used to connect to the email gateway from the default. However, your
browser will be redirected to the new IP address.
Once System Setup is complete, several alert messages are sent. See Immediate Alerts, on page 63 for more
information.
Setting up the Connection to Active Directory
If the System Setup Wizard properly installs the configuration on the email gateway, the Active Directory
Wizard appears. If you are running an Active Directory server on your network, use the Active Directory
Wizard to configure an LDAP server profile for the Active Directory server and assign a listener for recipient
validation. If you are not using Active Directory or want to configure it later, click Skip this Step. You can
run the Active Directory Wizard on the System Administration > Active Directory Wizard page. You can
also configure Active Directory and other LDAP profiles on the System Administration > LDAP page.
The Active Directory Wizard retrieves the system information needed to create an LDAP server profile, such
as the authentication method, the port, the base DN, and whether SSL is supported. The Active Directory
Wizard also creates LDAP accept and group queries for the LDAP server profile.
After the Active Directory Wizard creates the LDAP server profile, use the System Administration > LDAP
page to view the new profile and make additional changes
Procedure
Step 1 On the Active Directory Wizard page, click Run Active Directory Wizard.
Step 2 Enter the host name for the Active Directory server.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
48
Setup and Installation
Proceeding to the Next Steps
Step 3 Enter a username and passphrase for the authentication request.
Step 4 Click Next to continue.
The Active Directory Wizard tests the connection to the Active Directory server. If successful, the Test
Directory Settings page is displayed.
Step 5 Test the directory settings by entering an email address that you know exists in the Active Directory and
clicking Test. The results appear in the connection status field.
Step 6 Click Done.
Proceeding to the Next Steps
After you successfully configure your email gateway to work with your Active Directory Wizard, or skip the
process, the System Setup Next Steps page appears.
Click the links on the System Setup Next Steps page to proceed with the configuration of your email gateway.
Accessing the Command Line Interface (CLI)
Access to the CLI varies depending on the management connection method you chose in Connecting to the
Email Gateway, on page 33. The factory default username and passphrase are listed next. Initially, only the
admin user account has access to the CLI. You can add other users with differing levels of permission after
you have accessed the command line interface for the first time via the admin account. (For information about
adding users, see Adding Users , on page 980.) The System Setup Wizard asks you to change the passphrase
for the admin account. The passphrase for the admin account can also be reset directly at any time using the
passphrase command.
To connect via Ethernet: Start an SSH session with the factory default IP address 192.168.42.42. SSH is
configured to use port 22. Enter the username and passphrase below.
To connect via a Serial connection: Start a terminal session with the communication port on your personal
computer that the serial cable is connected to. Use the settings for serial port outlined in Connecting to the
Email Gateway, on page 33. Enter the username and passphrase below.
Log in to the email gateway by entering the username and passphrase.
Related Topics
• Factory Default Username and Passphrase, on page 39
Factory Default Username and Passphrase
If you install a new virtual or hardware email gateway, you must change the default passphrase to get complete
access to set up the email gateway. When you log in to the email gateway for the first time, the web interface
prompts you to change the default passphrase, and the CLI limits the access to the following commands till
you change the default passphrase.
• Commit
• Interfaceconfig
• passphrase
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
49
Setup and Installation
Running the Command Line Interface (CLI) System Setup Wizard
• Loadconfig
• Systemsetup
• loadlicense (for virtual email gateways)
• feature key
• Ping
• Telnet
• netstat
• Username: admin
• Passphrase: ironport
For Example:
login: admin
passphrase: ironport
Note If your session times out, you will be asked to re-enter your username and passphrase. If your session times
out while you are running the System Setup Wizard, you will have to start over again.
Running the Command Line Interface (CLI) System Setup Wizard
The CLI version of the System Setup Wizard basically mirrors the steps in the GUI version, with a few minor
exceptions:
• The CLI version includes prompts to enable the web interface.
• The CLI version allows you to edit the default Mail Flow Policy for each listener you create.
• The CLI version contains prompts for configuring the global Anti-Virus and Outbreak Filters security
settings.
• The CLI version does not prompt you to create an LDAP profile after the system setup is complete. Use
the ldapconfig command to create an LDAP profile.
To run the System Setup Wizard, type systemsetup at the command prompt.
IronPort> systemsetup
The System Setup Wizard warns you that you will reconfigure your system. If this is the very first time you
are installing the email gateway, or if you want to completely overwrite your existing configuration, answer
“Yes” to this question.
WARNING: The system setup wizard will completely delete any existing
'listeners' and all associated settings including the 'Host Access Table' -
mail operations may be interrupted.
Are you sure you wish to continue? [Y]> Y
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
50
Setup and Installation
Change the Admin Passphrase
Note The remainder of the system setup steps are described below. Examples of the CLI System Setup Wizard
dialogue will only be included for sections that deviate from the GUI System Setup Wizard described above
in Defining Basic Configuration Using the Web-Based System Setup Wizard , on page 40.
Related Topics
• Change the Admin Passphrase, on page 51
• Accept the License Agreement, on page 51
• Set the Hostname , on page 51
• Assign and Configure Logical IP Interface(s), on page 52
• Specify the Default Gateway, on page 52
• Enable the Web Interface, on page 53
• Configure the DNS Settings, on page 53
• Create a Listener, on page 53
• Enable Anti-Spam, on page 60
• Select a Default Anti-Spam Scanning Engine, on page 61
• Enable the Spam Quarantine, on page 61
• Enable Anti-Virus Scanning, on page 61
• Enable Outbreak Filters , on page 61
• Configure the Alert Settings and AutoSupport, on page 62
• Configure Scheduled Reporting, on page 62
• Configure Time Settings, on page 62
• Commit Changes, on page 62
• Test the Configuration, on page 62
• Immediate Alerts, on page 63
Change the Admin Passphrase
First, you change the passphrase for the AsyncOS admin account. You must enter the old passphrase to
continue. The new passphrase must be six characters or longer. Be sure to keep the passphrase in a secure
location. Changes made to the passphrase are effective once the system setup process is finished.
In addition to creating a login passphrase manually, you can also create a system-generated passphrase to log
in to your email gateway.
Accept the License Agreement
Read and accept the software license agreement that is displayed.
Set the Hostname
Next, you define the fully-qualified hostname for the email gateway. This name should be assigned by your
network administrator.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
51
Setup and Installation
Assign and Configure Logical IP Interface(s)
Assign and Configure Logical IP Interface(s)
The next step assigns and configures a logical IP interface on the physical Ethernet interface named Management
(on C390, and C690 appliances) or Data 1 (on C190 appliances), and then prompts you to configure a logical
IP interface on any other physical Ethernet interfaces available on the email gateway.
Each Ethernet interface can have multiple IP interfaces assigned to it. An IP interface is a logical construct
that associates an IP address and hostname with a physical Ethernet interface. If you decided to use both the
Data 1 and Data 2 Ethernet ports, you need the IP addresses and hostnames for both connections.
For C390, and C690 appliances: Cisco recommends using one of the physical Ethernet ports to connect
directly to the Internet for the purposes of receiving inbound email through public listeners, and using another
physical Ethernet port to connect directly to your internal network for the purposes of relaying outbound email
through private listeners.
For C190 appliances: By default, the systemsetup command will configure only one physical Ethernet port
with one listener for receiving inbound email and relaying outbound email.
Note When you configure an interface to relay outbound mail, the system turns on SSH for the interface as long
as no public listeners are configured to use the interface.
The following information is required:
• A name (nickname) created by you to refer to the IP interface later. For example, if you are using one
Ethernet port for your private network and the other for the public network, you may want to name them
PrivateNet and PublicNet, respectively.
Note The names you define for interfaces are case-sensitive. AsyncOS will not allow
you to create two identical interface names. For example, the names Privatenet
and PrivateNet are considered as two different (unique) names.
• The IP address assigned by your network administrator. This is can be an IPv4 or IPv6 address, You
can assign both types of IP addresses to a single IP interface.
• The netmask of the interface. The netmask must be in CIDR format. For example, use /24 for the
255.255.255.0 subnet.
Note IP addresses within the same subnet cannot be configured on separate physical
Ethernet interfaces. See Assigning Network and IP Addresses, on page 1303 for
more detailed information on Network and IP Address configuration.
For C190 appliances, the Data 2 interface is configured first.
Specify the Default Gateway
In the next portion of the systemsetup command, you type the IP address of the default router (gateway) on
your network.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
52
Setup and Installation
Enable the Web Interface
Enable the Web Interface
In the next portion of the systemsetup command, you enable the web interface for the email gateway (for
the Management Ethernet interface). You can also choose to run the web interface over secure HTTP ( https
). If you choose to use HTTPS, the system will use a demonstration certificate until you upload your own
certificate.
Configure the DNS Settings
Next, you configure the DNS (Domain Name Service) settings. Cisco AsyncOS contains a high-performance
internal DNS resolver/cache that can query the Internet’s root servers directly, or the system can use your
own DNS servers. If you choose to use your own servers, you will need to supply the IP address and hostname
of each DNS server. You can enter as many DNS servers as you need (each server will have a priority of 0.).
By default, systemsetup prompts you to enter the addresses for your own DNS servers.
Create a Listener
A “listener” manages inbound email processing services that will be configured on a particular IP interface.
Listeners only apply to email entering the email gateway — either from your internal systems or from the
Internet. Cisco AsyncOS uses listeners to specify criteria that messages must meet in order to be accepted
and relayed to recipient hosts. You can think of a listener as an email listener (or even a “SMTP daemon”)
running for IP addresses you specified above.
For C390, and C690 appliances: By default, the systemsetup command configures two listeners — one
public and one private. (For more information on the types of listeners available, see Configuring the Gateway
to Receive Email, on page 77.)
For C190 appliances: By default, the systemsetup command configures one public listener for both receiving
mail from the Internet and for relaying email from your internal network. See Listener Example for C190
Appliances , on page 58.
When you define a listener, you specify the following attributes:
• A name (nickname) created by you to refer to the listener later. For example, the listener that accepts
email from your internal systems to be delivered to the Internet may be called OutboundMail.
• One of the IP interfaces (that you created earlier in the systemsetup command) on which to receive
email.
• The name of the machine(s) to which you want to route email (public listeners only). (This is the first
smtproutes entry. See Routing Email for Local Domains, on page 697.)
• Whether or not to enable filtering based on IP Reputation Scores for public listeners. If enabled, you are
also prompted to select between Conservative, Moderate, or Aggressive settings.
• Rate-limiting per host: the maximum number of recipients per hour you are willing to receive from a
remote host (public listeners only).
• The recipient domains or specific addresses you want to accept email for (public listeners) or the systems
allowed to relay email through the email gateway (private listeners). (These are the first Recipient Access
Table and Host Access Table entries for a listener. See Sender Group Syntax, on page 103 and Adding
Domains and Users For Which to Accept Messages, on page 135 for more information.)
Related Topics
• Public Listener, on page 54
• Private Listener, on page 56
• Listener Example for C190 Appliances , on page 58
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
53
Setup and Installation
Public Listener
Public Listener
Note The following examples of creating a public and private listener apply to C390, and C690 appliances only.
For C190 appliances, skip to the next section, Listener Example for C190 Appliances , on page 58.
In this example portion of the systemsetup command, a public listener named InboundMail is configured to
run on the PublicNet IP interface. Then, it is configured to accept all email for the domain example.com . An
initial SMTP route to the mail exchange exchange.example.com is configured. Rate limiting is enabled, and
the maximum value of 4500 recipients per hour from a single host is specified for the public listener.
Note The value you enter for maximum recipients per hour you are willing to receive from a remote host is a
completely arbitrary value, one that is usually relative to the size of the enterprise for which you are
administering email. For example, a sender who sends 200 messages in an hour might be considered a
“spammer” (sender of unsolicited bulk email), but if you are configuring the email gateway to handle all email
for a 10,000 person company, 200 messages per hour from a remote host may be a reasonable value. Conversely,
in a 50-person company, someone sending 200 messages in an hour to you may be an obvious spammer. You
must choose an appropriate value when you enable rate-limiting on a public listener (throttle) inbound email
for your enterprise. For more information on Default Host Access policies, see Sender Group Syntax, on page
103.
The default host access policy for the listener is then accepted.
You are now going to configure how the appliance accepts mail by
creating a "Listener".
Please create a name for this listener (Ex: "InboundMail"):
[]> InboundMail
Please choose an IP interface for this Listener.
1. Management (192.168.42.42/24: mail3.example.com)
2. PrivateNet (192.168.1.1/24: mail3.example.com)
3. PublicNet (192.168.2.1/24: mail3.example.com)
[1]> 3
Enter the domains or specific addresses you want to accept mail for.
Hostnames such as "example.com" are allowed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
54
Setup and Installation
Public Listener
Partial hostnames such as ".example.com" are allowed.
Usernames such as "postmaster@" are allowed.
Full email addresses such as "[email protected]" or "joe@[1.2.3.4]" are allowed.
Separate multiple addresses with commas.
[]> example.com
Would you like to configure SMTP routes for example.com? [Y]> y
Enter the destination mail server which you want mail for example.com to be delivered.
Separate multiple entries with commas.
[]> exchange.example.com
Do you want to enable rate limiting for this listener? (Rate limiting defines the maximum
number
of recipients per hour you are willing to receive from a remote domain.) [Y]> y
Enter the maximum number of recipients per hour to accept from a remote domain.
[]> 4500
Default Policy Parameters
==========================
Maximum Message Size: 100M
Maximum Number Of Connections From A Single IP: 1,000
Maximum Number Of Messages Per Connection: 1,000
Maximum Number Of Recipients Per Message: 1,000
Maximum Number Of Recipients Per Hour: 4,500
Maximum Recipients Per Hour SMTP Response:
452 Too many recipients received this hour
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
55
Setup and Installation
Private Listener
Use SenderBase for Flow Control: Yes
Virus Detection Enabled: Yes
Allow TLS Connections: No
Would you like to change the default host access policy? [N]> n
Listener InboundMail created.
Defaults have been set for a Public listener.
Use the listenerconfig->EDIT command to customize the listener.
*****
Private Listener
In this example portion of the systemsetup command, a private listener named OutboundMail is configured
to run on the PrivateNet IP interface. Then, it is configured to relay all email for all hosts within the domain
example.com . (Note the dot at the beginning of the entry: .example.com )
The default value for rate limiting (not enabled) and the default host access policy for this listener are then
accepted.
Note that the default values for a private listener differ from the public listener created earlier. For more
information, see Working with Listeners, on page 78.
Do you want to configure the appliance to relay mail for internal hosts? [Y]> y
Please create a name for this listener (Ex: "OutboundMail"):
[]> OutboundMail
Please choose an IP interface for this Listener.
1. Management (192.168.42.42/24: mail3.example.com)
2. PrivateNet (192.168.1.1/24: mail3.example.com)
3. PublicNet (192.168.2.1/24: mail3.example.com)
[1]> 2
Please specify the systems allowed to relay email through the appliance.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
56
Setup and Installation
Private Listener
Hostnames such as "example.com" are allowed.
Partial hostnames such as ".example.com" are allowed.
IP addresses, IP address ranges, and partial IP addressed are allowed.
Separate multiple entries with commas.
[]> .example.com
Do you want to enable rate limiting for this listener?
(Rate limiting defines the maximum number of recipients per hour you are willing
to receive from a remote domain.) [N]> n
Default Policy Parameters
==========================
Maximum Message Size: 100M
Maximum Number Of Connections From A Single IP: 600
Maximum Number Of Messages Per Connection: 10,000
Maximum Number Of Recipients Per Message: 100,000
Maximum Number Of Recipients Per Hour: Disabled
Use SenderBase for Flow Control: No
Virus Detection Enabled: Yes
Allow TLS Connections: No
Would you like to change the default host access policy? [N]> n
Listener OutboundMAil created.
Defaults have been set for a Private listener.
Use the listenerconfig->EDIT command to customize the listener.
*****
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
57
Setup and Installation
Listener Example for C190 Appliances
Listener Example for C190 Appliances
Note The following example of creating a listener applies to C170 and C190 appliances only.
In this example portion of the systemsetup command, a listener named MailInterface is configured to run on
the MailNet IP interface. Then, it is configured to accept all email for the domain example.com . An initial
SMTP route to the mail exchange exchange.example.com is configured. Then, the same listener is configured
to relay all email for all hosts within the domain example.com . (Note the dot at the beginning of the entry:
.example.com )
Rate limiting is enabled, and the maximum value of 450 recipients per hour from a single host is specified
for the public listener.
Note The value you enter for maximum recipients per hour you are willing to receive from a remote host is a
completely arbitrary value, one that is usually relative to the size of the enterprise for which you are
administering email. For example, a sender who sends 200 messages in an hour might be considered a
“spammer” (sender of unsolicited bulk email), but if you are configuring the email gateway to handle all email
for a 10,000 person company, 200 messages per hour from a remote host may be a reasonable value. Conversely,
in a 50-person company, someone sending 200 messages in an hour to you may be an obvious spammer. You
must choose an appropriate value when you enable rate-limiting on a public listener (throttle) inbound email
for your enterprise. For more information on Default Host Access policies, see Sender Group Syntax, on page
103.
The default host access policy for the listener is then accepted.
You are now going to configure how the appliance accepts mail by creating a "Listener".
Please create a name for this listener (Ex: "MailInterface"):
[]> MailInterface
Please choose an IP interface for this Listener.
1. MailNet (10.1.1.1/24: mail3.example.com)
2. Management (192.168.42.42/24: mail3.example.com)
[1]> 1
Enter the domain names or specific email addresses you want to accept mail for.
Hostnames such as "example.com" are allowed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
58
Setup and Installation
Listener Example for C190 Appliances
Partial hostnames such as ".example.com" are allowed.
Usernames such as "postmaster@" are allowed.
Full email addresses such as "[email protected]" or "joe@[1.2.3.4]" are allowed.
Separate multiple addresses with commas.
[]> example.com
Would you like to configure SMTP routes for example.com? [Y]> y
Enter the destination mail server where you want mail for example.com to be delivered.
Separate multiple entries with commas.
[]> exchange.example.com
Please specify the systems allowed to relay email through the appliance.
Hostnames such as "example.com" are allowed.
Partial hostnames such as ".example.com" are allowed.
IP addresses, IP address ranges, and partial IP addresses are allowed.
Separate multiple entries with commas.
[]> .example.com
Do you want to enable rate limiting for this listener?
(Rate limiting defines the maximum number of recipients per hour you are willing
to receive from a remote domain.) [Y]> y
Enter the maximum number of recipients per hour to accept from a remote domain.
[]> 450
Default Policy Parameters
==========================
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
59
Setup and Installation
Enable Anti-Spam
Maximum Message Size: 10M
Maximum Number Of Connections From A Single IP: 50
Maximum Number Of Messages Per Connection: 100
Maximum Number Of Recipients Per Message: 100
Maximum Number Of Recipients Per Hour: 450
Maximum Recipients Per Hour SMTP Response:
452 Too many recipients received this hour
Use SenderBase for Flow Control: Yes
Spam Detection Enabled: Yes
Virus Detection Enabled: Yes
Allow TLS Connections: No
Would you like to change the default host access policy? [N]>
Listener MailInterface created.
Defaults have been set for a Public listener.
Use the listenerconfig->EDIT command to customize the listener.
*****
Note Because the systemsetup command only configures one listener for both inbound and outbound mail for
C170 and C190 appliances, all outgoing mail will be calculated in the Mail Flow Monitor feature (which is
normally used for inbound messages). See Using Email Security Monitor, on page 833
Enable Anti-Spam
Your email gateway ships with a 30-day evaluation key for the Anti-Spam software. During this portion of
the systemsetup command, you can choose to accept the license agreements and enable Anti-Spam globally
on the email gateway.
Anti-Spam scanning will then be enabled on the incoming mail policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
60
Setup and Installation
Select a Default Anti-Spam Scanning Engine
Note If you do not accept the license agreement, Anti-Spam is not enabled on the email gateway.
See Managing Spam and Graymail, on page 383 for all of the Anti-Spam configuration options available on
the email gateway.
Select a Default Anti-Spam Scanning Engine
If you have enabled more than one anti-spam scanning engine, you are prompted to select which engine will
be enabled for use on the default incoming mail policy.
Enable the Spam Quarantine
If you choose to enable an anti-spam service, you can enable the incoming mail policy to send spam and
suspected spam messages to the local Spam Quarantine. Enabling the Spam Quarantine also enables the
end-user quarantine on the email gateway. Only administrators can access the end-user quarantine until
end-user access is configured.
See Setting Up the Local Spam Quarantine, on page 948 .
Enable Anti-Virus Scanning
Your email gateway ships with a 30-day evaluation key for virus scanning engines. During this portion of the
systemsetup command, you can choose to accept one or more license agreements and enable anti-virus
scanning on the email gateway. You must accept a license agreement for each anti-virus scanning engine you
want to enable on your email gateway.
After you accept the agreement, the anti-virus scanning engine you selected is enabled on the incoming mail
policy. The email gateway scans incoming mail for viruses, but it does not repair infected attachments. The
appliance drops infected messages.
See Anti-Virus, on page 365 for the anti-virus configuration options available on the email gateway.
Enable Outbreak Filters
This next step prompts you to enable Outbreak Filters. Your email gateway ships with a 30-day evaluation
key for Outbreak Filters.
Related Topics
• Outbreak Filters, on page 61
Outbreak Filters
Outbreak Filters provide a “first line of defense” against new virus outbreaks by quarantining suspicious
messages until traditional Anti-Virus security services can be updated with a new virus signature file. If
enabled, Outbreak Filters will be enabled on the default Incoming Mail Policy.
If you choose to enable Outbreak Filters, enter a threshold value and whether you would like to receive
Outbreak Filters alerts. For more information about Outbreak Filters and threshold values, see Outbreak Filters,
on page 425.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
61
Setup and Installation
Configure the Alert Settings and AutoSupport
Configure the Alert Settings and AutoSupport
Cisco AsyncOS sends alert messages to a user via email if there is a system error that requires the user’s
intervention. Add at least one email address that receives system alerts. Separate multiple addresses with
commas. The email addresses that you enter initially receive all types of alerts at all levels, except for Directory
Harvest Attack Prevention alerts. You can add more granularity to the alert configuration later using the
alertconfig command in the CLI or the System Administration > Alerts page in the GUI. For more
information, see section Alerts of chapter Distributing Administrative Tasks of the Cisco Secure Email
Gateway Guide.
The AutoSupport feature keeps the Cisco Customer Support team aware of issues with your email gateway
so that Cisco can provide industry-leading support to you. Answer “Yes” to send Cisco support alerts and
weekly status updates. (For more information, see section AutoSupport of chapter Distributing Administrative
Tasks of the Cisco Secure Email Gateway Guide.)
Configure Scheduled Reporting
Enter an address to which to send the default scheduled reports. You can leave this value blank and the reports
will be archived on the email gateway instead of sent via email.
Configure Time Settings
Cisco AsyncOS allows you to use the Network Time Protocol (NTP) to synchronize time with other servers
on your network or the Internet, or to manually set the system clock. You must also set the time zone on the
email gateway so that timestamps in message headers and log files are correct. You can also use the Cisco
Systems time servers to synchronize the time on your email gateway.
Choose the Continent, Country, and Timezone and whether to use NTP including the name of the NTP server
to use.
Commit Changes
Finally, the System Setup Wizard will ask you to commit the configuration changes you have made throughout
the procedure. Answer “Yes” if you want to commit the changes.
When you have successfully completed the System Setup Wizard, the following message will appear and you
will be presented with the command prompt:
Congratulations! System setup is complete. For advanced configuration, please refer to the
User Guide.
mail3.example.com>
The email gateway is now ready to send email.
Test the Configuration
To test the Cisco AsyncOS configuration, you can use the mailconfig command immediately to send a test
email containing the system configuration data you just created with the systemsetup command:
mail3.example.com> mailconfig
Please enter the email address to which you want to send
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
62
Setup and Installation
Immediate Alerts
the configuration file. Separate multiple addresses with commas.
The configuration file has been sent to [email protected].
mail3.example.com>
Send the configuration to a mailbox to which you have access to confirm that the system is able to send email
on your network.
Immediate Alerts
The email gateway uses feature keys to enable features. The first time you create a listener in the systemsetup
command, enable Anti-Spam, enable Sophos or McAfee Anti-Virus, or enable Outbreak Filters, an alert is
generated and sent to the addresses you specified in Step 2: System, on page 42.
The alert notifies you periodically of the time remaining on the key. For example:
Your "Receiving" key will expire in under 30 day(s).
Please contact IronPort Customer Support.
Your "Sophos" key will expire in under 30 day(s).
Please contact IronPort Customer Support.
Your "Outbreak Filters" key will expire in under 30 day(s).
Please contact IronPort Customer Support.
For information on enabling a feature beyond the 30-day evaluation period, contact your Cisco sales
representative. You can see how much time remains on a key via the System Administration > Feature
Keys page or by issuing the featurekey command. (For more information, see Feature Keys, on page 1008.)
Configuring your system as an Enterprise Gateway
To configure your system as an Enterprise Gateway (accepting email from the Internet), complete this chapter
first, and then see Configuring the Gateway to Receive Email, on page 77 for more information.
Verifying Your Configuration and Next Steps
Now that system setup is complete, your email gateway should be sending and receiving email. If you have
enabled the anti-virus, anti-spam, and virus-outbreak filters security features, the system will also be scanning
incoming and outgoing mail for spam and viruses.
The next step is to understand how to customize your email gateway's configuration. Understanding the Email
Pipeline, on page 65 provides a detailed overview of how email is routed through the system. Each feature
is processed in order (from top to bottom) and is described in the remaining chapters of this guide.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
63
Setup and Installation
Verifying Your Configuration and Next Steps
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
64
CHAPTER 4
Understanding the Email Pipeline
This chapter contains the following sections:
• Overview of the Email Pipeline, on page 65
• Email Pipeline Flows, on page 65
• Incoming / Receiving, on page 68
• Work Queue / Routing, on page 70
• Delivery, on page 74
Overview of the Email Pipeline
The Email Pipeline is the flow of email as it is processed by the email gateway. It has three phases:
• Receipt — As the email gateway connects to a remote host to receive incoming email, it adheres to
configured limits and other receipt policies. For example, verifying that the host can send your users
mail, enforcing incoming connection and message limits, and validating the message’s recipient.
• Work Queue — The email gateway processes incoming and outgoing mail, performing tasks such as
filtering, safelist/blocklist scanning, anti-spam and anti-virus scanning, Outbreak Filters, and quarantining.
• Delivery — As the email gateway connects to send outgoing email, it adheres to configured delivery
limits and policies. For example, enforcing outbound connection limits and processing undeliverable
messages as specified.
Email Pipeline Flows
The following figures provide an overview of how email is processed through the system, from receipt to
routing to delivery. Each feature is processed in order (from top to bottom). You can test most of the
configurations of features in this pipeline using the trace command.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
65
Understanding the Email Pipeline
Email Pipeline Flows
Figure 6: Email Pipeline — Receiving Email Connections
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
66
Understanding the Email Pipeline
Email Pipeline Flows
Figure 7: Email Pipeline — Work Queue
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
67
Understanding the Email Pipeline
Incoming / Receiving
Figure 8: Email Pipeline — Delivering Email
Incoming / Receiving
The receiving phase of the Email Pipeline involves the initial connection from the sender’s host. Each message’s
domains can be set, the recipient is checked, and the message is handed off to the work queue.
Related Topics
• Host Access Table (HAT), Sender Groups, and Mail Flow Policies, on page 68
• Received: Header, on page 69
• Default Domain, on page 69
• Bounce Verification, on page 69
• Domain Map, on page 69
• Recipient Access Table (RAT), on page 69
• Alias Tables, on page 69
• LDAP Recipient Acceptance, on page 70
• SMTP Call-Ahead Recipient Validation, on page 70
Host Access Table (HAT), Sender Groups, and Mail Flow Policies
The HAT allows you to specify hosts that are allowed to connect to a listener (that is, which hosts you will
allow to send email).
Sender Groups are used to associate one or more senders into groups, upon which you can apply message
filters, and other Mail Flow Policies. Mail Flow Policies are a way of expressing a group of HAT parameters
(access rule, followed by rate limit parameters and custom SMTP codes and responses).
Together, sender groups and mail flow policies are defined in a listener’s HAT.
Host DNS verification settings for sender groups allow you to classify unverified senders prior to the SMTP
conversation and include different types of unverified senders in your various sender groups.
While the connecting host was subject to Host DNS verification in sender groups — prior to the SMTP
conversation — the domain portion of the envelope sender is DNS verified in mail flow policies, and the
verification takes place during the SMTP conversation. Messages with malformed envelope senders can be
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
68
Understanding the Email Pipeline
Received: Header
ignored. You can add entries to the Sender Verification Exception Table — a list of domains and email
addresses from which to accept or reject mail despite envelope sender DNS verification settings.
Sender reputation filtering allows you to classify email senders and restrict access to your email infrastructure
based on sender’s trustworthiness as determined by the IP Reputation Service.
For more information, see Understanding Predefined Sender Groups and Mail Flow Policies, on page 110.
Received: Header
Using the listenerconfig command, you can configure a listener to not include the Received: header
by default to all messages received by the listener.
For more information, see Working with Listeners, on page 78.
Default Domain
You can configure a listener to automatically append a default domain to sender addresses that do not contain
fully-qualified domain names; these are also known as “bare” addresses (such as “joe” vs. “[email protected]”).
For more information, see Working with Listeners, on page 78.
Bounce Verification
Outgoing mail is tagged with a special key, and so if that mail is sent back as a bounce, the tag is recognized
and the mail is delivered. For more information, see Bounce Verification, on page 735.
Domain Map
For each listener you configure, you can construct a domain map table which rewrites the envelope recipient
for each recipient in a message that matches a domain in the domain map table. For example, [email protected]
-> [email protected]
For more information, see The Domain Map Feature, on page 720.
Recipient Access Table (RAT)
For inbound email only, the RAT allows you to specify a list of all local domains for which the email gateway
will accept mail.
For more information, see Overview of Accepting or Rejecting Connections Based on the Recipient’s Address,
on page 133.
Alias Tables
Alias tables provide a mechanism to redirect messages to one or more recipients. Aliases are stored in a
mapping table. When the envelope recipient (also known as the Envelope To, or RCPT TO ) of an email
matches an alias as defined in an alias table, the envelope recipient address of the email will be rewritten.
For more information about Alias Tables, see Creating Alias Tables, on page 703.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
69
Understanding the Email Pipeline
LDAP Recipient Acceptance
LDAP Recipient Acceptance
You can use your existing LDAP infrastructure to define how the recipient email address of incoming messages
(on a public listener) should be handled during the SMTP conversation or within the workqueue. For more
informaiton, see Working with Listeners, on page 78. This allows the email gateway to combat directory
harvest attacks (DHAP) in a unique way: the system accepts the message and performs the LDAP acceptance
validation within the SMTP conversation or the work queue. If the recipient is not found in the LDAP directory,
you can configure the system to perform a delayed bounce or drop the message entirely.
For more information, see Working with LDAP Queries, on page 785.
SMTP Call-Ahead Recipient Validation
When you configure your email gateway for SMTP call-ahead recipient validation, the email gateway suspends
the SMTP conversation with the sending MTA while it “calls ahead” to the SMTP server to verify the recipient.
When the email gateway queries the SMTP server, it returns the SMTP server’s response to the email gateway.
The email gateway resumes the SMTP conversation and sends a response to the sending MTA, allowing the
conversation to continue or dropping the connection based on the SMTP server response (and settings you
configure in the SMTP Call-Ahead profile).
For more information, see Validating Recipients Using an SMTP Server, on page 667
Work Queue / Routing
The Work Queue is where the received message is processed before moving to the delivery phase. Processing
includes masquerading, routing, filtering, safelist/blocklist scanning, anti-spam and anti-virus scanning, file
reputation scanning and analysis, Outbreak Filters, and quarantining.
Note Data loss prevention (DLP) scanning is only available for outgoing messages. For information on where DLP
message scanning occurs in the Work Queue, see Message Splintering, on page 271.
Related Topics
• Email Pipeline and Security Services, on page 70
• LDAP Recipient Acceptance, on page 70
• Masquerading or LDAP Masquerading, on page 71
• LDAP Routing, on page 71
• Message Filters, on page 71
• Email Security Manager (Per-Recipient Scanning), on page 72
• Quarantines, on page 73
Email Pipeline and Security Services
Note, as a general rule, changes to security services (anti-spam scanning, anti-virus scanning, and Outbreak
Filters) do not affect messages already in the work queue. As an example:
If a message bypasses anti-virus scanning when it first enters the pipeline because of any of these reasons:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
70
Understanding the Email Pipeline
LDAP Recipient Acceptance
• anti-virus scanning was not enabled globally for the appliance, or
• the HAT policy was to skip anti-virus scanning, or
• there was a message filter that caused the message to bypass anti-virus scanning,
then the message will not be anti-virus scanned upon release from the quarantine, regardless of whether
anti-virus scanning has been re-enabled. However, messages that bypass anti-virus scanning due to mail
policies may be anti-virus scanned upon release from a quarantine, as the mail policy's settings may have
changed while the message was in the quarantine. For example, if a message bypasses anti-virus scanning
due to a mail policy and is quarantined, then, prior to release from the quarantine, the mail policy is updated
to include anti-virus scanning, the message will be anti-virus scanned upon release from the quarantine.
Similarly, suppose you had inadvertently disabled anti-spam scanning globally (or within the HAT), and you
notice this after mail is in the work queue. Enabling anti-spam at that point will not cause the messages in the
work queue to be anti-spam scanned.
LDAP Recipient Acceptance
You can use your existing LDAP infrastructure to define how the recipient email address of incoming messages
(on a public listener) should be handled during the SMTP conversation or within the workqueue. For more
informaiton, see Working with Listeners, on page 78. This allows the email gateway to combat directory
harvest attacks (DHAP) in a unique way: the system accepts the message and performs the LDAP acceptance
validation within the SMTP conversation or the work queue. If the recipient is not found in the LDAP directory,
you can configure the system to perform a delayed bounce or drop the message entirely.
For more information, see Working with LDAP Queries, on page 785.
Masquerading or LDAP Masquerading
Masquerading is a feature that rewrites the envelope sender (also known as the sender, or MAIL FROM ) and
the To:, From:, and/or CC: headers on email processed by a private or public listener according to a table you
construct. You can specify different masquerading parameters for each listener you create in one of two ways:
via a static mapping table, or via an LDAP query.
For more information about masquerading via a static mapping table, see Configuring Masquerading, on page
710.
For more information about masquerading via an LDAP query, see Working with LDAP Queries, on page
785.
LDAP Routing
You can configure your email gateway to route messages to the appropriate address and/or mail host based
upon the information available in LDAP directories on your network.
For more information, see Working with LDAP Queries, on page 785.
Message Filters
Message filters allow you to create special rules describing how to handle messages and attachments as they
are received. Filter rules identify messages based on message or attachment content, information about the
network, message envelope, message headers, or message body. Filter actions allow messages to be dropped,
bounced, archived, quarantined, blind carbon copied, or altered.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
71
Understanding the Email Pipeline
Email Security Manager (Per-Recipient Scanning)
For more information, see Using Message Filters to Enforce Email Policies, on page 139.
Multi-recipient messages are “splintered” after this phase, prior to Email Security Manager. Splintering
messages refers to creating splinter copies of emails with single recipients, for processing via Email Security
Manager.
Email Security Manager (Per-Recipient Scanning)
• Safelist/Blocklist Scanning, on page 72
• Anti-Spam, on page 72
• Anti-Virus, on page 72
• Graymail Detection and Safe Unsubscribing, on page 73
• File Reputation Scanning and File Analysis , on page 73
• Content Filters, on page 73
• Outbreak Filters, on page 73
Safelist/Blocklist Scanning
End user safelists and blocklists are created by end users and stored in a database that is checked prior to
anti-spam scanning. Each end user can identify domains, sub domains or email addresses that they wish to
always treat as spam or never treat as spam. If a sender address is part of an end users safelist, anti-spam
scanning is skipped, and if the sender address is listed in the blocklist, the message may be quarantined or
dropped depending on administrator settings. For more information about configuring safelists and blocklists,
see Spam Quarantine, on page 947.
Anti-Spam
Anti-spam scanning offers complete, Internet-wide, server-side anti-spam protection. It actively identifies
and defuses spam attacks before they inconvenience your users and overwhelm or damage your network,
allowing you to remove unwanted mail before it reaches your users’ inboxes, without violating their privacy.
Anti-spam scanning can be configured to deliver mail to the Spam Quarantine (either on- or off-box). Messages
released from the Spam Quarantine proceed directly to the destination queue, skipping any further work queue
processing in the email pipeline.
For more information, see Managing Spam and Graymail, on page 383 .
Anti-Virus
Your email gateway includes integrated virus scanning engines. You can configure the email gateway to scan
messages and attachments for viruses on a per-“mail policy” basis. You can configure the email gateway to
take actions such as the following when a virus is found:
• attempt to repair the attachment
• drop the attachment
• modify the subject header
• add an additional X- header
• send the message to a different address or mailhost
• archive the message
• delete the message
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
72
Understanding the Email Pipeline
Graymail Detection and Safe Unsubscribing
Messages released from quarantines (see Quarantines, on page 73) are scanned for viruses. For more
information about Anti-Virus scanning, see Anti-Virus, on page 365 .
Graymail Detection and Safe Unsubscribing
You can configure the email gateway to detect graymail messages and perform secure unsubscribe on behalf
of the end user. Available actions are similar to those for anti-virus scanning.
For more information, see Managing Spam and Graymail, on page 383.
File Reputation Scanning and File Analysis
You can configure the email gateway to scan message attachments for emerging and targeted threats. Available
actions are similar to those for anti-virus scanning.
For more information, see File Reputation Filtering and File Analysis, on page 481
Content Filters
You can create content filters to be applied to messages on a per-recipient or per-sender basis. Content filters
are similar to message filters, except that they are applied later in the email pipeline — after a message has
been “splintered” into a number of separate messages for each matching Email Security Manager policy. The
functionality of content filters is applied after message filters processing and anti-spam and anti-virus scanning
have been performed on a message.
For more information about Content Filters, see Content Filters, on page 281.
Outbreak Filters
Cisco’s Outbreak Filters feature includes special filters that act proactively to provide a critical first layer of
defense against new outbreaks. Based on Outbreak Rules published by Cisco, messages with attachments of
specific filetypes can be sent to a quarantine named Outbreak.
Messages in the Outbreak quarantine are processed like any other message in a quarantine. For more information
about quarantines and the Work Queue, see Quarantines, on page 73.
For more information, see Outbreak Filters, on page 425 .
Quarantines
You can filter incoming or outgoing messages and place them into quarantines. Quarantines are special queues
or repositories used to hold and process messages. Messages in quarantines can be delivered or deleted, based
on how you configure the quarantine.
The following Work Queue features can send messages to quarantines:
• Spam filters
• Message Filters
• Anti-Virus
• Outbreak Filters
• Content Filters
• File Analysis (Advanced Malware Protection)
Messages delivered from quarantines are re-scanned for threats.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
73
Understanding the Email Pipeline
Delivery
Related Topics
• Policy, Virus, and Outbreak Quarantines, on page 927
• Spam Quarantine, on page 947
Delivery
The delivery phase of the Email Pipeline focuses on the final phase of email processing, including limiting
connections, bounces, and recipients.
Related Topics
• Virtual gateways, on page 74
• Delivery Limits, on page 74
• Domain-Based Limits, on page 74
• Domain-Based Routing, on page 74
• Global Unsubscribe, on page 75
• Bounce Limits, on page 75
Virtual gateways
The Virtual Gateway technology enables users to separate the email gateway into multiple Virtual Gateway
addresses from which to send and receive email. Each Virtual Gateway address is given a distinct IP address,
hostname and domain, and email delivery queue.
For more information, see Configuring Mail Gateways for all Hosted Domains Using Virtual Gateway™
Technology, on page 749.
Delivery Limits
Use the deliveryconfig command to set limits on delivery, based on which IP interface to use when delivering
and the maximum number of concurrent connections the email gateway makes for outbound message delivery.
For more information, see Set Email Delivery Parameters, on page 746.
Domain-Based Limits
For each domain, you can assign a maximum number of connections and recipients that will never be exceeded
by the system in a given time period. This “good neighbor” table is defined through the Mail Policies >
Destination Controls page (or the destconfig command).
For more information, see Controlling Email Delivery Using Destination Controls, on page 734.
Domain-Based Routing
Use the Network > SMTP Routes page (or the smtproutes command) to redirect all email for a particular
domain to a specific mail exchange (MX) host, without rewriting the envelope recipient.
For more information, see Routing Email for Local Domains, on page 697.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
74
Understanding the Email Pipeline
Global Unsubscribe
Global Unsubscribe
Use Global Unsubscribe to ensure that specific recipients, recipient domains, or IP addresses never receive
messages from the email gateway. If Global Unsubscribe is enabled, the system will check all recipient
addresses against a list of “globally unsubscribed” users, domains, email addresses, and IP Addresses. Matching
emails are not sent.
For more information, see Using Global Unsubscribe, on page 757.
Bounce Limits
You use the Network > Bounce Profiles page (or the bounceconfig command) to configure how AsyncOS
handles hard and soft conversational bounces for each listener you create. You create bounce profiles and
then apply profiles to each listener using the Network > Listeners page (or the listenerconfig command).
You can also assign bounce profiles to specific messages using message filters.
For more information about bounce profiles, see Directing Bounced Email, on page 726.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
75
Understanding the Email Pipeline
Bounce Limits
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
76
CHAPTER 5
Configuring the Gateway to Receive Email
This chapter contains the following sections:
• Overview of Configuring the Gateway to Receive Email, on page 77
• Working with Listeners, on page 78
• Configuring Global Settings for Listeners, on page 80
• Listening for Connection Requests by Creating a Listener Using Web Interface, on page 83
• Listening for Connection Requests by Creating a Listener Using CLI, on page 88
• Enterprise Gateway Configuration, on page 90
Overview of Configuring the Gateway to Receive Email
The email gateway functions as the gateway for your organization, servicing email connections, accepting
messages, and relaying them to the appropriate systems. The email gateway can service email connections
from the Internet to recipients hosts inside your network, and from systems inside your network to the Internet.
Typically, email connection requests use Simple Mail Transfer Protocol (SMTP). The appliance services
SMTP connections by default, and acts as the SMTP gateway, also known as a mail exchanger or “MX,” for
the network.
The email gateway uses listeners to service incoming SMTP connection requests, A listener describes an
email processing service that is configured on a particular IP interface. Listeners apply to email entering the
appliance, from either the Internet or from systems within your network trying to reach the Internet. Use
listeners to specify criteria that messages and connections must meet in order to be accepted and for messages
to be relayed to recipient hosts. You can think of a listener as an “SMTP daemon” running on a specific port
for each IP address specified. Also, listeners define how the email gateway communicates with systems that
try to send email to the email gateway.
You can create the following types of listeners:
• Public. Listens for and accepts email messages coming in from the Internet. Public listeners receive
connections from many hosts and direct messages to a limited number of recipients.
• Private. Listens for and accepts email messages coming from systems within the network, typically from
internal groupware and email servers (POP/IMAP), intended for recipients outside the network in the
Internet. Private listeners receive connections from a limited (known) number of hosts and direct messages
to many recipients.
When you create a listener, you also must specify the following information:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
77
Configuring the Gateway to Receive Email
Working with Listeners
• Listener properties. Define global properties that apply to all listeners, and properties specific to each
listener. For example, you can specify the IP interface and port to use for a listener, and whether it is a
public or private listener. For details on how to do this, see Working with Listeners, on page 78.
• Which hosts that are allowed to connect to the listener. Define a set of rules that control incoming
connections from remote hosts. For example, you can define remote hosts and whether or not they can
connect to the listener. For details on how to do this, see Defining Which Hosts Are Allowed to Connect
Using the Host Access Table , on page 101.
• (Public listeners only) The local domains for which the listener accepts messages. Define which
recipients are accepted by the public listener. For example, if your organization uses the domain
currentcompany.com and it previously used oldcompany.com , then you might accept messages for both
currentcompany.com and oldcompany.com . For details on how to do this, see Accepting or Rejecting
Connections Based on Domain Name or Recipient Address, on page 133.
The settings configured in the listener, including its Host Access Table and Recipient Access Table, affect
how the listener communicates with an SMTP server during the SMTP conversation. This allows the email
gateway to block a spamming host before the connection is closed.
Figure 9: Relationship between Listeners, IP Interfaces, and Physical Ethernet Interfaces
Working with Listeners
Configure listeners on the Network > Listeners page in the GUI, or using the listenerconfig command in the
CLI.
You can define global settings that apply to all listeners. For more information, see Configuring Global Settings
for Listeners, on page 80.
Consider the following rules and guidelines when working with and configuring listeners on the email gateway:
• You can define multiple listeners per configured IP interface, but each listener must use a different port.
• By default, listeners use SMTP as the mail protocol to service email connections. However, you can also
configure the appliance to service email connections using Quick Mail Queuing Protocol (QMQP). Do
this using the listenerconfig CLI command.
• Listeners support both Internet Protocol version 4 (IPv4) and version 6 (IPv6) addresses. You can use
either protocol version or both on a single listener. The listener uses the same protocol version for mail
delivery as the connecting host. For example, if the listener is configured for both IPv4 and IPv6 and
connects to a host that uses IPv6, the listener uses IPv6. However, if the listener is configured to only
use IPv6 addresses, it cannot connect to a host that is only using IPv4 addresses.
• At least one listener (with default values) is configured on the email gateway after running the System
Setup Wizard. However, when you create a listener manually, AsyncOS does not use these default IP
Reputation score values.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
78
Configuring the Gateway to Receive Email
Working with Listeners
• C170 and C190 appliances: By default, the System Setup Wizard walks you through configuring one
public listener for both receiving mail from the Internet and for relaying email from your internal network.
That is, one listener can perform both functions.
• To help test and troubleshoot the email gateway, you can create a “sinkhole” type listener instead of a
public or private listener. When you create a sinkhole listener, you choose whether messages are written
to disk or not before they are deleted. (See the “Testing and Troubleshooting” chapter for more
information.) Writing messages to disk before deleting them can help you measure the rate of receiving
and the speed of the queue. A listener that doesn’t write messages to disk can help you measure the pure
rate of receiving from your message generation systems. This listener type is only available through the
listenerconfig command in the CLI.
Figure - Public and Private Listeners on Email Gateway Models with More than Two Ethernet Interfaces
illustrates a typical email gateway configuration created by the System Setup Wizard on email gateway models
that have more than two Ethernet interfaces. Two listeners are created: a public listener to serve inbound
connections on one interface and a private listener to serve outbound connections on a second IP interface.
Figure - Public Listener on Email Gateway Models with Only Two Ethernet Interfaces illustrates a typical
email gateway configuration created by the System Setup Wizard on email gateway models that have only
two Ethernet interfaces. One public listener on a single IP interface is created to serve both inbound and
outbound connections.
Figure 10: Public and Private Listeners on Email Gateway Models with More than Two Ethernet Interfaces
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
79
Configuring the Gateway to Receive Email
Configuring Global Settings for Listeners
Figure 11: Public Listener on Email Gateway Models with Only Two Ethernet Interfaces
Note This public listener uses SMTP protocol on Port 25 of the PublicNet IP interface on the Data2 Ethernet
interface to accept messages from the Internet and to relay messages from internal systems in the .example.com
domain. IP interface MailNet sends messages to destination hosts on the Internet and to internal mail hosts
Configuring Global Settings for Listeners
Global settings for the listeners affect all of the listeners that are configured on the email gateway. If the
listener uses an interface that has both Internet Protocol version 4 (IPv4) and version 6 (IPv6) addresses, the
listener settings apply to both IPv4 and IPv6 traffic
Procedure
Step 1 Choose Network > Listeners.
Step 2 Click Edit Global Settings.
Step 3 Make changes to the settings defined in the following table.
Table 6: Listener Global Settings
Global Setting Description
Maximum Concurrent Set the maximum number of concurrent connections for listeners. The default value
Connections is 300 for the C3x0 and C6x0 models, and the default value is 50 for the C1x0
models.. If the listener accepts both IPv4 and IPv6 connections, the number of
connections is divided between the two. For example, if the maximum concurrent
connections is 300, then the sum of IPv4 and IPv6 connections cannot exceed 300.
Maximum Concurrent Set the maximum concurrent TLS connections across all listeners combined. The
TLS Connections default value is 100. If the listener accepts both IPv4 and IPv6 TLS connections,
the number of connections is divided between the two. For example, if the maximum
concurrent connections is 100, then the sum of IPv4 and IPv6 TLS connections
cannot exceed 100.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
80
Configuring the Gateway to Receive Email
Configuring Global Settings for Listeners
Global Setting Description
Injection Counters Allows you to adjust when the injection control counters are reset. For very busy
Reset Period systems maintaining counters for a very large number of different IP addresses,
configuring the counters to be reset more frequently (for example, every 15 minutes
instead of every 60 minutes) will ensure that the data does not grow to an
unmanageable size and impact system performance.
The current default value is 1 hour. You can specify periods ranging from as little
as 1 minute (60 seconds) to as long as 4 hours (14,400 seconds).
See Injection Control Periodicity , on page 124.
Timeout Period for Set the length of time AsyncOS will allow an unsuccessful inbound connection to
Unsuccessful Inbound remain intact before closing it.
Connections
An unsuccessful connection can be an SMTP conversation in which SMTP or
ESMTP commands continue to be issued without a successful message injection
occurring. When the specified timeout is reached, the behavior is to send an error
and disconnect:
“421 Timed out waiting for successful message injection, disconnecting.”
A connection is considered unsuccessful until it successfully injects a message.
Only available for SMTP connections on public listeners. The default value is 5
minutes.
Total Time Limit for Set the length of time AsyncOS will allow an inbound connection to remain intact
All Inbound before closing it.
Connections
This setting is intended to preserve system resources by enforcing a maximum
allowable connection time. Once about 80% of this maximum connection time is
reached the following message is issued:
“421 Exceeded allowable connection time, disconnecting.”
The email gateway will attempt to disconnect when the connection exceeds 80%
of the maximum connection time in order to prevent disconnecting mid-message.
It is likely that a problem is occurring with the inbound connection if it is open long
enough to reach 80% of the maximum connection time. Keep this threshold in mind
when specifying the time limit.
Only available for SMTP connections on public listeners. The default value is 15
minutes.
Maximum size of Messages having subject size within the specified limit will be accepted and any
subject other messages will be rejected. If you set this value to 0, no limit is applied.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
81
Configuring the Gateway to Receive Email
Settings for Messages Containing Multiple Encodings
Global Setting Description
HAT delayed rejections Configure whether to perform HAT rejection at the message recipient level.By
default, HAT rejected connections will be closed with a banner message at the start
of the SMTP conversation.
When an email is rejected due to HAT “Reject” settings, AsyncOS can perform the
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. For example, you can see the mail from address and
each recipient address of the message which is blocked. Delaying HAT rejections
also makes it less likely that the sending MTA will perform multiple retries.
When you enable HAT delayed rejection, the following behavior occurs:
The MAIL FROM command is accepted, but no message object is created.
All RCPT TO commands are rejected with text explaining that access to send e-mail
is refused.
If the sending MTA authenticates with SMTP AUTH, they are granted a RELAY
policy and are allowed to deliver mail as normal.
Only configurable from the CLI listenerconfig --> setup command.
Step 4 Submit and commit your changes.
What to do next
Related Topics
• Settings for Messages Containing Multiple Encodings, on page 82
Settings for Messages Containing Multiple Encodings
You can define the behavior of the email gateway while modifying the message encoding for the following
parameters:
• Headers
• Untagged non-ASCII headers
• Mismatched footer or heading encoding
To configure this behavior, use the localeconfig command in CLI.
Note This behavior cannot be configured using web interface.
For a sample CLI transcript, see Disclaimer Stamping and Multiple Encodings, on page 658.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
82
Configuring the Gateway to Receive Email
Listening for Connection Requests by Creating a Listener Using Web Interface
Listening for Connection Requests by Creating a Listener Using
Web Interface
Procedure
Step 1 Choose Network > Listener.
Step 2 Click Add Listener.
Step 3 Configure the settings defined in the following table.
Table 7: Listener Settings
Name Unique nickname you supply for the listener, for future reference. The names you define
for listeners are case-sensitive. AsyncOS will not allow you to create two identical listener
names.
Type of Listener Choose one of the following types of listeners:
• Public. Public listeners contain default characteristics for receiving email from the
Internet.
• Private. Private listeners are intended to be used for private (internal) networks.
Interface Choose a configured email gateway IP interface and TCP port on which to create the
listener. Depending on the version of the IP address used by the interface, the listener
accepts connections from IPv4 addresses, IPv6 addresses or from both versions. By default,
SMTP uses port 25 and QMQP uses port 628.
Bounce Profile Select a bounce profile (bounce profiles created via the bounceconfig command in the
CLI are available in the list, see Creating a New Bounce Profile, on page 733).
Disclaimer Select a disclaimer to attach above or below emails (disclaimers created via the Mail
Above Policies > Text Resources page or the textconfig command in the CLI are available in
the list, see the “Text Resources” chapter.
Disclaimer Select a disclaimer to attach above or below emails (disclaimers created via the Mail
Below Policies > Text Resources page or the textconfig command in the CLI are available in
the list, see the “Text Resources” chapter).
SMTP Specify an SMTP Authentication profile.
Authentication
Profile
Certificate Specify a certificate for TLS connections to the listener (certificates added via the Network
> Certificates page or the certconfig command in the CLI are available in the list, see
Overview of Encrypting Communication with Other MTAs, on page 675).
Step 4 (Optional) Configure settings for controlling parsing in SMTP “MAIL FROM” and “RCPT TO” commands as
defined in the following table.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
83
Configuring the Gateway to Receive Email
Listening for Connection Requests by Creating a Listener Using Web Interface
Setting Description
Address Parser Choose how strictly the email gateway adheres to the RFC2821 standard using one of
Type the following parser types:
Strict Mode:
• Strict mode tries to follow RFC 2821. In Strict mode, the address parser follows
RFC 2821 rules with the following exceptions/enhancements:
• Space is allowed after the colon, as in “MAIL FROM: <[email protected]>”.
• Underscores are allowed in the domain name.
• “MAIL FROM” and “RCPT TO” commands are case-insensitive.
• Periods are not treated specially (for example, RFC 2821 does not allow a username
of “J.D.”).
Some of the additional options below may be enabled which technically would violate
RFC 2821.
Loose Mode:
The loose parser is basically the existing behavior from previous versions of AsyncOS.
It does its best to “find” an email address and:
• Ignores comments. It supports nested comments (anything found in parenthesis)
and ignores them.
• Does not require angle brackets around email addresses provided in “RCPT TO”
and “MAIL FROM” commands.
• Allows multiple nested angle brackets (it searches for the email address in the
deepest nested level).
Allow 8-bit User If enabled, allow 8-bit characters in the username portion of the address without escaping.
Names
Allow 8-bit If enabled, allow 8-bit characters in the domain portion of the address.
Domain Names
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
84
Configuring the Gateway to Receive Email
Listening for Connection Requests by Creating a Listener Using Web Interface
Setting Description
Allow Partial If enabled, will allow partial domains. Partial domains can be no domain at all, or a
Domains domain with no dots.
The following addresses are examples of partial domains:
• foo
• foo@
• foo@bar
This option must be enabled in order for the Default Domain feature to work properly.
Add Default Domain: A default domain to use for email addresses without a fully
qualified domain name. This option is disabled unless Allow Partial Domains is enabled
in SMTP Address Parsing options. This affects how a listener modifies email that it
relays by adding the “default sender domain” to sender and recipient addresses that do
not contain fully-qualified domain names. (In other words, you can customize how a
listener handles “bare” addresses).
If you have a legacy system that sends email without adding (appending) your company’s
domain to the sender address, use this to add the default sender domain. For example,
a legacy system may automatically create email that only enters the string “ joe ” as
the sender of the email. Changing the default sender domain would append “
@yourdomain.com ” to “ joe ” to create a fully-qualified sender name of
[email protected] .
Source Routing Determines behavior if source routing is detected in the “MAIL FROM” and “RCPT
TO” addresses. Source routing is a special form of an email address using multiple ‘@’
characters to specify routing (for example: @[email protected]:[email protected]). If
set to “reject,” the address will be rejected. If “strip,” the source routing portion of the
address will be deleted, and the message will be injected normally.
Unknown Address Determines behavior for when an address literal is received that the system cannot
Literals handle. Currently, this is everything except for IPv4. Thus, for example, for an IPv6
address literal, you can either reject it at the protocol level, or accept it and immediately
hard bounce it.
Recipient addresses containing literals will cause an immediate hard bounce. Sender
addresses may get delivered. If the message cannot be delivered, then the hard bounce
will hard bounce (double hard bounce).
In the case of reject, both sender and recipient addresses will be rejected immediately
at the protocol level.
Reject These Usernames that include characters (such as % or !, for example) entered here will be
Characters in User rejected.
Names
Step 5 (Optional) Configure advanced settings for customizing the behavior of the listener as defined in the following
table.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
85
Configuring the Gateway to Receive Email
Listening for Connection Requests by Creating a Listener Using Web Interface
Setting Description
Maximum The maximum number of connections allowed.
Concurrent
Connections
TCP Listen Queue The backlog of connections that AsyncOS will manage before the SMTP server accepts
Size them.
CR and LF Choose how to handle messages that contain bare CR (carriage return) and LF (line
Handling feed) characters.
• Clean. Allows the message, but converts bare CR and LF characters to CRLF
characters.
• Reject. Rejects the message.
• Allow. Allows the message.
Add Received Add a received header to all received email. A listener also modifies email that it relays
Header by adding a Received: header on each message. If you do not want to include the
Received: header, you can disable it using this option.
Note The Received: header is not added to the message within the work queue
processing. Rather, it is added when the message is enqueued for delivery
Disabling the received header is a way to ensure that your network’s topology is not
exposed by revealing the IP addresses or hostnames of internal servers on any messages
traveling outside your infrastructure. Please use caution when disabling the received
header.
Use SenderBase IP Choose whether or not to enable SenderBase IP Profiling and configure the following
Profiling setting:
• SenderBase Timeout per Connection. Define how long the appliance caches
SenderBase information per SMTP connection.
Step 6 (Optional) Configure settings for controlling LDAP queries associated with this listener as defined in the
following table.
Use these settings to enable LDAP queries on the listener. You must create the LDAP query first, before using
this option. Each type of query has a separate subsection to configure. Click the type of query to expand the
subsection.
For more information about creating LDAP queries, see LDAP Queries, on page 775.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
86
Configuring the Gateway to Receive Email
Partial Domains, Default Domains, and Malformed MAIL FROMs
Query Type Description
Accept Queries For Accept queries, select the query to use from the list. You can specify whether the
LDAP Accept occurs during the work queue processing or during the SMTP
conversation.
For LDAP Accept during the work queue processing, specify the behavior for
non-matching recipients: bounce or drop.
For LDAP Accept during the SMTP conversation, specify how to handle mail if the
LDAP server is unreachable. You can elect to allow messages or drop the connection
with a code and custom response. Finally, select whether or not to drop connections if
the Directory Harvest Attack Prevention (DHAP) threshold is reached during an SMTP
conversation.
Performing recipient validation in the SMTP conversation can potentially reduce the
latency between multiple LDAP queries. Therefore, you might notice an increased load
on your directory server when you enable conversational LDAP Accept.
See Overview of LDAP Queries, on page 775for more information.
Routing Queries For routing queries, select the query from the list. See Overview of LDAP Queries, on
page 775 for more information.
Masquerade For masquerade queries, select a query from the list, and select which address to
Queries masquerade, such as the From or CC header addresses.
See Overview of LDAP Queries, on page 775 for more information.
Group Queries For group queries, select the query from the list. See Overview of LDAP Queries, on
page 775 for more information.
Step 7 Submit and commit your changes.
What to do next
Related Topics
Partial Domains, Default Domains, and Malformed MAIL FROMs, on page 87
Partial Domains, Default Domains, and Malformed MAIL FROMs
If you enable envelope sender verification or disable allowing partial domains in SMTP Address Parsing
options for a listener, the default domain settings for that listener will no longer be used.
These features are mutually exclusive.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
87
Configuring the Gateway to Receive Email
Listening for Connection Requests by Creating a Listener Using CLI
Listening for Connection Requests by Creating a Listener Using
CLI
The following table lists some of the listenerconfig subcommands used in the tasks involved in creating and
editing listeners.
Table 8: Tasks for Creating Listeners
Tasks for Creating Listeners Command(s) and Subcommands
Create a new listener
listenerconfig -> new
Edit global settings for listeners
listenerconfig -> setup
Specify a bounce profile for the listener
bounceconfig, listenerconfig-> edit -> bounceconfig
Associate a disclaimer with the listener
textconfig, listenerconfig -> edit -> setup -> footer
Configure an SMTP Authentication
smtpauthconfig, listenerconfig -> smtpauth
Configure SMTP address parsing
textconfig, listenerconfig -> edit -> setup -> address
Configure a default domain for the listener
listenerconfig -> edit -> setup -> defaultdomain
Add a received header to email
listenerconfig -> edit -> setup -> received
Change bare CR and LF characters to CRLF
listenerconfig -> edit -> setup -> cleansmtp
Modify the Host Access Table
listenerconfig -> edit -> hostaccess
Accept email for local domains or specific
listenerconfig -> edit -> rcptaccess
users (RAT) (public listeners only)
Encrypt conversations on listeners (TLS)
certconfig, listenerconfig -> edit
Choose the certificate (TLS)
listenerconfig -> edit -> certificate
For more information about listenerconfig command, see CLI Reference Guide for AsyncOS for Cisco Secure
Email Gateway.
For information about email routing and delivery configurations, see Configuring Routing and Delivery
Features, on page 697.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
88
Configuring the Gateway to Receive Email
Advanced HAT Parameters
Related Topics
Advanced HAT Parameters, on page 89
Advanced HAT Parameters
The following table defines the syntax of advanced HAT parameters. Note that for the numeric values below,
you can add a trailing k to denote kilobytes or a trailing M to denote megabytes. Values with no letters are
considered bytes. Parameters marked with an asterisk support the variable syntax shown in the following
table.
Table 9: Advanced HAT Parameter Syntax
Parameter Syntax Values Example Values
Maximum messages per Number
max_msgs_per_session 1000
connection
Maximum recipients per Number
max_rcpts_per_msg 10000
message
1k
Maximum message size Number
max_message_size 1048576
20M
Maximum concurrent Number
max_concurrency 1000
connections allowed to this
listener
SMTP Banner Code Number
smtp_banner_code 220
SMTP Banner Text (*) String
smtp_banner_text Accepted
SMTP Reject Banner Code Number
smtp_banner_code 550
SMTP Reject Banner Text (*) String
smtp_banner_text Rejected
Override SMTP Banner on | off | default
use_override_hostname default
Hostname
String
override_hostname newhostname
Use TLS on | off | required
tls on
Use anti-spam scanning on | off
spam_check off
Use virus scanning on | off
virus_check off
Maximum Recipients per Hour Number
max_rcpts_per_hour 5k
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
89
Configuring the Gateway to Receive Email
Enterprise Gateway Configuration
Parameter Syntax Values Example Values
Maximum Recipients per Hour Number
max_rcpts_per_hour_code 452
Error Code
Maximum Recipients per Hour String
max_rcpts_per_hour_text Too manyrecipients
Text (*)
Use SenderBase on | off
use_sb on
Define IP Reputation Score -10.0- 10.0
sbrs[value1 sbrs[-10:-7.5]
:value2
]
Directory Harvest Attack Number
dhap_limit 150
Prevention: Maximum Invalid
Recipients Per Hour
Enterprise Gateway Configuration
In this configuration, the Enterprise Gateway configuration accepts email from the Internet and relays email
to groupware servers, POP/IMAP servers, or other MTAs. At the same time, the enterprise gateway accepts
SMTP messages from groupware servers and other email servers for relay to recipients on the Internet.
Figure 12: Public and Private Listeners for an Enterprise Gateway
In this configuration, at least two listeners are required:
• One listener configured specifically to accept mail from the Internet
• One listener configured specifically to accept mail from your internal groupware and email servers
(POP/IMAP)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
90
Configuring the Gateway to Receive Email
Enterprise Gateway Configuration
By creating distinct public and private listeners for different public and private networks, you can distinguish
among email for security, policy enforcement, reporting, and management. For example, email received on
public listeners is scanned by your configured anti-spam engine and the anti-virus scanning engine by default,
while email received on private listeners is not scanned.
Figure - Public and Private Listeners for an Enterprise Gateway shows one public listener (A) and one private
listener (B) configured on the email gateway in this Enterprise Gateway configuration.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
91
Configuring the Gateway to Receive Email
Enterprise Gateway Configuration
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
92
CHAPTER 6
IP Reputation Filtering
This chapter contains the following sections:
• Overview of Sender IP Reputation Filtering, on page 93
• IP Reputation Service, on page 93
• Editing IP Reputation Filtering Score Thresholds for a Listener , on page 96
• Entering Low IP Reputation Scores in the Message Subject, on page 98
Overview of Sender IP Reputation Filtering
Sender IP reputation filtering is the first layer of spam protection, allowing you to control the messages that
come through the email gateway based on senders’ trustworthiness as determined by the Sender IP Reputation
Service.
The email gateway can accept messages from known or highly reputable senders — such as customers and
partners — and deliver them directly to the end user without any content scanning. Messages from unknown
or less reputable senders can be subjected to content scanning, such as anti-spam and anti-virus scanning, and
you can also throttle the number of messages you are willing to accept from each sender. Email senders with
the worst reputation can have their connections rejected or their messages bounced based on your preferences.
Note File reputation filtering is a separate service. For information, see File Reputation Filtering and File Analysis,
on page 481
IP Reputation Service
The IP Reputation Service, using global data from the Talos Affiliate network, assigns a IP Reputation Score
(IPRS) to email senders based on complaint rates, message volume statistics, and data from public blocked
lists and open proxy lists. The IP Reputation Score helps to differentiate legitimate senders from spam sources.
You can determine the threshold for blocking messages from senders with low reputation scores.
The Talos Security Network website ( https://talosintelligence.com) provides a global overview of the latest
email and web-based threats, displays current email traffic volume by country, and allows you to look up
reputation scores based on IP address, URI or Domain.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
93
IP Reputation Filtering
IP Reputation Score
Related Topics
• IP Reputation Score , on page 94
• How Sender IP Reputation Filters Work , on page 95
• Recommended Settings for Different Sender IP Reputation Filtering Approaches , on page 95
• Outbreak Filters, on page 425
• Using Email Security Monitor, on page 833
IP Reputation Score
The IP Reputation Score is a numeric value assigned to an IP address based on information from the IP
Reputation Service. The IP Reputation Service aggregates data from over 25 public blocked lists and open
proxy lists, and combines this data with global data from Talos to assign a score from -10.0 to +10.0, as
follows:
Score Meaning
-10.0 Most likely to be a source of spam
0 Neutral, or not enough information to make a recommendation
+10.0 Most likely to be a trustworthy sender
The lower (more negative) the score, the more likely that a message is spam. A score of -10.0 means that this
message is “guaranteed” to be spam, while a score of 10.0 means that the message is “guaranteed” to be
legitimate.
Using the IP Reputation Score, you configure the email gateway to apply mail flow policies to senders based
on their trustworthiness. (You can also create message filters to specify “thresholds” for IP Reputation Scores
to further act upon messages processed by the system. For more information, refer to “IP Reputation Rule,
on page 175” and “Bypass Anti-Spam System Action, on page 219.”)
Figure 13: The IP Reputation Service
1. Talos affiliates send real-time, global data
2. Sending MTA opens connection with the email gateway
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
94
IP Reputation Filtering
How Sender IP Reputation Filters Work
3. Email gateway checks global data for the connecting IP address
4. IP Reputation Service calculates the probability that this message is spam and assigns an IP Reputations
Score
5. Cisco returns the response based on the IP Reputation Score
How Sender IP Reputation Filters Work
Sender IP Reputation filter technology aims to shunt as much mail as possible from the remaining security
services processing that is available on the email gateway. (See Understanding the Email Pipeline, on page
65.)
When sender reputation filtering is enabled, mail from known bad senders is simply refused. Known good
mail from global 2000 companies is automatically routed around the spam filters, reducing the chance of false
positives. Unknown, or “grey” email is routed to the anti-spam scanning engine. Using this approach, Sender
IP Reputation filters can reduce the load on the content filters by as much as 50%.
Figure 14: Sender IP Reputation Filtering Example
RecommendedSettingsforDifferentSenderIPReputationFilteringApproaches
Depending on the objectives of your enterprise, you can implement a conservative, moderate, or aggressive
approach.
Approach Characteristics Allowed _List Blocked_ List Suspectlist Unknownlist
Sender IP Reputation Score range:
Conservative Near zero false 7 to 10 -10 to -4 -4 to -2 -2 to 7
positives, better
performance
Moderate Very few false Sender -10 to -3 -3 to -1 -1 to +10
positives, high IPReputation
(Installation
performance Scores are not
default)
used.
Aggressive Some false positives, 4 to 10 -10 to -2 -2 to -1 -1 to 4
maximum
performance.
This option shunts the
most mail away from
Anti-Spam processing.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
95
IP Reputation Filtering
Editing IP Reputation Filtering Score Thresholds for a Listener
Approach Characteristics Allowed _List Blocked_ List Suspectlist Unknownlist
All approaches Mail Flow Policy:
Trusted Blocked Throttled Accepted
Editing IP Reputation Filtering Score Thresholds for a Listener
Use this procedure if you want to change the default IP Reputation Service score thresholds or add a sender
group for reputation filtering.
Note Other settings related to IP Reputation Score thresholds, and Mail Flow Policy settings, are described in
Defining Which Hosts Are Allowed to Connect Using the Host Access Table , on page 101
Before You Begin
• If your email gateway is set to receive mail from a local MX/MTA, identify upstream hosts that may
mask the sender's IP address. See Determining Sender IP Address In Deployments with Incoming Relays
, on page 411 for more information.
• Understand IP Reputation Scores. See Defining Sender Groups by IP Reputation Score, on page 106.
• Choose a filtering approach for your organization and note the recommended settings for that approach.
See Recommended Settings for Different Sender IP Reputation Filtering Approaches , on page 95.
Procedure
Step 1 Select Mail Policies > HAT Overview.
Step 2 Select the public listener from the Sender Groups (Listener) menu.
Step 3 Click the link for a sender group.
For example, click the “SUSPECTLIST” link.
Step 4 Click Edit Settings.
Step 5 Enter the range of IP Reputation Scores for this sender group.
For example, for “ALLOWED_LIST,” enter the range 7.0 to 10.
Step 6 Click Submit.
Step 7 Repeat as needed for each sender group for this listener.
Step 8 Commit changes.
What to do next
Related Topics
• Testing IP Reputation Filtering Using the IP Reputation Scores, on page 97
• Defining Which Hosts Are Allowed to Connect Using the Host Access Table , on page 101
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
96
IP Reputation Filtering
Testing IP Reputation Filtering Using the IP Reputation Scores
• How to Configure the Email Gateway to Scan Messages for Spam, on page 384
Testing IP Reputation Filtering Using the IP Reputation Scores
Unless you regularly receive a large portion of spam, or you have set up “dummy” accounts to specifically
receive spam for your organization, it may be difficult to immediately test the IP Reputation policies you
have implemented. However, if you add entries for reputation filtering with IP Reputation Scores into a
listener’s HAT as indicated in the following table, you will notice that a smaller percentage of inbound mail
will be “unclassified.”
Test the policies using the trace command with an arbitrary IP Reputation scores. See Debugging Mail Flow
Using Test Messages: Trace, on page 1249. The trace command is available in the CLI as well as the GUI.
Table 10: Suggested Mail Flow Policies for Implementing the IP Reputation Scores
Policy Name Primary Behavior (Access Parameters Value
Rule)
$BLOCKED REJECT None
Maximum messages / session: 10
$THROTTLED ACCEPT
Maximum recipients / message: 20
Maximum message size: 1 MB
Maximum concurrent connections: 10
Use Spam Detection: ON
Use TLS: OFF
Maximum recipients / hour: 20 (recommended)
Use SenderBase: ON
Maximum messages / session: 1,000
$ACCEPTED ACCEPT
Maximum recipients / message: 1,000
(Public Listener)
Maximum message size: 100 MB
Maximum concurrent connections: 1,000
Use Spam Detection: ON
Use TLS: OFF
Use SenderBase: ON
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
97
IP Reputation Filtering
Entering Low IP Reputation Scores in the Message Subject
Policy Name Primary Behavior (Access Parameters Value
Rule)
Maximum messages / session: 1,000
$TRUSTED ACCEPT
Maximum recipients / message: 1,000
Maximum message size: 100 MB
Maximum concurrent connections: 1,000
Use Spam Detection: OFF
Use TLS: OFF
Maximum recipients / hour: -1 (disabled)
Use SenderBase: OFF
Note In the $THROTTLED policy, the maximum recipients per hour from the remote host is set to 20 recipients
per hour, by default. Note that this setting controls the maximum throttling available. You can increase the
number of recipients to receive per hour if this parameter is too aggressive. For more information on Default
Host Access policies, see Understanding Predefined Sender Groups and Mail Flow Policies, on page 110.
Entering Low IP Reputation Scores in the Message Subject
Although Cisco recommends throttling, an alternate way to use the IP Reputation Service is to modify the
subject line of suspected spam messages. To do this, use the message filter shown in the following table. This
filter uses the reputation filter rule and the strip-header and insert-header filter actions to replace the subject
line of messages having a IP Reputation Score lower than -2.0 with a subject line that includes the actual IP
Reputation Score represented as: {Spam IP Reputation Score}. Replace listener_name in this example with
the name of your public listener. (The period on its own line is included so that you can cut and paste this text
directly into the command line interface of the filters command.)
Table: Message Filter to Modify Subject Header with IP Reputation: Example 1
iprs_filter:
if ((recv-inj == "listener_name
" AND subject != "\\{Spam -?[0-9.]+\\}"))
insert-header("X-IPRS", "$REPUTATION");
if (reputation <= -2.0)
strip-header("Subject");
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
98
IP Reputation Filtering
Entering Low IP Reputation Scores in the Message Subject
insert-header("Subject", "$Subject \\{Spam $REPUTATION\\}");
Related Topic
• Using Message Filters to Enforce Email Policies, on page 139
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
99
IP Reputation Filtering
Entering Low IP Reputation Scores in the Message Subject
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
100
CHAPTER 7
Defining Which Hosts Are Allowed to Connect
Using the Host Access Table
This chapter contains the following sections:
• Overview of Defining Which Hosts Are Allowed to Connect, on page 101
• Defining Remote Hosts into Sender Groups, on page 102
• Defining Access Rules for Email Senders Using Mail Flow Policies, on page 107
• Understanding Predefined Sender Groups and Mail Flow Policies, on page 110
• Handling Messages from a Group of Senders in the Same Manner, on page 112
• Working with the Host Access Table Configuration, on page 121
• Using a List of Sender Addresses for Incoming Connection Rules, on page 122
• SenderBase Settings and Mail Flow Policies, on page 123
• Verifying Senders, on page 125
Overview of Defining Which Hosts Are Allowed to Connect
For every configured listener, you must define a set of rules that control incoming connections from remote
hosts. For example, you can define remote hosts and whether or not they can connect to the listener. AsyncOS
allows you to define which hosts are allowed to connect to the listener using the Host Access Table (HAT).
The HAT maintains a set of rules that control incoming connections from remote hosts for a listener. Every
configured listener has its own HAT. You configure HATs for both public and private listeners.
To control incoming connections from remote hosts, you define the following information:
• Remote hosts. Define the way in which a remote host attempts to connect to the listener. You group
remote host definitions into sender groups . For example, you can define multiple remote hosts in a
sender group by IP address and partial hostname. You can also define remote hosts by their IP Reputation
score. For more information, see Defining Remote Hosts into Sender Groups, on page 102.
• Access rules. You can define whether the defined remote hosts in the sender group are allowed to connect
to the listener and under what conditions. You define access rules using mail flow policies . For example,
you can define that a particular sender group is allowed to connect to the listener, but only allow a
maximum number of messages per connection. For more information, see Defining Access Rules for
Email Senders Using Mail Flow Policies, on page 107
Define which hosts are allowed to connect to the listener on the Mail Policies > HAT Overview page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
101
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Default HAT Entries
When a listener receives a TCP connection, it compares the source IP address against the configured sender
groups. It evaluates the sender groups in the order listed on the HAT Overview page. When it finds a match,
it applies the configured mail flow policy to the connection. If you have configured multiple conditions within
a sender group, that sender group is matched if any of the conditions match.
When you create a listener, AsyncOS creates predefined sender groups and mail flow polices for the listener.
You can edit the predefined sender groups and mail flow policies, and create new sender groups and mail
flow policies. For more information, see Understanding Predefined Sender Groups and Mail Flow Policies,
on page 110.
You can export all information stored in a Host Access Table to a file, and you can import Host Access Table
information stored in a file into the email gateway for a listener, overriding all configured Host Access Table
information. For more information, see Working with the Host Access Table Configuration, on page 121.
Related Topics
• Default HAT Entries, on page 102
Default HAT Entries
By default, the HAT is defined to take different actions depending on the listener type:
• Public listeners. The HAT is set to accept email from all hosts.
• Private listeners. The HAT is set up to relay email from the host(s) you specify, and reject all other
hosts.
In the HAT Overview, the default entry is named “ALL.” You can edit the default entry by clicking the mail
flow policy for the ALL sender group on the Mail Policies > HAT Overview page.
Note By rejecting all hosts other than the ones you specify, the listenerconfig and systemsetup commands
prevent you from unintentionally configuring your system as an “open relay.” An open relay (sometimes
called an “insecure relay” or a “third party” relay) is an SMTP email server that allows third-party relay of
email messages. By processing email that is neither for nor from a local user, an open relay makes it possible
for an unscrupulous sender to route large volumes of spam through your gateway.
Defining Remote Hosts into Sender Groups
You can define the way in which remote hosts attempt to connect to a listener. You group remote host
definitions into sender groups. A sender group is a list of remote hosts defined for the purpose of handling
email from those senders in the same way.
A sender group is a list of senders identified by:
• IP address (IPv4 or IPv6)
• IP range
• Specific host or domain name
• IP Reputation Service “organization” classification
• IP Reputation Score (IPRS) range (or lack of score)
• DNS List query response
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
102
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Sender Group Syntax
For more information on the list of acceptable addresses in sender groups, see Sender Group Syntax, on page
103.
When an SMTP server attempts an SMTP connection with the email gateway, the listener evaluates the sender
groups in order and assigns the connection to a sender group when it matches any criterion in the sender group,
such as IP reputation score, domain, or IP address.
Note The system acquires and verifies the validity of the remote host’s IP address by performing a double DNS
lookup. This consists of a reverse DNS (PTR) lookup on the IP address of the connecting host, followed by
a forward DNS (A) lookup on the results of the PTR lookup. The system then checks that the results of the
A lookup match the results of the PTR lookup. If the results do not match, or if an A record does not exist,
the system only uses the IP address to match entries in the HAT.
Define sender groups on the Mail Policies > HAT Overview page.
Related Topics
• Sender Group Syntax, on page 103
• Sender Groups Defined by Network Owners, Domains, and IP Addresses, on page 104
• Defining Sender Groups by IP Reputation Score, on page 106
• Sender Groups Defined by Querying DNS Lists, on page 107
Sender Group Syntax
Table 11: Defining Remote Hosts in the HAT: Sender Group Syntax
Syntax Meaning
n:n:n:n:n:n:n:n IPv6 address; does not need to include leading zeroes.
n:n:n:n:n:n:n:n-n:n:n:n:n:n:n:n Range of IPv6 addresses; does not need to include leading zeroes.
n:n:n-n:n:n:n:n:n
n.n.n.n Full (complete) IPv4 Address
n.n.n. Partial IPv4 address
n.n.n.
n.n.
n.n.
n.
n.n.n.n-n. Range of IPv4 addresses
n.n.n.n-n.
n.n.n-n.
n.n-n.
n.n-n
n-n.
n-n
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
103
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Sender Groups Defined by Network Owners, Domains, and IP Addresses
Syntax Meaning
yourhost.example.com A fully-qualified domain name
.partialhost Everything within the partialhost domain
n/c IPv4 CIDR address block
n.n/c
n.n.n/c
n.n.n.n/c
n:n:n:n:n:n:n:n/c IPv6 CIDR address block; does not need to include leading zeroes
SBRS[n:n]SBRS[none] IP Reputation Score. For more information, see Defining Sender Groups by
IP Reputation Score, on page 106.
SBO:n Network Owner Identification Number. For more information, see Defining
Sender Groups by IP Reputation Score, on page 106.
dnslist[dnsserver.domain] DNS List query. For more information, see Sender Groups Defined by
Querying DNS Lists, on page 107.
ALL Special keyword that matches ALL addresses. This applies only to the ALL
sender group, and is always included (but not listed).
Sender Groups Defined by Network Owners, Domains, and IP Addresses
Since the SMTP protocol has no built-in method for authenticating senders of email, senders of unsolicited
bulk email have been successful at employing a number of tactics for hiding their identity. Examples include
spoofing the Envelope Sender address on a message, using a forged HELO address, or simply rotating through
different domain names. This leaves many mail administrators asking themselves the fundamental question,
“Who is sending me all of this email?” To answer this question, the IP Reputation Service has developed a
unique hierarchy for aggregating identity-based information based on the IP address of the connecting host
— the one thing that is almost impossible for a sender to forge in a message.
An IP Address is defined as the IP address of the sending mail host. The email gateway supports both Internet
Protocol version 4 (IPv4) and version 6 (IPv6) addresses.
A Domain is defined as an entity that uses hostnames with a given second-level domain name (for example,
yahoo.com), as determined by a reverse (PTR) lookup on the IP address.
A Network Owner is defined as an entity (usually a company) that controls a block of IP addresses, as
determined based on IP address space assignments from global registries such as ARIN (the American Registry
for Internet Numbers) and other sources.
An Organization is defined as an entity that most closely controls a particular group of mail gateways within
a network owner’s IP block, as determined by SenderBase. An Organization may be the same as the Network
Owner, a division within that Network Owner, or a customer of that Network Owner.
Related Topics
• Setting Policies Based on the HAT, on page 105
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
104
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Setting Policies Based on the HAT
Setting Policies Based on the HAT
The following table lists some examples of network owners and organizations.
Table 12: Example of Network Owners and Organizations
Example Type Network Owner Organization
Network Service Provider Level 3 Communications Macromedia Inc.
AllOutDeals.com
GreatOffers.com
Email Service Provider GE GE Appliances
GE Capital
GE Mortgage
Commercial Sender The Motley Fool The Motley Fool
As network owners can range dramatically in size, the appropriate entity to base your mail flow policy on is
the organization. The IP Reputation Service has a unique understanding of the source of the email down to
the organization level, which the email gateway leverages to automatically apply policies based on the
organization. In the example above, if a user specified “Level 3 Communications” as a sender group in the
Host Access Table (HAT), SenderBase will enforce policies based on the individual organizations controlled
by that network owner.
For example, in the table above, if a user enters a limit of 10 recipients per hour for Level 3, the email gateway
will allow up to 10 recipients per hour for Macromedia Inc., Alloutdeals.com and Greatoffers.com (a total of
30 recipients per hour for the Level 3 network owner). The advantage of this approach is that if one of these
organizations begins spamming, the other organizations controlled by Level 3 will not be impacted. Contrast
this to the example of “The Motley Fool” network owner. If a user sets rate limiting to 10 recipients per hour,
the Motley Fool network owner will receive a total limit of 10 recipients per hour.
The Mail Flow Monitor feature is a way of defining the sender and providing you with monitoring tools to
create mail flow policy decisions about the sender. To create mail flow policy decisions about a given sender,
ask these questions:
• Which IP addresses are controlled by this sender?
The first piece of information that the Mail Flow Monitor feature uses to control the inbound email
processing is the answer to this question. The answer is derived by querying the IP Reputation Service.
The IP Reputation Service provides information about the relative size of the sender (either the network
owner or the SenderBase organization). Answering this question assumes the following:
• Larger organizations tend to control more IP addresses, and send more legitimate email.
• Depending on its size, how should the overall number of connections be allotted for this sender?
• Larger organizations tend to control more IP addresses, and send more legitimate email. Therefore,
they should be allotted more connections to your email gateway.
• The sources of high-volume email are often ISPs, NSPs, companies that manage outsourced email
delivery, or sources of unsolicited bulk email. ISPs, NSPS, and companies that manage outsourced
email delivery are examples of organizations that control many IP addresses, and should be allotted
more connections to your email gateway. Senders of unsolicited bulk email usually do not control
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
105
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Defining Sender Groups by IP Reputation Score
many IP addresses; rather, they send large volumes of mail through a few number of IP addresses.
They should be allotted fewer connections to your email gateway.
The Mail Flow Monitor feature uses its differentiation between network owners and SenderBase organizations
to determine how to allot connections per sender, based on logic in SenderBase. See the “Using Email Security
Monitor” chapter for more information on using the Mail Flow Monitor feature.
Defining Sender Groups by IP Reputation Score
The email gateway can query the IPReputation Service to determine a IP reputation score. The IP Reputation
Score is a numeric value assigned to an IP address, domain, or organization based on information from the
IP Reputation Service. The scale of the score ranges from -10.0 to +10.0, as described in the following table.
Table 13: Definition of the IP Reputation Score
Score Meaning
-10.0 Most likely to be a source of spam
0 Neutral, or not enough information to make a recommendation
+10.0 Most likely to be a trustworthy sender
none No data available for this sender (typically a source of spam)
Using the IP Reputation Score, you configure the email gateway to apply mail flow policies to senders based
on their trustworthiness. For example, all senders with a score less than -7.5 could be rejected. This is most
easily accomplished via the GUI; see Creating a Sender Group for Message Handling , on page 113. However,
if you are modifying an exported HAT in a text file, the syntax for including IP Reputation Scores is described
in the following table.
Table 14: Syntax for IP Reputation Scores
SBRS[ n n IP Reputation Score. Senders are identified by querying the IP Reputation Service, and
the scores are defined between the ranges.
SBRS[none] Specify no IP (very new domains may not have IP Reputation Scores yet).
Note Network owners added to a HAT via the GUI use the syntax SBO:n, where n is the network owner’s unique
identification number in the IP Reputation Service.
Use the Network > Listeners page or listenerconfig -> setup command in the CLI to enable a listener
to query the IP Reputation Service. You can also define the timeout value that the email gateway should wait
when querying the IP Reputation Service. Then, you can configure different policies to use look ups to the
IP Reputation Service by using the values in the Mail Policies Pages in the GUI or the listenerconfig ->
edit -> hostaccess commands in the CLI.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
106
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Sender Groups Defined by Querying DNS Lists
Note You can also create message filters to specify “thresholds” for IP Reputation Scores to further act upon
messages processed by the system. For more information, see “IP Reputation Rule,” “Bypass Anti-Spam
System Action,” and “Bypass Anti-Virus System Action” in the anti-spam and anti-virus chapters.
Sender Groups Defined by Querying DNS Lists
You also have the ability in a listener’s HAT to define a sender group as matching a query to a specific DNS
List sever. The query is performed via DNS at the time of the remote client’s connection. The ability to query
a remote list also exists currently as a message filter rule (see “DNS List Rule” in the chapter on “Using
Message Filters to Enforce Email Policies”), but only once the message content has been received in full.
This mechanism allows you to configure a sender within a group that queries a DNS List so that you can
adjust your mail flow policies accordingly. For example, you could reject connections or limit the behavior
of the connecting domain.
Note Some DNS Lists use variable responses (for example, “127.0.0.1” versus “127.0.0.2” versus “127.0.0.3”) to
indicate various facts about the IP address being queried against. If you use the message filter DNS List rule
(see “DNS List Rule” in the chapter on “Using Message Filters to Enforce Email Policies”), you can compare
the result of the query against different values. However, specifying a DNS List server to be queried in the
HAT only supports a Boolean operation for simplicity (that is, does the IP address appear in the list or not)
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 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 ALLOWED_LIST 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
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:
• 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.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
107
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
HAT Variable Syntax
• 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).
• REJECT. Connection is initially accepted, but the client attempting to connect gets a 4XX or 5XX
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 listenerconfig > setup command.
For more information, see Listening for Connection Requests by Creating a
Listener Using CLI, on page 88.
• 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.
• CONTINUE. The mapping in the HAT is ignored, and processing of the HAT continues. If the incoming
connection matches a later entry that is not CONTINUE, that entry is used instead. The CONTINUE
rule is used to facilitate the editing of the HAT in the GUI. For more information, see Creating a Sender
Group for Message Handling , on page 113.
Related Topics
• HAT Variable Syntax, on page 108
HAT Variable Syntax
The following table defines a set of variables that can also be used in conjunction with the custom SMTP and
Rate Limiting banners defined for a mail flow policy. Variable names are case-insensitive. (That is, $group
is equivalent to $Group .)
Table 15: HAT Variable Syntax
Variable Definition
$Group Replaced by the name of the sender group that was matched in the HAT. If the
sender group has no name, “None” is displayed.
$Hostname Replaced by the remote hostname if and only if is has been validated by the
email gateway. If the reverse DNS lookup of the IP address is successful but
returns no hostname, then “None” is displayed. If the reverse DNS lookup fails
(for example, if the DNS server cannot be reached, or no DNS server has been
configured) then “Unknown” is displayed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
108
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Using HAT Variables
Variable Definition
$OrgID Replaced by the SenderBase Organization ID (an integer value).
If the email gateway cannot obtain a SenderBase Organization ID, or if the IP
Reputation Service did not return a value, “None” is displayed.
$RemoteIP Replaced by the IP address of the remote client.
$HATEntry Replaced by the entry in the HAT that the remote client matched.
Related Topics
• Using HAT Variables, on page 109
• Testing HAT Variables, on page 110
Using HAT Variables
Note These variables can be used with the smtp_banner_text and max_rcpts_per_hour_text advanced HAT
parameters described in the “Configuring the Gateway to Receive Email” chapter.
Using these variables, you could edit the custom SMTP banner response text for accepted connections in the
$TRUSTED policy in the GUI:
Figure 15: Using HAT Variables
Or like this, in the CLI:
Would you like to specify a custom SMTP response? [Y]> y
Enter the SMTP code to use in the response. 220 is the standard code.
[220]> 200
Enter your custom SMTP response. Press Enter on a blank line to finish.
You've connected from the hostname: $Hostname, IP address of: $RemoteIP, matched the group:
$Group,
$HATEntry and the SenderBase Organization: $OrgID.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
109
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Testing HAT Variables
Testing HAT Variables
To test these variables, add the IP address of a known, trusted machine to the $ALLOWED_LIST sender
group of a listener on the email gateway. Then, connect from that machine via telnet. You can see the variable
substitution in the SMTP response. For example:
# telnet
IP_address_of_Email_Security_Appliance port
220 hostname
ESMTP
200 You've connected from the hostname: hostname
, IP address of: IP-address_of_connecting_machine
, matched the group: ALLOWED_LIST, 10.1.1.1 the SenderBase Organization: OrgID
.
Understanding Predefined Sender Groups and Mail Flow
Policies
The following table lists the predefined sender groups and mail flow policies that are configured when a public
listener is created.
Table 16: Predefined Sender Groups and Mail Flow Policies for Public Listeners
Predefined Sender Group Description Default Configured Mail Flow
Policy
ALLOWED_LIST Add senders you trust to the Allowed_list sender $TRUSTED
group. The $TRUSTED mail flow policy is
configured so that email from senders you trust
has no rate limiting enabled, and the content
from those senders is not scanned by the
Anti-Spam or Anti-Virus software.
BLOCKED_LIST Senders in the Blocked_list sender group are $BLOCKED
rejected (by the parameters set in the
$BLOCKED mail flow policy). Adding senders
to this group rejects connections from those hosts
by returning a 5XX SMTP response in the SMTP
HELO command.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
110
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Understanding Predefined Sender Groups and Mail Flow Policies
Predefined Sender Group Description Default Configured Mail Flow
Policy
SUSPECTLIST The Suspectlist sender group contains a mail $THROTTLED
flow policy that throttles, or slows, the rate of
incoming mail. If senders are suspicious, you
can add them to the Suspectlist sender group,
where the mail flow policy dictates that:
• Rate limiting limits the maximum number
of messages per session, the maximum
number of recipients per message, the
maximum message size, and the maximum
number of concurrent connections you are
willing to accept from a remote host.
• The maximum recipients per hour from the
remote host is set to 20 recipients per hour.
Note that this setting is the maximum
throttling available. You can increase the
number of recipients to receive per hour if
this parameter is too aggressive.
• The content of messages will be scanned
by the anti-spam scanning engine and the
anti-virus scanning engine (if you have
these feature enabled for the system).
• The SenderBase Reputation Service will
be queried for more information about the
sender.
UNKNOWNLIST The Unknownlist sender group may be useful if $ACCEPTED
you are undecided about the mail flow policy
you should use for a given sender. The mail flow
policy for this group dictates that mail is
accepted for senders in this group, but the
Anti-Spam software (if enabled for the system),
the anti-virus scanning engine, and the IP
Reputation Service should all be used to gain
more information about the sender and the
message content. Rate limits for senders in this
group are also enabled with default values. For
more information on virus scanning engines, see
Virus Scanning, on page 367. For more
information on the IP Reputation Service, see
IP Reputation Service, on page 93.
ALL Default sender group that applies to all other $ACCEPTED
senders. For more information, see Default HAT
Entries, on page 102.
The following table lists the predefined sender groups and mail flow policies that are configured when a
private listener is created.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
111
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Handling Messages from a Group of Senders in the Same Manner
Table 17: Predefined Sender Groups and Mail Flow Policies for Private Listeners
Predefined Sender Group Description Default Configured Mail Flow
Policy
RELAYLIST Add senders you know should be allowed to $RELAYED
relay to the Relaylist sender group. The
$RELAYED mail flow policy is configured so
that email from senders you are allowing to
relay has no rate limiting, and the content from
those senders is not scanned by the anti-spam
scanning engine or anti-virus software.
Note The RELAYLIST sender group
includes the systems allowed to relay
email when the System Setup
Wizard was run.
ALL Default sender group that applies to all other $BLOCKED
senders. For more information, see Default
HAT Entries, on page 102.
Note When you run the System Setup Wizard on an email gateway model that has only two Ethernet ports, you are
prompted to create only one listener. It creates a public listener that also includes a $RELAYED mail flow
policy that is used to relay mail for internal systems. For email gateway models that have more than two
Ethernet ports, the RELAYLIST sender group and $RELAYED mail flow policy only appear on private
listeners.
Handling Messages from a Group of Senders in the Same
Manner
Use the Mail Policies > HAT Overview and Mail Flow Policy pages to configure how the listener handles
messages from senders. Do this by creating, editing, and deleting sender groups and mail flow policies.
Related Topics
• Creating a Sender Group for Message Handling , on page 113
• Adding a Sender to an Existing Sender Group, on page 114
• Rearranging the Order of the Rules to Perform for Incoming Connections, on page 114
• Searching for Senders, on page 115
• Defining Access Rules for Email Senders Using Mail Flow Policies, on page 107
• Defining Default Values for Mail Flow Policies, on page 120
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
112
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Creating a Sender Group for Message Handling
Creating a Sender Group for Message Handling
Procedure
Step 1 Navigate to the Mail Policies > HAT Overview page.
Step 2 Choose the listener to edit in the Listener field.
Step 3 Click Add Sender Group.
Step 4 Type the name of the sender group.
Step 5 Select the order in which to place it in the list of sender groups.
Step 6 (Optional) Enter a comment, for example information about this sender group or its settings.
Step 7 Select a mail flow policy to which to apply this sender group.
Note If you do not know the mail flow policy you would like to apply to this group (or if no mail flow
policies exist yet), then use the default “CONTINUE (no policy)” mail flow policy.
Step 8 (Optional) Select a DNS list.
Step 9 (Optional) Include senders for which IP Reputation Score has no information. This is referred to as “none”
and generally denotes a suspect.
Step 10 (Optional) Enter a DNS list.
Step 11 (Optional) Configure host DNS verification settings.
For more information, see Implementing More Stringent Throttling Settings for Unverified Senders, on page
129 .
Step 12 Click Submit to create the sender group.
Step 13 Click on the newly created sender group.
Step 14 Click Add Sender to add senders to the sender group.
• Add sender IP address .Select IP Addresses, add an IPv4 address, IPv6 address, or a hostname, and
submit the changes.
A sender can include a range of IP addresses and partial hostnames.
• Add sender's country of origin. Select Geolocation, select the country, and submit the changes.
Step 15 Submit and commit your changes.
What to do next
Related Topics
• Editing IP Reputation Filtering Score Thresholds for a Listener , on page 96
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
113
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Adding a Sender to an Existing Sender Group
Adding a Sender to an Existing Sender Group
Procedure
Step 1 From a domain, IP, or network owner profile page, click the Add to Sender Group link.
Step 2 Choose the sender group from the list defined for each listener.
Step 3 Submit and commit your changes.
Note When you add a domain to a sender group, two actual domains are listed in the GUI. For example,
if you were adding the domain example.net , on the Add to Sender Group page, both example.net
and .example.net are added. The second entry ensures that any host in the subdomain of
example.net will be added to the sender group. For more information, see Sender Group Syntax,
on page 103.
If one or more of the senders you are adding to a sender group is a duplicate of a sender that is
already present in that sender group, the duplicate senders will not be added and you will see a
confirmation message.
Step 4 Click Save to add the sender and return to the Incoming Mail Overview page.
What to do next
Related Topics
• Protecting Email Gateway-Generated Messages From the Spam Filter, on page 405
• How to Configure the Email Gateway to Scan Messages for Spam, on page 384
Rearranging the Order of the Rules to Perform for Incoming Connections
If you add a sender group to a listener, you may need to edit the sender group order.
The HAT is read from top to bottom for each host that attempts to connect to the listener. If a rule matches a
connecting host, the action is taken for that connection immediately.
Procedure
Step 1 Navigate to the Mail Policies > HAT Overview page.
Step 2 Choose the listener to edit in the Listener field.
Step 3 Click Edit Order.
Step 4 Type the new order for existing rows of sender groups in the HAT.
Cisco recommends maintaining the default order: RELAYLIST (certain hardware models only), followed by
ALLOWED_LIST, BLOCKED_LIST, SUSPECTLIST, and UNKNOWNLIST.
Step 5 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
114
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Searching for Senders
Searching for Senders
You can find senders by entering text in the Find Senders field at the top of the HAT Overview page. Enter
the text to search with and click Find.
Defining Rules for Incoming Messages Using a Mail Flow Policy
Consider the following rules and guidelines before creating a mail flow policy:
• Defaults for the policy are “greyed out” while the “Use Default” radio button is selected. To overwrite
the default values, enable the feature or setting by selecting the “On” radio button and making changes
to the now accessible values. To define default values, see Defining Default Values for Mail Flow Policies,
on page 120.
• Some parameters depend on certain pre-configurations. (For example, the Directory Harvest Attack
prevention setting requires that you have configured an LDAP Acceptance Query.)
Procedure
Step 1 Navigate to the Mail Policies > Mail Flow Policies page.
Step 2 Click Add Policy.
Step 3 Enter the information described in the following table.
Table 18: Mail Flow Policy Parameters
Parameter Description
Connections
Maximum message The maximum size of a message that will be accepted by this listener. The smallest
size possible maximum message size is 1 kilobyte.
Maximum concurrent The maximum number of concurrent connections allowed to connect to this listener
connections from a from a single IP address.
single IP
Maximum messages The maximum number of messages that can be sent through this listener per
per connection connection from a remote host.
Maximum recipients That maximum number of recipients per message that will be accepted from this
per message host.
SMTP Banner
Custom SMTP Banner The SMTP code returned when a connection is established with this listener.
Code
Custom SMTP Banner The SMTP banner text returned when a connection is established with this listener.
Text
Note You can use some variables in this field. For more information, see HAT
Variable Syntax, on page 108.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
115
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Defining Rules for Incoming Messages Using a Mail Flow Policy
Parameter Description
Custom SMTP Reject The SMTP code returned when a connection is rejected by this listener.
Banner Code
Custom SMTP Reject The SMTP banner text returned when a connection is rejected by this listener.
Banner Text
Override SMTP By default, the email gateway will include the hostname associated with the interface
Banner Host Name of the listener when displaying the SMTP banner to remote hosts (for example: 220-
hostname ESMTP ). You may choose to override this banner by entering a different
hostname here. Additionally, you may leave the hostname field blank to choose not
to display a hostname in the banner.
Rate Limit for Hosts
Max. Recipients per The maximum number of recipients per hour this listener will receive from a remote
Hour host. The number of recipients per sender IP address is tracked globally. Each listener
tracks its own rate limiting threshold; however, because all listeners validate against
a single counter, it is more likely that the rate limit will be exceeded if the same IP
address (sender) is connecting to multiple listeners.
Note You can use some variables in this field. For more information, see HAT
Variable Syntax, on page 108.
Max. Recipients per The SMTP code returned when a host exceeds the maximum number of recipients
Hour Code per hour defined for this listener.
Max. Recipients Per The SMTP banner text returned when a host exceeds the maximum number of
Hour Exceeded Text recipients per hour defined for this listener.
Rate Limit for Sender
Max. Recipients per The maximum number of recipients during a specified time period that this listener
Time Interval will receive from a unique envelope sender, based on the mail-from address. The
number of recipients is not tracked globally. Each listener tracks its own rate limiting
threshold; however, because all listeners validate against a single counter, it is more
likely that the rate limit will be exceeded if messages from the same mail-from
address are received by multiple listeners.
Select whether to use the default maximum recipients, accept unlimited recipients,
or specify another maximum number of recipients.
Use the Default Mail Flow Policy settings to specify the maximum number of
recipients and the time interval that will be used by the other mail flow policies by
default. The time interval can only be specified using the Default Mail Flow Policy.
Sender Rate Limit The SMTP code returned when an envelope exceeds the maximum number of
Exceeded Error Code recipients for the time interval defined for this listener.
Sender Rate Limit The SMTP banner text returned when an envelope sender exceeds the maximum
Exceeded Error Text number of recipients for the time interval defined for this listener.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
116
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Defining Rules for Incoming Messages Using a Mail Flow Policy
Parameter Description
Exceptions If you want certain envelope senders to be exempt from the defined rate limit, select
an address list that contains the envelope senders. See Using a List of Sender
Addresses for Incoming Connection Rules, on page 122for more information.
Flow Control
Use SenderBase for Enable “look ups” to the IP Reputation Service for this listener.
Flow Control
Group by Similarity of Used to track and rate limit incoming mail on a per-IP address basis while managing
IP Addresses: entries in a listener’s Host Access Table (HAT) in large CIDR blocks. You define a
(significant bits 0-32) range of significant bits (from 0 to 32) by which to group similar IP addresses for
the purposes of rate limiting, while still maintaining an individual counter for each
IP address within that range. Requires “Use SenderBase” to be disabled. For more
information about HAT significant bits, see Configuring Routing and Delivery
Features, on page 697.
Directory Harvest Attack Prevention (DHAP)
Directory Harvest The maximum number of invalid recipients per hour this listener will receive from
Attack Prevention: a remote host. This threshold represents the total number of RAT rejections and
Maximum Invalid SMTP call-ahead server rejections combined with the total number of messages to
Recipients Per Hour invalid LDAP recipients dropped in the SMTP conversation or bounced in the work
queue (as configured in the LDAP accept settings on the associated listener). For
more information on configuring DHAP for LDAP accept queries, see Working with
LDAP Queries, on page 785.
Directory Harvest The email gateway will drop a connection to a host if the threshold of invalid
Attack Prevention: recipients is reached.
Drop Connection if
DHAP threshold is
Reached within an
SMTP Conversation
Max. Invalid Specify the code to use when dropping connections. The default code is 550.
Recipients Per Hour
Code:
Max. Invalid Specify the text to use for dropped connections. The default text is “Too many invalid
Recipients Per Hour recipients.”
Text:
Drop Connection if Enable to drop connections if the DHAP threshold is reached within an SMTP
DHAP threshold is conversation.
reached within an
SMTP Conversation
Max. Invalid Specify the code to use when dropping connections due to DHAP within an SMTP
Recipients Per Hour conversation. The default code is 550.
Code
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
117
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Defining Rules for Incoming Messages Using a Mail Flow Policy
Parameter Description
Max. Invalid Specify the text to use when dropping connections due to DHAP within an SMTP
Recipients Per Hour conversation.
Text:
Spam Detection
Anti-spam scanning Enable anti-spam scanning on this listener.
Virus Detection
Anti-virus scanning Enable the anti-virus scanning on this listener.
Sender Domain Reputation Verification
Sender Domain Enable sender domain reputation verification.
Reputation
Verification
Encryption and Authentication
TLS Deny, Prefer, or Require Transport Layer Security (TLS) in SMTP conversations
for this listener.
If you select Preferred, you can make TLS mandatory for envelope senders from a
specific domain or with a specific email address by selecting an Address List that
specifies those domains and email addresses. When an envelope sender matching a
domain or address in this list tries to send a message over a connection that does not
use TLS, the email gateway rejects the connection and the sender will have to try
again using TLS.
The Verify Client Certificate option directs the email gateway to establish a TLS
connection to the user’s mail application if the client certificate is valid. If you select
this option for the TLS Preferred setting, the email gateway still allows a non-TLS
connection if the user doesn’t have a certificate, but rejects a connection if the user
has an invalid certificate. For the TLS Required setting, selecting this option requires
the user to have a valid certificate in order for the email gateway to allow the
connection.
For information on creating an address list, see Using a List of Sender Addresses for
Incoming Connection Rules, on page 122.
For information on using client certificates for TLS connections, see Establishing a
TLS Connection from the Email Gateway, on page 827.
SMTP Authentication Allows, disallow, or requires SMTP Authentication from remote hosts connecting
to the listener. SMTP Authentication is described in detail in the “LDAP Queries”
chapter.
If Both TLS and Require TLS to offer SMTP Authentication.
SMTP Authentication
are enabled:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
118
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Defining Rules for Incoming Messages Using a Mail Flow Policy
Parameter Description
Domain Key/ DKIM Enable Domain Keys or DKIM signing on this listener (ACCEPT and RELAY only).
Signing
DKIM Verification Enable DKIM verification.
S/MIME Decryption and Verification
S/MIME • Enable S/MIME decryption or verification.
Decryption/Verification • Choose whether to retain or remove the digital signature from the messages
after S/MIME verification. For triple wrapped messages, only the inner signature
is retained or removed.
S/MIME Public Key Harvesting
S/MIME Public Key Enable S/MIME public key harvesting.
Harvesting
Harvest Certificates Choose whether to harvest public keys if the verification of the incoming signed
on Verification Failure messages fail.
Store Updated Choose whether to harvest updated public keys.
Certificate
SPF/SIDF Verification
Enable SPF/SIDF Enable SPF/SIDF signing on this listener. For more information, see Email
Verification Authentication, on page 601.
Conformance Level Set the SPF/SIDF conformance level. You can choose from SPF, SIDF or SIDF
Compatible. For details, see Email Authentication, on page 601.
Downgrade PRA If you choose a conformance level of SIDF compatible, configure whether you want
verification result if to downgrade Pass result of the PRA Identity verification to None if there are
'Resent-Sender:' or Resent-Sender: or Resent-From: headers present in the message. You may choose
'Resent-From:' were this option for security purposes.
used:
HELO Test Configure whether you want to perform a test against the HELO identity (Use this
for SPF and SIDF Compatible conformance levels).
DMARC Verification
Enable DMARC Enable DMARC verification on this listener. For more information, see DMARC
Verification Verification, on page 632.
Use DMARC Select the DMARC verification profile that you want to use on this listener.
Verification Profile
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
119
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Defining Default Values for Mail Flow Policies
Parameter Description
DMARC Feedback Enable sending of DMARC aggregate feedback reports.
Reports
For more information about DMARC aggregate feedback report, see DMARC
Aggregate Reports, on page 639.
Note DMARC specification requires the feedback report messages to be
DMARC compliant. Make sure that these messages are DKIM signed or
you must publish appropriate SPF records.
Untagged Bounces
Consider Untagged Applies only if bounce verification tagging (discussed in the “Configuring Routing
Bounces to be Valid and Delivery Features” chapter) is enabled. By default, the appliance considers
untagged bounces invalid and either rejects the bounce or adds a custom header,
depending on the Bounce Verification settings. If you choose to consider untagged
bounces to be valid, the email gateway accepts the bounce message.
Envelope Sender DNS Verification
See Verifying Senders, on page 125.
Exception Table
Use Exception Table Use the sender verification domain exception table. You can only have one exception
table, but you can enable it per mail flow policy. See Sender Verification Exception
Table, on page 127 for more information.
Note If anti-spam or anti-virus scanning is enabled globally in the HAT, messages are flagged for anti-spam
or anti-virus scanning as they are accepted by the email gateway. If anti-spam or anti-virus scanning
is disabled after the message is accepted, the message will still be subject to scanning when it leaves
the work queue.
Step 4 Submit and commit your changes.
Defining Default Values for Mail Flow Policies
Procedure
Step 1 Click Mail Policies > Mail Flow Policies.
Step 2 Choose the listener to edit in the Listener field.
Step 3 Click the Default Policy Parameters link below the configured mail flow policies.
Step 4 Define the default values that all mail flow policies for this listener use.
For more information on the properties, see Defining Rules for Incoming Messages Using a Mail Flow Policy,
on page 115.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
120
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Working with the Host Access Table Configuration
Step 5 Submit and commit your changes.
Working with the Host Access Table Configuration
You can export all information stored in a Host Access Table to a file, and you can import Host Access Table
information stored in a file into the email gateway for a listener, overwriting all existing Host Access Table
information.
Related Topics
• Exporting the Host Access Table Configuration to an External File, on page 121
• Importing the Host Access Table Configuration from an External File, on page 121
Exporting the Host Access Table Configuration to an External File
Procedure
Step 1 Navigate to the Mail Policies > HAT Overview page.
Step 2 Choose the listener to edit in the Listener menu.
Step 3 Click Export HAT.
Step 4 Enter a file name for the exported HAT. This is the name of the file that will be created in the configuration
directory on the email gateway.
Step 5 Submit and commit your changes.
Importing the Host Access Table Configuration from an External File
When you import a HAT, all of the existing HAT entries are removed from the current HAT.
Procedure
Step 1 Navigate to the Mail Policies > HAT Overview page.
Step 2 Choose the listener to edit in the Listener menu.
Step 3 Click Import HAT.
Step 4 Select a file from the list.
Note The file to import must be in the configuration directory on the email gateway.
Step 5 Click Submit. You will see a warning message, asking you to confirm that you wish to remove all of the
existing HAT entries.
Step 6 Click Import.
Step 7 Commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
121
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Using a List of Sender Addresses for Incoming Connection Rules
You can place “comments” in the file. Lines that begin with a ‘#’ character are considered comments and are
ignored by AsyncOS. For example:
# File exported by the GUI at 20060530T215438
$BLOCKED
REJECT {}
[ ... ]
Using a List of Sender Addresses for Incoming Connection Rules
Mail flow policies allow you to use of an address list for certain settings that apply to a group of envelope
senders, such as rate limiting exemptions and mandatory TLS connections. An address list can consist of
email addresses, domains, partial domains, and IP addresses. You can use the Mail Policies > Address Lists
page in the GUI or the addresslistconfig command in the CLI to create an address list. The Address Lists
page displays all address lists on the email gateway, along with any mail flow policies that use an address list.
Procedure
Step 1 Select Mail Policies > Address Lists.
Step 2 Click Add Address List.
Step 3 Enter a name for the address list.
Step 4 Enter a description of the address list.
Step 5 (Optional) To enforce using full email addresses in the address list, select Full Email Addresses only.
Step 6 Choose any one of the following options to create an address list:
• Select Full Email Addresses only if you want to enforce using full email addresses in the address list.
• Select Domains only if you want to enforce using domains in the address list.
• Select IP Addresses only if you want to enforce using IP addresses in the address list.
Step 7 Enter the addresses you want to include. You can use the following formats:
• Full email address: [email protected]
• Partial email address: user@
Note If you have selected Allow only full Email Addresses, you cannot use partial email addresses.
• IP address in their email address: @[1.2.3.4]
• All users in a domain: @example.com
• All users in a partial domain: @.example.com
Note that domains and IP addresses must start with a @ character.
Separate email addresses with a comma. If you separate the addresses using a new line, AsyncOS automatically
converts your entries into a comma-separated list.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
122
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
SenderBase Settings and Mail Flow Policies
Step 8 Submit and commit your changes.
SenderBase Settings and Mail Flow Policies
In order to classify connections to the email gateway and apply mail flow policies (which may or may not
contain rate limiting), a listener uses the following methodology:
Classification -> Sender Group -> Mail Flow Policy -> Rate Limiting
For more information, see Sender Groups Defined by Network Owners, Domains, and IP Addresses, on page
104.
The “Classification” stage uses the sending host’s IP address to classify an inbound SMTP session (received
on a public listener) into a Sender Group. The Mail Flow Policy associated with that Sender Group may have
parameters for rate limiting enabled. (Rate limiting limits the maximum number of messages per session, the
maximum number of recipients per message, the maximum message size, and/or the maximum number of
concurrent connections you are willing to accept from a remote host.)
Normally, in this process, recipients are counted against each sender in the corresponding named sender group.
If mail is received from several senders in the same hour, the total recipients for all senders is compared against
the limit.
There are some exceptions to this counting methodology:
• If the classification is done by Network Owner, then the IP Reputation Service will automatically divide
a large block of addresses into smaller blocks.
Counting of recipients and recipient rate limiting is done separately for each of these smaller blocks (usually,
but not always, the equivalent of a /24 CIDR block).
• If the HAT Significant Bits feature is used. In this case, a large block of addresses may be divided into
smaller blocks by applying the significant bits parameter associated with the policy.
Note that this parameter relates to the Mail Flow Policy -> Rate Limiting phase. It is not the same as the
“bits” field in the “network/bits” CIDR notation that may be used to classify IP addresses in a Sender Group.
By default, IP Reputation Service and IP Profiling support are enabled for public listeners and disabled for
private listeners.
Related Topics
• HAT Significant Bits Feature, on page 123
HAT Significant Bits Feature
Beginning with the 3.8.3 release of AsyncOS, you can track and rate limit incoming mail on a per-IP address
basis while managing sender group entries in a listener’s Host Access Table (HAT) in large CIDR blocks.
For example, if an incoming connection matched against the host “10.1.1.0/24,” a counter could still be
generated for each individual address within that range, rather than aggregating all traffic into one large
counter.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
123
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
HAT Configuration
Note In order for the significant bits HAT policy option to take effect, you must not enable “User SenderBase” in
the Flow Control options for the HAT (or, for the CLI, answer no to the question for enabling the SenderBase
Information Service in the listenerconfig -> setup command: “Would you like to enable Reputation
Filters and IP Profiling support?”). That is, the Hat Significant Bits feature and enabling SenderBase IP
Profiling support are mutually exclusive.
In most cases, you can use this feature to define sender groups broadly — that is, large groups of IP addresses
such as “10.1.1.0/24” or “10.1.0.0/16” — while applying mail flow rate limiting narrowly to smaller groups
of IP addresses.
The HAT Significant Bits feature corresponds to these components of the system:
• HAT Configuration , on page 124
• Significant Bits HAT Policy Option , on page 124
• Injection Control Periodicity , on page 124
HAT Configuration
There are two parts of HAT configuration: sender groups and mail flow policies. Sender group configuration
defines how a sender's IP address is “classified” (put in a sender group). Mail flow policy configuration defines
how the SMTP session from that IP address is controlled. When using this feature, an IP address may be
“classified in a CIDR block” (e.g. 10.1.1.0/24) sender group while being controlled as an individual host (/32).
This is done via the “signficant_bits” policy configuration setting.
Significant Bits HAT Policy Option
The HAT syntax allows for the signficant_bits configuration option. This feature appears in the GUI in the
Mail Policies > Mail Flow Policies page.
When the option to use SenderBase for flow control is set to “OFF” or Directory Harvest Attack Prevention
is enabled, the “significant bits” value is applied to the connecting sender’s IP address, and the resulting CIDR
notation is used as the token for matching defined sender groups within the HAT. Any rightmost bits that are
covered by the CIDR block are “zeroed out” when constructing the string. Thus, if a connection from the IP
address 1.2.3.4 is made and matches on a policy with the significant_bits option set to 24, the resultant CIDR
block would be 1.2.3.0/24. So by using this feature, the HAT sender group entry (for example, 10.1.1.0/24)
can have a different number of network significant bits (24) from the significant bits entry in the policy
assigned to that group (32, in the example).
For more information on listenerconfig command, see the CLI Reference Guide for AsyncOS for Cisco
Secure Email Gateway.
Injection Control Periodicity
A global configuration option exists to allow you to adjust when the injection control counters are reset. For
very busy systems maintaining counters for a very large number of different IP addresses, configuring the
counters to be reset more frequently (for example, every 15 minutes instead of every 60 minutes) will ensure
that the data does not grow to an unmanageable size and impact system performance.
The current default value is 3600 seconds (1 hour).You can specify periods ranging from as little as 1 minute
(60 seconds) to as long as 4 hours (14,400 seconds).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
124
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Verifying Senders
Adjust this period via the GUI, using the global settings (for more information, see Configuring Global Settings
for Listeners, on page 80).
You can also adjust this period using the listenerconfig -> setup command in the CLI. For more information
on listenerconfig command, see the CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway.
Verifying Senders
Spam and unwanted mail is frequently sent by senders whose domains or IP addresses cannot be resolved by
DNS. DNS verification means that you can get reliable information about senders and process mail accordingly.
Sender verification prior to the SMTP conversation (connection filtering based on DNS lookups of the sender’s
IP address) also helps reduce the amount of junk email processed through the mail pipeline on the email
gateway.
Mail from unverified senders is not automatically discarded. Instead, AsyncOS provides sender verification
settings that allow you to determine how the email gateway handles mail from unverified senders: you can
configure your email gateway to automatically block all mail from unverified senders prior to the SMTP
conversation or throttle unverified senders, for example.
The sender verification feature consists of the following components:
• Verification of the connecting host. This occurs prior to the SMTP conversation. For more information,
see Sender Verification: Host, on page 125.
• Verification of the domain portion of the envelope sender. This occurs during the SMTP conversation.
For more information, see Sender Verification: Envelope Sender, on page 126.
Related Topics
• Sender Verification: Host, on page 125
• Sender Verification: Envelope Sender, on page 126
• Implementing Sender Verification — Example Settings, on page 128
• Testing Your Settings for Messages from Unverified Senders, on page 130
• Sender Verification and Logging, on page 132
Sender Verification: Host
Senders can be unverified for different reasons. For example, the DNS server could be “down” or not
responding, or the domain may not exist. Host DNS verification settings for sender groups allow you to classify
unverified senders prior to the SMTP conversation and include different types of unverified senders in your
various sender groups.
The email gateway attempts to verify the sending domain of the connecting host via DNS for incoming mail.
This verification is performed prior to the SMTP conversation. The system acquires and verifies the validity
of the remote host’s IP address (that is, the domain) by performing a double DNS lookup . A double DNS
lookup is defined as a reverse DNS (PTR) lookup on the IP address of the connecting host, followed by a
forward DNS (A) lookup on the results of the PTR lookup. The email gateway then checks that the results of
the A lookup match the results of the PTR lookup. If the PTR or A lookups fail, or the results do not match,
the system uses only the IP address to match entries in the HAT and the sender is considered as not verified.
Unverified senders are classified into the following categories:
• Connecting host PTR record does not exist in the DNS.
• Connecting host PTR record lookup fails due to temporary DNS failure.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
125
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Sender Verification: Envelope Sender
• Connecting host reverse DNS lookup (PTR) does not match the forward DNS lookup (A).
Using the sender group “Connecting Host DNS Verification” settings, you can specify a behavior for unverified
senders (see Throttling Messages from Unverified Senders Using the SUSPECTLIST Sender Group, on page
129).
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 ALLOWED_LIST sender group, for example, would mean that mail from unverified senders would receive
the same treatment as mail from your trusted senders in your ALLOWED_LIST (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.
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.
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.
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 email gateway 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.
• 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 storeSender Verification Exception Table, on page 127
a list of domains or addresses from which 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.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
126
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Partial Domains, Default Domains, and Malformed MAIL FROMs
Though most spam is from unverifiable senders, there are reasons why you might want to accept mail from
an unverified sender. For example, not all legitimate email can be verified through DNS lookups — a temporary
DNS server problem can stop a sender from being verified.
When mail from unverified senders is attempted, the sender verification exception table and mail flow policy
envelope sender DNS verification settings are used to classify envelope senders during the SMTP conversation.
For example, you may accept and throttle mail from sending domains that are not verified because they do
not exist in DNS. Once that mail is accepted, messages with malformed MAIL FROMs are rejected with a
customizable SMTP code and response. This occurs during the SMTP conversation.
You can enable envelope sender DNS verification (including the domain exception table) in the mail flow
policy settings for any mail flow policy via the GUI or the CLI ( listenerconfig -> edit -> hostaccess
-> < policy > ).
Related Topics
• Partial Domains, Default Domains, and Malformed MAIL FROMs, on page 127
• Custom SMTP Code and Response, on page 127
• Sender Verification: Envelope Sender, on page 126
Partial Domains, Default Domains, and Malformed MAIL FROMs
If you enable envelope sender verification or disable allowing partial domains in SMTP Address Parsing
options for a listener (see the SMTP Address Parsing Options section in the “Configuring the Gateway to
Receive Email” chapter), the default domain settings for that listener will no longer be used.
These features are mutually exclusive.
Custom SMTP Code and Response
You can specify the SMTP code and response message for messages with malformed envelope senders, for
envelope senders which do not exist in DNS, and for envelope senders which do not resolve via DNS queries
(DNS server might be down, etc.).
In the SMTP response, you can include a variable, $EnvelopeSender , which is expanded to the value of the
envelope sender when the custom response is sent.
While typically a “Domain does not exist” result is permanent, it is possible for this to be a transient condition.
To handle such cases, “conservative” users may wish to change the error code from the default 5XX to a 4XX
code.
Sender Verification Exception Table
The sender verification exception table is a list of domains or email addresses that will either be automatically
allowed or rejected during the SMTP conversation. You can also specify an optional SMTP code and reject
response for rejected domains. There is only one sender verification exception table per email gateway and
it is enabled per mail flow policy.
The sender verification exception table can be used to list obviously fake but correctly formatted domains or
email addresses from which you want to reject mail. For example, the correctly formatted MAIL FROM:
[email protected] could be listed in the sender verification exception table and set to be automatically
rejected. You can also list domains that you want to automatically allow, such as internal or test domains.
This is similar to envelope recipient (SMTP RCPT TO command) processing which occurs in the Recipient
Access Table (RAT).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
127
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Implementing Sender Verification — Example Settings
The sender verification exception table is defined in the GUI via the Mail Policies > Exception Table page
(or the CLI, via the exceptionconfig command) and then is enabled on a per-policy basis via the GUI (see
Defining Messages to Send to Unverified Senders Using the ACCEPTED Mail Flow Policy, on page 129) or
the CLI (see the CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway.
Entries in the sender verification exception table have the following syntax:
See Excluding Unverified Senders from Sender Verification Rules Based on Sender’s Email Address, on page
130 for more information about modifying the exception table.
Implementing Sender Verification — Example Settings
This section provides an example of a typical conservative implementation of host and envelope sender
verification.
For this example, when implementing host sender verification, mail from connecting hosts for which reverse
DNS lookup does not match is throttled via the existing SUSPECTLIST sender group and THROTTLED
mail flow policy.
A new sender group (UNVERIFIED) and a new mail flow policy (THROTTLEMORE) are created. Mail
from connecting hosts which are not verified will be throttled (using the UNVERIFIED sender group and the
more aggressive THROTTLEMORE mail flow policy) prior to the SMTP conversation.
Envelope sender verification is enabled for the ACCEPTED mail flow policy.
The following table shows the suggested settings for implementing sender verification:
Table 19: Sender Verification: Suggested Settings
Sender Group Policy Include
UNVERIFIED THROTTLEMORE Prior to SMTP conversation:
SUSPECTLIST THROTTLED Connecting host PTR record does not exist in the DNS.
Connecting host reverse DNS lookup (PTR) does not match the forward
DNS lookup (A).
ACCEPTED Envelope Sender Verification during SMTP conversation:
- Malformed MAIL FROM:
- Envelope sender does not exist in DNS.
- Envelope sender DNS does not resolve.
Related Topics
• Throttling Messages from Unverified Senders Using the SUSPECTLIST Sender Group, on page 129
• Implementing More Stringent Throttling Settings for Unverified Senders, on page 129
• Defining Messages to Send to Unverified Senders Using the ACCEPTED Mail Flow Policy, on page
129
• Excluding Unverified Senders from Sender Verification Rules Based on Sender’s Email Address, on
page 130
• Searching for Addresses within the Sender Verification Exception Table, on page 130
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
128
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Throttling Messages from Unverified Senders Using the SUSPECTLIST Sender Group
Throttling Messages from Unverified Senders Using the SUSPECTLIST Sender Group
Procedure
Step 1 Select Mail Policies > HAT Overview.
Step 2 Click SUSPECTLIST in the list of sender groups.
Step 3 Click Edit Settings.
Step 4 Select the THROTTLED policy from the list.
Step 5 Check the “Connecting host reverse DNS lookup (PTR) does not match the forward DNS lookup (A)” checkbox
under Connecting Host DNS Verification.
Step 6 Submit and commit your changes.
Now, senders for which reverse DNS lookups fail will match the SUSPECTLIST sender group and will receive
the default action from the THROTTLED mail flow policy.
Implementing More Stringent Throttling Settings for Unverified Senders
Procedure
Step 1 Create a new mail flow policy (for this example, it is named THROTTLEMORE) and configure it with more
stringent throttling settings.
a) On the Mail Flow Policies page, click Add Policy
b) Enter a name for the mail flow policy, and select Accept as the Connection Behavior.
c) Configure the policy to throttle mail.
d) Submit and commit your changes.
Step 2 Create a new sender group (for this example, it is named UNVERIFIED) and configure it to use the
THROTTLEMORE policy:
a) On the HAT Overview page, click Add Sender Group
b) Select the THROTTLEMORE policy from the list.
c) Check the “Connecting host PTR record does not exist in DNS” checkbox under Connecting Host DNS
Verification.
d) Submit and commit your changes.
Defining Messages to Send to Unverified Senders Using the ACCEPTED Mail Flow Policy
Procedure
Step 1 Select Mail Policies > Mail Flow Policies.
Step 2 On the Mail Flow Policies page, click on the ACCEPTED mail flow policy.
Step 3 Scroll down to the Sender Verification section.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
129
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Excluding Unverified Senders from Sender Verification Rules Based on Sender’s Email Address
Step 4 In the Envelope Sender DNS Verification section, do the following:
• Select On to enable envelope sender DNS verification for this mail flow policy.
• You may also define custom SMTP code and responses.
Step 5 In the Use Domain Exception Table section, select On to enable the domain exception table.
Step 6 Submit and commit your changes.
Excluding Unverified Senders from Sender Verification Rules Based on Sender’s Email Address
Procedure
Step 1 Select Mail Policies > Exception Table.
Note The exception table applies globally to all mail flow policies with “Use Exception Table” enabled.
Step 2 Click Add Domain Exception on the Mail Policies > Exception Table page.
Step 3 Enter an email address. You can enter a specific address ([email protected]), a name (user@), a domain
(@example.com or @.example.com), or an address with a bracketed IP address (user@[192.168.23.1]).
Step 4 Specify whether to allow or reject messages from the address. When rejecting mail, you can also specify an
SMTP code and custom response.
Step 5 Submit and commit your changes.
Searching for Addresses within the Sender Verification Exception Table
Procedure
Step 1 Enter the email address in the Find Domain Exception section of the Exception Table page.
Step 2 Click Find.
If the address matches any of the entries in the table, the first matching entry is displayed.
Testing Your Settings for Messages from Unverified Senders
Now that you have configured sender verification settings, you can verify the behavior of your email gateway.
Note that testing DNS-related settings is beyond the scope of this document.
Related Topics
• Sending a Test Message with a Malformed MAIL FROM Sender Address, on page 131
• Sending a Message from an Address That is Excluded from Sender Verification Rules, on page 131
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
130
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Sending a Test Message with a Malformed MAIL FROM Sender Address
Sending a Test Message with a Malformed MAIL FROM Sender Address
While it may be difficult to test the various DNS-related settings for your THROTTLED policy, you can test
the malformed MAIL FROM setting.
Procedure
Step 1 Open a Telnet session to your email gateway.
Step 2 Use SMTP commands to send a test message with a malformed MAIL FROM (something like “admin”
without a domain).
Note If you have configured your email gateway to use a default domain or to specifically allow partial
domains when sending or receiving email or if you have enabled address parsing (see the
“Configuring the Gateway to Receive Email” chapter) you may not be able to create, send, and
receive an email with a missing or malformed domain.
Step 3 Verify that the message is rejected.
# telnet IP_address_of_Email_Security_Appliance port
220 hostname ESMTP
helo example.com
250 hostname
mail from: admin
553 #5.5.4 Domain required for sender address
Note that the SMTP code and response is the one you configured for the envelope sender verification settings
for the THROTTLED mail flow policy.
Sending a Message from an Address That is Excluded from Sender Verification Rules
To confirm that mail from the email address listed in the sender verification exception table is not subject to
envelope sender verification:
Procedure
Step 1 Add the following address to the exception table with an “Allow” behavior: [email protected]
Step 2 Commit your changes.
Step 3 Open a Telnet session to your email gateway.
Step 4 Use SMTP commands to send a test message from the email address you entered in the sender verification
exception table ([email protected]).
Step 5 Verify that the message is accepted.
# telnet IP_address_of_Email_Security_Appliance port
220 hostname ESMTP
helo example.com
250 hostname
mail from: [email protected]
250 sender <[email protected]> ok
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
131
Defining Which Hosts Are Allowed to Connect Using the Host Access Table
Sender Verification and Logging
If you remove that email address from the sender verification exception table, mail from that sender will be
rejected because the domain portion of the envelope sender is not DNS verified.
Sender Verification and Logging
The following log entries provide an example of Sender Verification verdicts.
Related Topics
• Envelope Sender Verification, on page 132
Envelope Sender Verification
Malformed Envelope Senders:
Thu Aug 10 10:14:10 2006 Info: ICID 3248 Address: <user> sender rejected, envelope sender
domain missing
Domain does not exist (NXDOMAIN):
Wed Aug 9 15:39:47 2006 Info: ICID 1424 Address: <[email protected]> sender rejected, envelope
sender domain does not exist
Domain does not resolve (SERVFAIL):
Wed Aug 9 15:44:27 2006 Info: ICID 1425 Address: <[email protected]> sender rejected, envelope
sender domain could not be resolved
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
132
CHAPTER 8
Accepting or Rejecting Connections Based on
Domain Name or Recipient Address
This chapter contains the following sections:
• Overview of Accepting or Rejecting Connections Based on the Recipient’s Address, on page 133
• Overview of the Recipient Access Table (RAT), on page 134
• Accessing the RAT using the GUI, on page 134
• Accessing the RAT using the CLI, on page 134
• Editing the Default RAT Entry, on page 134
• Domains and Users, on page 135
Overview of Accepting or Rejecting Connections Based on the
Recipient’s Address
AsyncOS uses a Recipient Access Table (RAT) for each public listener to manage accept and reject actions
for recipient addresses. Recipient addresses include these:
• Domains
• Email addresses
• Groups of email addresses
The System Setup Wizard guides the administrator in configuring at least one public listener (with default
values) on the email gateway. Configuring a public listener during setup involves specifying default local
domains or specific addresses to accept mail. These local domains or specific addresses are the first entries
in the RAT for that public listener.
For each public listener, the default entry, “All Other Recipients”, rejects email from all recipients. The
administrator defines all local domains for which the email gateway accepts messages. Optionally, you can
also define specific users for whom the email gateway will accept or reject messages. AsyncOS allows you
to define acceptable local domains and specific users using the Recipient Access Table (RAT).
You might need to configure a listener to accept messages for multiple domains. For example, if your
organization uses the domain currentcompanyname.com and it previously used oldcompanyname.com , then
you might accept messages for both currentcompanyname.com and oldcompanyname.com . In this case, include
both local domains in the RAT for your public listener.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
133
Accepting or Rejecting Connections Based on Domain Name or Recipient Address
Overview of the Recipient Access Table (RAT)
(Note: the Domain Map feature can map messages from one domain to another. See the Domain Map feature
section of the “Configuring Routing and Delivery Features” chapter.)
Overview of the Recipient Access Table (RAT)
The Recipient Access Table defines which recipients are accepted by a public listener. At a minimum, the
table specifies the address and whether to accept or reject it.
The Recipient Access Table (RAT) page shows a listing of the entries in the RAT including the order, default
action, and whether or not the entry has been configured to bypass LDAP accept queries.
Accessing the RAT using the GUI
GUI
Procedure
Navigate to Mail Policies > Recipient Access Table (RAT).
Accessing the RAT using the CLI
CLI
Procedure
Use the listenerconfig command with the edit > rcptaccess > new subcommands.
Editing the Default RAT Entry
Before you begin
• Set up a public listener.
• Plan edits with caution, ensuring you do not create an open relay on the Internet. An open relay (sometimes
called an “insecure relay” or a “third-party” relay) is an SMTP email server that allows third-party relay
of email messages. By processing mail that is neither for — nor from — a local user, an open relay makes
it possible for an unscrupulous sender to route large volumes of spam through your gateway. By default,
the RAT rejects all recipients to prevent creation of an open relay.
• Note that you cannot delete the default entry from the RAT.
Procedure
Step 1 Navigate to Mail Policies > Recipient Access Table (RAT).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
134
Accepting or Rejecting Connections Based on Domain Name or Recipient Address
Domains and Users
Step 2 Click All Other Recipients.
Domains and Users
Modifying the Domains For Which to Accept Messages using the RAT
Use the Mail Policies > Recipient Access Table (RAT) page to configure the local domains and specific users
for which the email gateway accepts messages. On this page, you can perform the following tasks:
• Add, delete, and modify entries in the RAT.
• Change the order of the entries.
• Export RAT entries to a text file.
• Import RAT entries from a text file. Importing from a text file overwrites the existing entries.
Related Topics
• Adding Domains and Users For Which to Accept Messages, on page 135
• Rearranging the Order of Domains and Users in the Recipient Access Table, on page 137
• Exporting the Recipient Access Table to an External File, on page 138
• Importing the Recipient Access Table from an External File, on page 138
Adding Domains and Users For Which to Accept Messages
Procedure
Step 1 Navigate to the Mail Policies > Recipient Access Table (RAT) page.
Step 2 Choose the listener to edit in the Overview for Listener field.
Step 3 Click Add Recipient.
Step 4 Select an order for the entry.
Step 5 Enter the recipient address.
Step 6 Choose to accept or reject the recipient.
Step 7 (Optional) Choose to bypass LDAP acceptance queries for the recipient.
Step 8 (Optional) Use a custom SMTP response for this entry.
a) Select Yes for Custom SMTP Response.
b) Enter an SMTP response code and text. Include the SMTP response to the RCPT TO command for the
recipient.
Step 9 (Optional) Choose to bypass throttling by selecting Yes for Bypass Receiving Control.
Step 10 Submit and commit your changes.
What to do next
Related Topics
• Defining Recipient Addresses, on page 136
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
135
Accepting or Rejecting Connections Based on Domain Name or Recipient Address
Defining Recipient Addresses
• Bypassing LDAP Accept for Special Recipients, on page 136
• Bypassing Throttling for Special Recipients, on page 137
Defining Recipient Addresses
The RAT allows you to define a recipient or group of recipients. Recipients can be defined by full email
address, domain, partial domain, username, or IP address:
[IPv4 address] Specific Internet Protocol version 4 (IPv4) address of the host. Note that the
IP address must be between the “ [] ” characters.
[IPv6 address] Specific Internet Protocol version 6 (IPv6) address of the host. Note that the
IP address must be between the “ [] ” characters.
division.example.com Fully-qualified domain name.
.partialhost Everything within the “partialhost” domain.
user@domain Complete email address.
user@ Anything with the given username.
user@[IP_address ] Username at a specific IPv4 or IPv6 address. Note that the IP address must
be between the “ [] ” characters.
Note that “ user@IP_address ” (without the bracket characters) is not a valid
address. The system will append the brackets when it receives the message
to create a valid address, which could affect whether a recipient is matched
in the RAT.
Note When you add a domain to the Recipient Access Table in step 4 of the System Setup Wizard in the GUI (see
Step 3: Network, on page 43), you might want to consider adding a second entry to specify subdomains. For
example, if you type the domain example.net , you might also want to enter .example.net . The second
entry ensures that mail destined for any subdomain of example.net will match in the Recipient Access Table.
Note that only specifying .example.com in the RAT will accept for all subdomains of .example.com but will
not accept mail for complete email address recipients without a subdomain (for example [email protected]).
Bypassing LDAP Accept for Special Recipients
If you configure LDAP acceptance queries, you may wish to bypass the acceptance query for certain recipients.
This feature can be useful if there are recipients for whom you receive email which you do not want to be
delayed or queued during LDAP queries, such as [email protected] .
If you configure the recipient address to be rewritten in the work queue prior to the LDAP acceptance query,
(such as aliasing or using a domain map), the rewritten address will not bypass LDAP acceptance queries.
For example you use an alias table to map [email protected] to [email protected] and
[email protected] . If you configure bypassing LDAP acceptance for [email protected] , an LDAP
acceptance query is still run for [email protected] and [email protected] after the aliasing takes place.
To configure bypassing LDAP acceptance via the GUI, select Bypass LDAP Accept Queries for this
Recipient when you add or edit the RAT entry.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
136
Accepting or Rejecting Connections Based on Domain Name or Recipient Address
Bypassing Throttling for Special Recipients
To configure bypassing LDAP acceptance queries via the CLI, answer yes to the following question when
you enter recipients using the listenerconfig -> edit -> rcptaccess command:
Would you like to bypass LDAP ACCEPT for this entry? [Y]> y
When you configure a RAT entry to bypass LDAP acceptance, be aware that the order of RAT entries affects
how recipient addresses are matched. The RAT matches the recipient address with the first RAT entry that
qualifies. For example, you have the following RAT entries: [email protected] and ironport.com.
You configure the entry for [email protected] to bypass LDAP acceptance queries, and you configure
the entry for ironport.com for ACCEPT. When you receive mail for [email protected], the LDAP
acceptance bypass will occur only if the entry for [email protected] is before the entry for ironport.com.
If the entry for ironport.com is before the [email protected] entry, the RAT matches the recipient
address to this entry and applies the ACCEPT action.
Bypassing Throttling for Special Recipients
For recipient entries, you can specify that the recipient bypasses throttling control mechanisms enabled on
the listener.
This feature is useful if there are certain recipients for whom you do not want to limit messages. For example,
many users will want to receive email for the address “ postmaster@domain ” on a listener, even if the sending
domain is being throttled based on the receiving control defined in mail flow policies. Specifying this recipient
to bypass receiving control in a listener’s RAT allows the listener to receive unlimited messages for the
recipient “ postmaster@domain ” while retaining mail flow policies for other recipients in the same domain.
Recipients will avoid being counted against the recipients-per-hour counter maintained by the system if the
sending domain is being limited.
To specify certain recipients to bypass receiving control via the GUI, select Yes for the “Bypass Receiving
Control” setting when adding or editing a RAT entry:
To specify certain recipients to bypass receiving control via the CLI, answer yes to the following question
when you enter recipients using the listenerconfig > edit > rcptaccess command:
Would you like to bypass receiving control for this entry? [N]> y
Rearranging the Order of Domains and Users in the Recipient Access Table
Procedure
Step 1 Navigate to the Mail Policies > Recipient Access Table (RAT) page.
Step 2 Choose the listener to edit in the Overview for Listener field.
Step 3 Click Edit Order.
Step 4 Change the order by arranging the values in the Order column.
Step 5 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
137
Accepting or Rejecting Connections Based on Domain Name or Recipient Address
Exporting the Recipient Access Table to an External File
Exporting the Recipient Access Table to an External File
Procedure
Step 1 Navigate to the Mail Policies > Recipient Access Table (RAT) page.
Step 2 Choose the listener to edit in the Overview for Listener field.
Step 3 Click Export RAT.
Step 4 Enter a file name for the exported entries.
This is the name of the file that will be created in the configuration directory on the email gateway.
Step 5 Submit and commit your changes.
Importing the Recipient Access Table from an External File
When you import Recipient Access Table entries from a text file, all of the existing entries are removed from
the Recipient Access Table.
Procedure
Step 1 Navigate to the Mail Policies > Recipient Access Table (RAT) page.
Step 2 Choose the listener to edit in the Overview for Listener field.
Step 3 Click Import RAT.
Step 4 Select a file from the list.
AsyncOS lists all text files in the configuration directory on the email gateway.
Step 5 Click Submit.
A warning message displays asking you to confirm that you want to remove all of the existing Recipient
Access Table entries.
Step 6 Click Import.
Step 7 Commit your changes.
You can place “comments” in the file. Lines that begin with a ‘#’ character are considered comments and are
ignored by AsyncOS. For example:
Example:
# File exported by the GUI at 20060530T220526
.example.com ACCEPT
ALL REJECT
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
138
CHAPTER 9
Using Message Filters to Enforce Email Policies
The email gatewaycontains extensive content scanning and message filtering technology that allows you to
enforce corporate policies and act on specific messages as they enter or leave your corporate networks.
This chapter contains information about the powerful combinations of features available for policy enforcement:
a content scanning engine, message filters, attachment filters, and content dictionaries.
This chapter contains the following sections:
• Overview, on page 139
• Components of a Message Filter, on page 140
• Message Filter Processing, on page 142
• Message Filter Rules, on page 147
• Message Filter Actions, on page 194
• Attachment Scanning, on page 225
• Detecting Malicious Files in Messages Attachments Using Message Filter , on page 235
• Using the CLI to Manage Message Filters, on page 236
• Message Filter Examples, on page 251
• Configuring Scan Behavior, on page 258
Overview
Message filters allow you to create special rules describing how to handle messages as they are received by
the email gateway. A message filter specifies that a certain kind of email message should be given special
treatment. Cisco message filters also allow you to enforce corporate email policy by scanning the content of
messages for words you specify. This chapter contains the following sections:
• Components of a message filter. Message filters allow you to create special rules describing how to
handle messages as they are received. Filter rules identify messages based on message or attachment
content, information about the network, message envelope, message headers, or message body. Filter
actions generate notifications or allow messages to be dropped, bounced, archived, blind carbon copied,
or altered. For more information, see Components of a Message Filter, on page 140.
• Processing Message Filters. When AsyncOS processes message filters, the content that AsyncOS scans,
the order of the processing, and the actions taken are based on several factors, including the message
filter order, any prior processing that may have altered the message content, the MIME structure of the
message, the threshold score configured for content matching, and structure of the query. For more
information, see Message Filter Processing, on page 142.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
139
Using Message Filters to Enforce Email Policies
Components of a Message Filter
• Message Filter Rules. Each filter has a rule that defines the collection of messages that the filter can act
upon. You define those rules when you create a message filter. For more information, see Message Filter
Rules, on page 140.
• Message Filter Actions. Each filter has an action that is performed on a message if the rule evaluates
to true . There are two types of actions that can be performed: final actions (such as delivering, dropping,
or bouncing a message), or non-final actions (such as stripping or inserting a header) which permit the
message to be further processed. For more information, see Message Filter Actions, on page 140.
• Attachment Scanning Message Filters. Attachment scanning message filters allow you to strip
attachments from messages that are inconsistent with your corporate policies, while still retaining the
ability to deliver the original message. You can filter attachments based on their specific file type,
fingerprint, or content. You can also scan image attachments using an image analyzer. The image analyzer
uses algorithms that measure image attributes to determine the likelihood of inappropriate content. These
algorithms can detect, for example, the shapes and color palette in an image. The analyzer can identify
the type of shapes in an image and the percentage of any flesh-tone colors relative to the other colors in
the image to help identify inappropriate content. Images with a high percentage of flesh-tone colors are
more likely to be inappropriate. The algorithms do not discriminate in any way. For more information,
see Attachment Scanning, on page 225.
• Using the CLI to Manage Message Filters. The CLI accepts commands for working with message
filters. For example, you might want to display, reorder, import or export a list of message filters. For
more information, see Using the CLI to Manage Message Filters, on page 236.
• Message Filter Examples. This section contains some real world examples of filters with a brief discussion
of each. For more information, see Message Filter Examples, on page 251.
Components of a Message Filter
Message filters allow you to create special rules describing how to handle messages as they are received. A
message filter is comprised of message filter rules and message filter actions.
Related Topics
• Message Filter Rules, on page 140
• Message Filter Actions, on page 140
• Message Filter Example Syntax, on page 141
Message Filter Rules
Message filter rules determine the messages that a filter will act on. Rules may be combined using the logical
connectors AND, OR, and NOT to create more complex tests. Rule expressions may also be grouped using
parentheses.
Message Filter Actions
The purpose of message filters is to perform actions on selected messages.
The two types of actions are:
• Final actions — such as deliver , drop , and bounce — end the processing of a message, and permit no
further processing through subsequent filters.
• Non-final actions perform an action which permits the message to be processed further.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
140
Using Message Filters to Enforce Email Policies
Message Filter Example Syntax
Note Non-final message filter actions are cumulative. If a message matches multiple filters where each filter specifies
a different action, then all actions are accumulated and enforced. However, if a message matches multiple
filters specifying the same action, the prior actions are overridden and the final filter action is enforced.
Related Topics
• Filter Actions Summary Table, on page 194
• Action Variables, on page 203
• Matched Content Visibility, on page 205
• Description and Examples of Message Filter Actions, on page 206
Message Filter Example Syntax
The intuitive meaning of a filter specification is:
if the message matches the rule, then apply the actions in sequence. If the else clause is present, the actions
within the else clause are executed in the event the message does not match the rule.
The name of the filter you specify makes it easier to manage filters when you are activating, deactivating, or
deleting them.
Message filters use the following syntax:
Example Syntax Purpose
expedite: filter name
if (recv-listener == 'InboundMail' or recv-int == 'notmain') rule specification
action specification
{
alt-src-host('outbound1');
skip-filters();
}
optional alternative action specification
else
{
alt-src-host('outbound2');
}
Note that you can omit any alternative actions:
Example Syntax Purpose
expedite2: filter name
rule specification
if ((not (recv-listener == 'InboundMail')) and
(not (recv-int == 'notmain')))
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
141
Using Message Filters to Enforce Email Policies
Message Filter Processing
Example Syntax Purpose
action specification
{
alt-src-host('outbound2');
skip-filters();
You can combine several filters in sequence within a single text file, one following the other.
You must enclose the values in filters in either single or double quotation marks. Single or double quotation
marks must be equally paired on each side of the value; for example, the expressions
notify('[email protected]') and notify("[email protected]") are both legal, but the
expression notify("[email protected]') causes a syntax error.
Lines beginning with a ‘ # ’ character are considered comments and are ignored; however, they are not
preserved by AsyncOS as can be verified by viewing a filter via filters -> detail .
Message Filter Processing
When AsyncOS processes message filters, the content that AsyncOS scans, the order of the processing, and
the actions taken are based on several factors:
• Message filter order. Message filters are maintained in an ordered list. When a message is processed,
AsyncOS applies each message filter in the order it appears in the list. If a final action occurs, no further
action is taken on the message. For more information, see Message Filter Order, on page 143.
• Prior processing. Actions performed on AsyncOS messages may add or remove headers before the
message filter is evaluated. AsyncOS processes the message filter process on the headers that are present
in the message at the time of processing. For more information, see Message Header Rules and Evaluation,
on page 143.
• The MIME structure of the message. The MIME structure of the message determines which part of
the message is treated as “body,” and which part of the message is treated as an “attachment”. Many
message filters are configured to act on just the body or just the attachment part of the message. For more
information, see Message Bodies vs. Message Attachments, on page 143.
• The threshold score configured for the regular expression. When you match a regular expression,
you configure a “score” to tally up the number of times a match must occur before a filter action is taken.
This allows you to “weight” the responses to different terms. For more information, see Thresholds for
Matches in Content Scanning, on page 144 .
• The structure of the query. When evaluating AND or OR tests within message filters, AsyncOS does
not evaluate unneeded tests. In addition, it is important to note that the system does not evaluate the tests
from left to right. Instead, when AND and OR tests are evaluated, the least expensive test is evaluated
first. For more information, see AND Test and OR Tests in Message Filters, on page 147.
Related Topics
• Message Filter Order, on page 143
• Message Header Rules and Evaluation, on page 143
• Message Bodies vs. Message Attachments, on page 143
• Thresholds for Matches in Content Scanning, on page 144
• AND Test and OR Tests in Message Filters, on page 147
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
142
Using Message Filters to Enforce Email Policies
Message Filter Order
Message Filter Order
Message filters are kept in an ordered list and numbered by their position in the list. When a message is
processed, the message filters are applied in the associated numeric order. Therefore, filter number 30 will
not have a chance to alter the source host of a message if filter number 9 has already executed a final action
on (for example, bounced) the message. The position of a filter in the list can be changed via the system user
interfaces. Filters imported via a file are ordered based on their relative order in the imported file.
After a final action, no further actions may be taken on the message.
Although a message may match a filter rule, the filter may not act upon that message for any of the following
reasons:
• The filter is inactive.
• The filter is invalid.
• The filter has been superseded by an earlier filter that executed a final action for the message.
Message Header Rules and Evaluation
Filters evaluate “processed” headers rather than the original message headers when applying header rules.
Thus:
• If a header was added by a previous processing action, it can now be matched by any subsequent header
rule.
• If a header was stripped by a previous processing action, it can no longer be matched by any subsequent
header rule.
• If a header was modified by a previous processing action, any subsequent header rule will evaluate the
modified header and not the original message header.
This behavior is common to both message filters and content filters.
Message Bodies vs. Message Attachments
An email message is composed of multiple parts. Although RFCs define everything that comes after a message’s
headers as a multipart “message body,” many users still conceptualize a message’s “body” and its “attachment”
differently. When you use any of the Cisco message filters named body- variable or attachment-variable ,
the email gateway attempts to distinguish the parts that most users consider to be the “body” and the
“attachment” in the same way that many MUAs attempt to render these parts differently.
For the purposes of writing body - variable or attachment-variable message filter rules, everything after the
message headers is considered the message body , whose content is considered the first text part of the MIME
parts that are within the body. Anything after the content, (that is, any additional MIME parts) is considered
an attachment . AsyncOS evaluates the different MIME parts of the message, and identifies the parts of the
file that is treated as an attachment.
For example, The following figure shows a message in the Microsoft Outlook MUA where the words “
Document attached below. ” appear as a plain text message body and the document “ This is a Microsoft
Word document.doc ” appears as an attachment . Because many users conceptualize email this way (rather
than as a multipart message whose first part is plain text and whose second part is a binary file), the Cisco
uses the term “attachment” in message filters to create rules to differentiate and act on the .doc file part (in
essence, the second MIME part) as opposed to the “body” of the message (the first, plain text part) — although,
according to the language used in RFCSs 1521 and 1522, a message’s body is comprised of all MIME parts.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
143
Using Message Filters to Enforce Email Policies
Thresholds for Matches in Content Scanning
Figure 16: Message with “Attachment"
Because the email gateway makes this distinction between the body and the attachment in multipart messages,
there are several cases you should be aware of when using the body - variable or attachment-variable message
filter rules in order to achieve the expected behavior:
• If you have a message with a single text part—that is, a message containing a header of “Content-Type:
text/plain” or “Content-Type: text/html” — the email gateway will consider the entire message as the
body. If the content type is anything different, the email gateway considers it to be a single attachment.
• Some encoded files (uuencoded, for example) are included in the body of the email message. When this
occurs, the encoded file is treated as an attachment, and it is extracted and scanned, while the remaining
text is considered to be the body of the text.
• A single, non-text part is always considered an attachment . For example, a message consisting of only
a.zip file is considered an attachment.
Thresholds for Matches in Content Scanning
When you add filter rules that search for patterns in the message body or attachments, you can specify the
minimum threshold for the number of times the pattern must be found. When AsyncOS scans the message,
it totals the “score” for the number of matches it finds in the message and attachments. If the minimum
threshold is not met, the regular expression does not evaluate to true. You can specify this threshold for the
following filter rules:
• body-contains
• only-body-contains
• attachment-contains
• every-attachment-contains
• dictionary-match
• attachment-dictionary-match
You can also specify a threshold value for the drop-attachments-where-contains action.
Note You cannot specify thresholds for filter rules that scan headers or envelope recipients and senders.
Related Topics
• Threshold Syntax, on page 145
• Threshold Scoring for Message Bodies and Attachments, on page 145
• Threshold Scoring Multipart/Alternative MIME Parts, on page 145
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
144
Using Message Filters to Enforce Email Policies
Threshold Syntax
• Threshold Scoring for Content Dictionaries, on page 146
Threshold Syntax
To specify a threshold for the minimum number of occurrences, specify the pattern and the minimum number
of matches required to evaluate to true:
if(<filter rule>('<pattern>',<minimum threshold>)){
For example, to specify that the body-contains filter rule must find the value “Company Confidential” at least
two times, use the following syntax:
if(body-contains('Company Confidential',2)){
By default, when AsyncOS saves a content scanning filter, it compiles the filter and assigns a threshold value
of 1, if you have not assigned a value.
You can also specify a minimum number of pattern matches for values in a content dictionary. For more
information about content dictionaries, see the “Text Resources” chapter.
Threshold Scoring for Message Bodies and Attachments
An email message may be composed of multiple parts. When you specify threshold values for filter rules that
search for patterns in the message body or attachments, AsyncOS counts the number of matches in the message
parts and attachments to determine the threshold “score.” Unless the message filter specifies a specific MIME
part (such as the attachment-contains filter rule), AsyncOS will total the matches found in all parts of the
message to determine if the matches total the threshold value. For example, you have a body-contains message
filter with a threshold of 2. You receive a message in which the body contains one match, and the attachment
contains one match. When AsyncOS scores this message, it totals the two matches and determines that the
threshold score has been met.
Similarly, if you have multiple attachments, AsyncOS totals the scores for each attachment to determine the
score for matches. For example, you have an attachment-contains filter rule with a threshold of 3. You
receive a message with two attachments, and each attachment contains two matches. AsyncOS would score
this message with four matches and determine that the threshold score has been met.
Threshold Scoring Multipart/Alternative MIME Parts
To avoid duplicate counting, if there are two representatives of the same content (plain text and HTML),
AsyncOS does not total the matches from the duplicate parts. Instead, it compares the matches in each part
and selects the highest value. AsyncOS would then add this value to the scores from other parts of the multipart
message to create a total score.
For example, you configure a body-contains filter rule and set the threshold to 4. You then receive a message
that contains both plain text, HTML and two attachments. The message would use the following structure:
multipart/mixed
multipart/alternative
text/plain
text/html
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
145
Using Message Filters to Enforce Email Policies
Threshold Scoring for Content Dictionaries
application/octet-stream
application/octet-stream
The body-contains filter rule would determine the score for this message by first scoring the text/plain and
text/html parts of the message. It would then compare the results of these scores and select the highest score
from the results. Next, it would add this result to the score from each of the attachments to determine the final
score. Suppose the message has the following number of matches:
multipart/mixed
multipart/alternative
text/plain (2 matches)
text/html (2 matches)
application/octet-stream (1 match)
application/octet-stream
Because AsyncOS compares the matches for the text/plain and text/html parts, it returns a score of 3, which
does not meet the minimum threshold to trigger the filter rule.
Threshold Scoring for Content Dictionaries
When you use a content dictionary, you can “weight” terms so that certain terms trigger filter actions more
easily. For example, you may want not want to trigger a message filter for the term, “bank.” However, if the
term, “bank” is combined with the term, “account,” and accompanied with an ABA routing number, you may
want to trigger a filter action. To accomplish this, you can use a weighted dictionary to give increased
importance to certain terms or a combination of terms. When a message filter that uses a content dictionary
scores the matches for filter rule, it uses these weights to determine the final score. For example, suppose you
create a content dictionary with the following contents and weights:
Table 20: Sample Content Dictionary
Term/Smart Identifier Weight
ABA Routing Number 3
Account 2
Bank 1
When you associate this content dictionary with a dictionary-match or attachment-dictionary-match
message filter rule, AsyncOS would add the weight for the term to the total “score” for each instance of the
matching term found in the message. For example, if the message contains three instances of the term, “account”
in the message body, AsyncOS would add a value of 6 to the total score. If you set the threshold value for the
message filter to 6, AsyncOS would determine that the threshold score has been met. Or, if the message
contained one instance of each term, the total value would be 6, and this score would trigger the filter action.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
146
Using Message Filters to Enforce Email Policies
AND Test and OR Tests in Message Filters
AND Test and OR Tests in Message Filters
When evaluating AND or OR tests within message filters, AsyncOS does not evaluate unneeded tests. So,
for example, if one side of an AND test is false, the system will not evaluate the other side. It is important to
note that the system does not evaluate the tests from left to right. Instead, when AND and OR tests are evaluated,
the least expensive test is evaluated first. For example, in the following filter, the remote-ip test will always
be processed first because it has a lower cost than the rcpt-to-group test (generally LDAP tests are more
expensive):
andTestFilter:
if (remote-ip == "192.168.100.100" AND rcpt-to-group == "GROUP")
{ ... }
Because the least expensive test is performed first, switching the order of the items in the test will have no
effect. If you want to guarantee the order in which tests are performed, use nested if statements. This is also
the best way to ensure that an expensive test is avoided whenever possible:
expensiveAvoid:
if (<simple tests>)
{ if (<expensive test>)
{ <action> }
In a somewhat more complicated example, consider:
if (test1 AND test2 AND test3) { ... }
The system groups the expression from left to right, so this becomes:
if ((test1 AND test2) AND test3) { ... }
This means the first thing the system does is compare the cost of (test1 AND test2) against the cost of test3
, evaluating the second AND first. If all three tests have the same cost, then test3 will be performed first
because (test1 AND test2) would be twice as expensive.
Message Filter Rules
Each message filter contains a rule that defines the collection of messages that a filter can act upon. You define
the filter rules, and then you define a filter action for messages that return true .
Related Topics
• Filter Rules Summary Table, on page 148
• Regular Expressions in Rules, on page 158
• Smart Identifiers, on page 162
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
147
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
• Description and Examples of Message Filter Actions, on page 206
Filter Rules Summary Table
The following table summarizes the rules you can use in message filters.
Table 21: Message Filter Rules
Rule Syntax Description
Subject Header subject Does the subject header match a
certain pattern? See Subject Rule,
on page 165.
Body Size body-size Is the body size within some range?
See Body Size Rule, on page 168.
Envelope Sender mail-from Does the Envelope Sender (i.e., the
Envelope From, <MAIL FROM>)
match a given pattern? See
Envelope Sender Rule, on page 167.
Envelope Sender in Group mail-from-group Is the Envelope Sender (i.e., the
Envelope From, <MAIL FROM>)
in a given LDAP group? See
Envelope Sender in Group Rule, on
page 167.
Sender Group sendergroup Which sender group was matched
in a listener's Host Access Table
(HAT)? See Sender Group Rule,
on page 167.
Envelope Recipient rcpt-to Does the Envelope Recipient, (i.e.
the Envelope To, <RCPT TO>)
match a given pattern? See
Envelope Recipient Rule, on page
166.
Note The rcpt-to rule is
message-based. If a
message has multiple
recipients, only one
recipient has to match
the rule for the specified
action to affect the
message to all
recipients.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
148
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
Envelope Recipient in Group rcpt-to-group Is the Envelope Recipient, (i.e. the
Envelope To, <RCPT TO>) in a
given LDAP group? See Envelope
Recipient in Group Rule, on page
166.
Note The rcpt-to-group rule
is message-based. If a
message has multiple
recipients, only one
recipient has to be found
in a group for The
rcptthe specified action
to affect the message to
all recipients.
Remote IP remote-ip Was the message sent from a
remote host that matches a given
IP address or IP block? See Remote
IP Rule, on page 169.
Receiving Interface recv-int Did the message arrive via the
named receiving interface? See
.Receiving IP Interface Rule, on
page 169
Receiving Listener recv-listener Did the message arrive via the
named listener? See Receiving
Listener Rule, on page 169.
Date date Is current time before or after a
specific time and date? See Date
Rule, on page 169.
Header header(<string>) Does the message contain a specific
header? Does the value of that
header match a certain pattern? See
Header Rule, on page 170.
Random random(<integer>) Is a random number in some range?
See Random Rule, on page 170.
Recipient Count rcpt-count How many recipients is this email
going to? See Recipient Count
Rule, on page 171.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
149
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
Address Count addr-count() What is the cumulative number of
recipients?
This filter differs from the
rcpt-count filter rule in that it
operates on the message body
headers instead of the envelope
recipients. See Address Count Rule,
on page 171.
SPF Status spf-status What was the SPF verification
status? This filter rule allows you
to query for different SPF
verification results. You can enter
a different action for each valid
SPF/SIDF return value. See
SPF-Status Rule, on page 177.
SPF Passed spf-passed Did the SPF/SIDF verification
pass? This filter rule generalizes the
SPF/SIDF results as a Boolean
value. See SPF-Passed Rule, on
page 179.
S/MIME Gateway Message smime-gateway Is the message S/MIME signed,
encrypted, or signed and encrypted?
See S/MIME Gateway Message
Rule, on page 179
S/MIME Gateway Verified smime-gateway-verified Is the S/MIME message
successfully verified, decrypted, or
decrypted and verified? See
S/MIME Gateway Verified Rule,
on page 180.
Image verdict image-verdict What was the image scanning
verdict? This filter rule allows you
to query for different image
analysis verdicts. See Image
Analysis, on page 228.
Workqueue count workqueue-count Is the work queue count equal to,
less than, or greater than the
specified value? See
Workqueue-count Rule, on page
180.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
150
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
Body Scanning body-contains( Does the message contain text or
<regular expression>)
an attachment that matches a
specified pattern? Does the pattern
occur the minimum number of
times you specified for the
threshold value?
The engine scans delivery-status
parts and associated attachments.
See Body Scanning , on page 172.
Body Scanning only-body-contains Does the message body contain text
(<regular expression>)
that matches a specified pattern?
Does the pattern occur the
minimum number of times you
specified for the threshold value?
Attachments are not scanned. See
Body Scanning Rule, on page 172.
Encryption Detection encrypted Is the message encrypted? See
Encryption Detection Rule, on page
173.
Attachment Filename attachment-filename Does the message contain an
attachment with a filename that
matches a specific pattern? See
Attachment Filename Rule, on page
174.
Attachment Type attachment-type Does the message contain an
attachment of a particular MIME
type? See Attachment Type Rule,
on page 173.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
151
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
Attachment File Type attachment-filetype Does the message contain an
attachment of a file type that
matches a specific pattern based on
its fingerprint (similar to a UNIX
file command)? If the attachment
is an Excel or Word document, you
can also search for the following
embedded file types: .exe , .dll,
.bmp, .tiff, .pcx, .gif, .jpeg, png, and
Photoshop images.
You must enclose the file type in
quotes to create a valid filter. You
can use single or double quotes. For
example, to search for .exe
attachments, use the following
syntax:
if (attachment-filetype ==
"exe")
For more information, see
Attachment Filenames and Single
Compressed Files within Archive
Files, on page 174.
Attachment MIME Type attachment-mimetype Does the message contain an
attachment of a specific MIME
type? This rule is similar to the
attachment-type rule, except only
the MIME type given by the MIME
attachment is evaluated. (The email
gateway does not try to “guess” the
type of the file by its extension if
there is no explicit type given.) See
Examples of Attachment Scanning
Message Filters, on page 232.
Attachment File Hash List attachment-hashlist-match Does the message contain an
attachment that matches the specific
file SHA-256 value in the file hash
list? See Drop Message
Attachments that match File
SHA-256 Filter, on page 258 and
Drop Messages if Attachment
matches File SHA-256 Filter, on
page 258.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
152
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
Attachment Protected attachment-protected Does the message contain an
attachment that is password
protected? See Quarantining
Protected Attachments, on page 235.
Attachment Unprotected attachment-unprotected The attachment-unprotected filter
condition returns true if the
scanning engine detects an
attachment that is unprotected. A
file is considered unprotected if the
scanning engine was able to read
the attachment. A zip file is
considered to be unprotected if any
of its members is unprotected.
Note — The
attachment-unprotected filter
condition is not mutually exclusive
of the attachment-protected filter
condition. It is possible for both
filter conditions to return true when
scanning the same attachment. This
can occur, for example, if a zip file
contains both protected and
unprotected members.
See Detecting Unprotected
Attachments, on page 235.
Attachment Scanning attachment-contains Does the message contain an
(<regular expression>)
attachment that contains text or
another attachment that matches a
specific pattern? Does the pattern
occur the minimum number of
times you specified for the
threshold value?
This rule is similar to the
body-contains() rule, but it
attempts to avoid scanning the
entire “body” of the message. That
is, it attempts to scan only that
which the user would view as being
an attachment. See Examples of
Attachment Scanning Message
Filters, on page 232.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
153
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
Attachment Scanning attachment-binary-contains Does the message contain an
(<regular expression>)
attachment with binary data that
matches a specific pattern?
This rule is like the
attachment-contains () rule, but
it searches specifically for patterns
in the binary data.
Attachment Scanning every-attachment-contains Do all of the attachments in this
(<regular expression>)
message contain text that matches
a specific pattern? The text must
exist in all attachments and the
action performed is, in effect, a
logical AND operation of an '
attachment-contains() ' for each
attachment. The body is not
scanned. Does the pattern occur the
minimum number of times you
specified for the threshold value?
See Examples of Attachment
Scanning Message Filters, on page
232.
Attachment Size attachment-size Does the message contain an
attachment whose size is within
some range? This rule is similar to
the body-size rule, but it attempts
to avoid scanning the entire “body”
of the message. That is, it attempts
to scan only that which the user
would view as being an attachment.
The size is evaluated prior to any
decoding. See Examples of
Attachment Scanning Message
Filters, on page 232.
Public Blocked lists dnslist(<query server>) Does the sender’s IP address appear
on a public blocked list server
(RBL)? See DNS List Rule, on
page 175.
IP Reputation reputation What is the sender’s IP Reputation
Score? See IP Reputation Rule, on
page 175.
No IP Reputation no-reputation Used to test if IP Reputation Score
is “None.” See IP Reputation Rule,
on page 175.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
154
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
Dictionary dictionary-match Does the message body contain any
(<dictionary_name>)
of the regular expressions or terms
in the content dictionary named
dictionary_name ? Does the pattern
occur the minimum number of
times you specified for the
threshold value? See Dictionary
Rules, on page 176.
Attachment Dictionary Match attachment-dictionary-match Does the attachment contain any of
(<dictionary_name>)
the regular expressions in the
content dictionary named
dictionary_name ? Does the pattern
occur the minimum number of
times you specified for the
threshold value? See Dictionary
Rules, on page 176.
Subject Dictionary Match subject-dictionary-match Does the Subject header contain
(<dictionary_name>)
any of the regular expressions or
terms in the content dictionary
named dictionary name ? See
Dictionary Rules, on page 176.
Header Dictionary Match header-dictionary-match Does the specified header (case
(<dictionary_name>,
insensitive) contain any of the
<header>)
regular expressions or terms in the
content dictionary named
dictionary name ? See Dictionary
Rules, on page 176.
Body Dictionary Match body-dictionary-match This filter condition returns true if
(<dictionary_name>)
the dictionary term matches content
in the body of the message only.
The filter searches for terms within
the MIME parts not considered to
be an attachment. and it returns true
if the user-defined threshold is met
(the default threshold value is one).
See Dictionary Rules, on page 176.
Envelope Recipient Dictionary rcpt-to-dictionary-match Does the envelope recipient contain
(<dictionary_name>)
Match any of the regular expressions or
terms in the content dictionary
named dictionary name ? See
Dictionary Rules, on page 176.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
155
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
Envelope Sender Dictionary Match mail-from-dictionary-match Does the envelope sender contain
(<dictionary_name>)
any of the regular expressions or
terms in the content dictionary
named dictionary name ? See
Dictionary Rules, on page 176.
SMTP Authenticated User Match smtp-auth-id-matches Does the address of the Envelope
(<target>[, <sieve-char>])
Sender and the address in message
header match the authenticated
SMTP user ID of the sender? See
SMTP Authenticated User Match
Rule, on page 180.
True true Matches all messages. See True
Rule, on page 165.
Valid valid Returns false if the message
contains unparsable/invalid MIME
parts and true otherwise. See Valid
Rule, on page 165.
Signed signed Is the message is signed? See
Signed Rule, on page 182.
Signed Certificate signed-certificate Does the message signer or X.509
(<field> [<operator>
certificate issuer match a certain
<regular expression>])
pattern? See Signed Certificate
Rule, on page 182.
Header Repeats header-repeats (<target>, Returns true if at a given point in
<threshold> [, <direction>])
time, a specified number of
messages:
• With same subject header are
detected in last one hour.
• From same envelope-sender
are detected in last one hour.
See Header Repeats Rule, on page
185.
URL Reputation url-reputation Is the reputation score of any URL
url-no-reputation
in the message within the specified
range?
Is a reputation score for a URL
unavailable?
See URL Reputation Rules , on
page 186 and Configuring Email
Gateway to Consume External
Threat Feeds, on page 305.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
156
Using Message Filters to Enforce Email Policies
Filter Rules Summary Table
Rule Syntax Description
URL Category url-category Does the category of any URL in
the message match the specified
categories?
See URL Category Rule , on page
187.
Corrupt Attachment attachment-corrupt Does this message have an
attachment that is corrupt?
See Corrupt Attachment Rule, on
page 188.
Message Language message-language Is the message (subject and body)
in one of the selected languages?
See Message Language Rule, on
page 188.
Macro Detection macro-detection-rule Does the incoming or outgoing
([‘file_type-1',
message contain macro-enabled
'file_type-2',
…,'file_type-n']) attachments?
See Macro Detection Rule, on page
189
Forged Email Detection forged-email-detection Is the sender address of the message
("<dictionary_name>",
forged? The rule checks if the
<threshold>)
From: header in the message is
similar to any of the users in the
content dictionary.
See Forged Email Detection Rule,
on page 190.
Duplicate Boundaries Verification duplicate_boundaries Does the message contain duplicate
MIME boundaries?
See Duplicate Boundaries
Verification Rule, on page 190.
Malformed MIME Header malformed-header Does the message contain
Detection malformed MIME headers?
See Malformed MIME Header
Detection Rule, on page 191.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
157
Using Message Filters to Enforce Email Policies
Regular Expressions in Rules
Rule Syntax Description
Geolocation geolocation-rule Does the incoming message
(['country_name-1',
originate from the selected
'country_name-2',
'country_name-n']) countries?
Note Enable the Anti-Spam
engine on your
appliance before you use
the Geolocation
message filter rule.
See Geolocation Rule, on page 191.
Domain Reputation Does the sender domain match the
Sender Domain Reputation:
specified criteria?
- sdr-reputation
(<‘sdr_verdict_range'>, • Sender Domain Reputation
<‘domain_exception
_list'>) • External Threat Feeds
- sdr-age (<‘unit'>,
<‘operator'>
<‘actual value’>) See Domain Reputation Rule for
- sdr-unscannable ETF, on page 191 or Domain
(<'domain_exception Reputation Rule for SDR, on page
_list'>)
192.
External Threat Feeds:
For more information, see the
domain-external-
threat-feeds Configuring Email Gateway to
(<'external_threat_ Consume External Threat Feeds,
feed_source_name'>, on page 305 or Sender Domain
<'header'> , <'domain
Reputation Filtering, on page 323.
_exception_list'>)
Each message injected into the email gateway is processed through all message filters in order, unless you
specify a final action, which stops the message from being processed further. (See Message Filter Actions,
on page 140.) Filters may also apply to all messages, and rules may also be combined using logical connectors
(AND, OR, NOT).
Regular Expressions in Rules
Several of the atomic tests used to define rules use regular expression matching . Regular expressions can
become complex. Use the following table as a guide for the applying of regular expressions within message
filter rules:
Table 22: Regular Expression in Rules
Regular expression ( abc ) Regular expressions in filter rules match a string if the sequence of directives
in the regular expression match any part of the string.
For example, the regular expression Georg matches the string George Of The
Jungle , the string Georgy Porgy , the string La Meson Georgette as well
as Georg .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
158
Using Message Filters to Enforce Email Policies
Regular Expressions in Rules
Carat ( ^ ) Rules containing the dollar sign character ($) only match the end of the string,
and rules containing the caret symbol ( ^ ) only match the beginning of the
Dollar sign ( $ )
string.
For example, the regular expression ^Georg$ only matches the string Georg .
Searching for an empty header would look like this: "^$"
Letters, white space and the Rules containing characters, white space, and the at sign character ( @ ) only
at sign ( @ ) character match themselves explicitly.
For example, the regular expression ^George@admin$ only matches the string
George@admin .
Period character ( . ) Rules containing a period character ( . ) match any character (except a new
line).
For example, the regular expression ^...admin$ matches the string macadmin
as well as the string sunadmin but not win32admin .
Asterisk ( * ) directive Rules containing an asterisk ( * ) match “zero or more matches of the previous
directive.” In particular, the sequence of a period and an asterisk ( .* ) matches
any sequence of characters (not containing a new line).
For example, the regular expression ^P.*Piper$ matches all of these strings:
PPiper , Peter Piper , P.Piper , and Penelope Penny Piper .
Backslash special characters The backslash character escapes special characters. Thus the sequence \. only
(\) matches a literal period, the sequence \$ only matches a literal dollar sign, and
the sequence \^ only matches a literal caret symbol. For example, the regular
expression ^ik\.ac\.uk$ only matches the string ik.ac.uk .
Important Note: The backslash is also a special escape character for the parser.
As a result, if you want to include backslash in your regular expression, you
must use two backslashes — so that after parsing, only one “real” backslash
remains, which is then passed to the regular expression system. So, if you
wanted to match the example domain above, you would enter ^ik\\.ac\\.uk$
.
Case-insensitivity ( (?i) The token (?i) that indicates the rest of the regular expression should be treated
) in case-insensitive mode. Placing this token at the beginning of a case-sensitive
regular expression results in a completely insensitive match.
For example, the regular expression “ (?i)viagra ” matches Viagra , vIaGrA
, and VIAGRA .
Number of repetitions The regular expression notation that indicates the number of repetitions of the
{min,max} previous token is supported.
For example, the expression “ fo{2,3} ” matches foo and fooo but not fo or
fofo .
This statement: if(header('To') == "^.{500,}") looks for a “To” header
that has 500 or more characters in it.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
159
Using Message Filters to Enforce Email Policies
Using Regular Expressions to Filter Messages
Or ( | ) Alternation, or the “or” operator. If A and B are regular expressions, the
expression “ A|B ” will match any string that matches either “A” or “B.”
For example, the expression “ foo|bar ” will match either foo or bar , but
not foobar .
Related Topics
• Using Regular Expressions to Filter Messages, on page 160
• Guidelines for Using Regular Expressions, on page 160
• Regular Expression and Non-ASCII Character Sets, on page 161
• n Tests, on page 161
• Case-sensitivity, on page 161
• Writing Efficient Filters, on page 161
• PDFs and Regular Expressions, on page 162
Using Regular Expressions to Filter Messages
You can use filters to search for strings and patterns in non-ASCII encoded message content (both headers
and bodies). Specifically, the system supports regular expression (regex) searching for non-ASCII character
sets within:
• Message headers
• MIME attachment filename strings
• Message body:
• Bodies without MIME headers (i.e. traditional email)
• Bodies with MIME headers indicating encoding but no MIME parts
• Multi-part MIME messages with encoding indicated
• All of the above without the encoding specified in a MIME header
You can use regular expressions (regexes) to match on any part of the message or body, including matching
attachments. The various attachment types include text, HTML, MS Word, Excel, and others. Examples of
character sets of interest include gb2312, HZ, EUC, JIS, Shift-JIS, Big5, and Unicode. Message filter rules
with regular expressions can be created through the content filter GUI, or using a text editor to generate a file
that is then imported into the system. For more information, see Using the CLI to Manage Message Filters,
on page 236 and Configuring Scan Behavior, on page 258.
Guidelines for Using Regular Expressions
It is important to begin a regular expression with a caret ( ^ ) and end it with a dollar sign ( $ ) whenever you
want to exactly match a string and not a prefix.
Note When matching an empty string, do not use “” as that actually matches all strings. Instead use “^$” . For an
example, see the second example in Subject Rule, on page 165.
It is also important to remember that if you want to match a literal period, you must use an escaped period in
the regular expression. For example, the regular expression sun.com matches the string thegodsunocommando
, but the regular expression ^sun\.com$ only matched the string sun.com.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
160
Using Message Filters to Enforce Email Policies
Regular Expression and Non-ASCII Character Sets
Technically, the style of regular expressions used are Python re Module style regular expressions. For a more
detailed discussion of Python style regular expressions, consult the Python Regular Expression HOWTO,
accessible from: http://www.python.org/doc/howto/
Regular Expression and Non-ASCII Character Sets
In some languages, the concepts of a word or word boundary, or case do not exist.
Complex regular expressions that depend on concepts like what is or is not a character that would compose
a word (represented as “ \w ” in regex syntax) cause problems when the locale is unknown or if the encoding
is not known for certain.
n Tests
Regular expressions can be tested for matching using the sequence == and for non-matching using the sequence
!= . For example:
rcpt-to ==
"^goober@dev\\.null\\....$" (matching)
rcpt-to != "^goober@dev\\.null\\....$" (non-matching)
Case-sensitivity
Unless otherwise noted, regular expressions are case-sensitive. Thus, if your regular expression is searching
for foo , it does not match the pattern FOO or even Foo .
Writing Efficient Filters
This example shows two filters that do the same thing, but the first one takes much more CPU. The second
filter uses a regular expression that is more efficient.
attachment-filter: if ((recv-listener == "Inbound") AND
((((((((((((((((((((((((((((((((((((((((((((((attachment-filename ==
"\\.386$") OR (attachment-filename == "\\.exe$")) OR (attachment-filename == "\\.ad$")) OR
(attachment-filename == "\\.ade$")) OR (attachment-filename == "\\.adp$")) OR
(attachment-filename == "\\.asp$")) OR (attachment-filename == "\\.bas$")) OR
(attachment-filename == "\\.bat$")) OR (attachment-filename == "\\.chm$")) OR
(attachment-filename == "\\.cmd$")) OR (attachment-filename == "\\.com$")) OR
(attachment-filename == "\\.cpl$")) OR (attachment-filename == "\\.crt$")) OR
(attachment-filename == "\\.exe$")) OR (attachment-filename == "\\.hlp$")) OR
(attachment-filename == "\\.hta$")) OR (attachment-filename == "\\.inf$")) OR
(attachment-filename == "\\.ins$")) OR (attachment- filename == "\\.isp$")) OR
(attachment-filename == "\\.js$")) OR (attachment-filename == "\\.jse$")) OR
(attachment- filename == "\\.lnk$")) OR (attachment-filename == "\\.mdb$")) OR
(attachment-filename == "\\.mde$")) OR (attachment-filename == "\\.msc$")) OR
(attachment-filename == "\\.msi$")) OR (attachment-filename == "\\.msp$")) OR
(attachment-filename == "\\.mst$")) OR (attachment-filename == "\\.pcd$")) OR
(attachment-filename == "\\.pif$")) OR (attachment-filename == "\\.reg$")) OR
(attachment-filename == "\\.scr$")) OR (attachment-filename == "\\.sct$")) OR
(attachment-filename == "\\.shb$")) OR (attachment-filename == "\\.shs$")) OR
(attachment-filename == "\\.url$")) OR (attachment-filename == "\\.vb$")) OR
(attachment-filename == "\\.vbe$")) OR (attachment-filename == "\\.vbs$")) OR
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
161
Using Message Filters to Enforce Email Policies
PDFs and Regular Expressions
(attachment-filename == "\\.vss$")) OR (attachment-filename == "\\.vst$")) OR
(attachment-filename == "\\.vsw$")) OR (attachment-filename == "\\.ws$")) OR
(attachment-filename == "\\.wsc$")) OR (attachment-filename == "\\.wsf$")) OR
(attachment-filename == "\\.wsh$"))) { bounce(); }
In this instance, AsyncOS will have to start the regular expression engine 30 times, once for each attachment
type and the recv-listener.
Instead, write the filter to look like this:
attachment-filter: if (recv-listener == "Inbound") AND (attachment-filename == "\\.
(386|exe|ad|ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|exe|hlp|hta|inf|ins|isp|js|jse|l
nk|mdb|mde|msc|msi|msp|mst|pcd|pif|reg|scr|sct|shb|shs|
url|vb|vbe|vbs|vss|vst|vsw|ws|wsc|wsf|wsh)$") {
The regular expression engine only has to start twice and the filter is arguably easier to maintain as you do
not have to worry about adding “()”, spelling errors. In contrast to the above, this should show a decrease in
CPU overhead.
PDFs and Regular Expressions
Depending on how a PDF is generated, it may contain no spaces or line breaks. When this occurs, the scanning
engine attempts to insert logical spaces and line breaks based on the location of the words on the page. For
example, when a word is constructed using multiple fonts or font sizes, the PDF code is rendered in a way
that makes it difficult for the scanning engine to determine word and line breaks. When you attempt to match
a regular expression against a PDF file constructed in this way, the scanning engine may return unexpected
results.
For example, you enter a word in a PowerPoint document that uses different fonts and different font sizes for
each letter in the word. When a scanning engine reads a PDF generated from this application, it inserts logical
spaces and line breaks. Because of the construction of the PDF, it may interpret the word “callout” as “call
out” or “c a l lout.” Attempting to match either of these renderings against the regular expression, “callout,”
would result in no matches.
Smart Identifiers
When you use message rules that scan message content, you can use smart identifiers to detect certain patterns
in the data.
Smart identifiers can detect the following patterns in data:
• Credit card numbers
• U.S. Social Security numbers
• Committee on Uniform Security Identification Procedures (CUSIP) numbers
• American Banking Association (ABA) routing numbers
To use smart identifiers in a filter, enter the following keywords in a filter rule that scans body or attachment
content:
Table 23: Smart Identifiers in Message Filters
Key Word Smart Identifier Description
*credit Credit card number Identifies 14-, 15-, and 16- digit credit card numbers.
NOTE: The smart identifier does not identify enRoute cards.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
162
Using Message Filters to Enforce Email Policies
Smart Identifier Syntax
Key Word Smart Identifier Description
*aba ABA routing number Identifies ABA routing numbers.
*ssn Social security number Identifies U.S. social security numbers. The *ssn smart identifier
identifies social security numbers with dashes, periods and spaces.
*cusip CUSIP number Identifies CUSIP numbers.
Related Topics
• Smart Identifier Syntax, on page 163
Smart Identifier Syntax
When you use a smart identifier in a filter rule, enter the smart-identifier keyword in quotes within a filter
rule that scans the body or attachment file, as in the example below:
ID_Credit_Cards:
if(body-contains("*credit")){
notify("[email protected]");
}
.
You can also use smart identifiers in content filters and as a part of content dictionaries.
Note You cannot combine a smart identifier key word with a normal regular expression or another key word. For
example the pattern *credit|*ssn would not be valid.
Note To minimize on false positives using the *SSN smart identifier, it may be helpful to use the *ssn smart identifier
along with other filter criteria. One example filter that can be used is the “only-body-contains” filter condition.
This will only evaluate the expression to be true if the search string is present in all of the message body mime
parts. For example, you could create the following filter:
SSN-nohtml: if only-body-contains(“*ssn”) { duplicate-quarantine(“Policy”);}
Note The email gateway detects a smart identifier, only if the message contains the keyword (‘credit,’ ‘ssn,’ ‘cusip,’
or ‘aba’) added before the smart identifier.
For Example: If a message contains a Social Security number (XXX-XX-XXXX’), the email gateway detects
the Social Security number as a smart identifier only if there is a keyword – ‘ssn’ added before the Social
Security number (‘ssn XXX-XX-XXXX,’ ‘ssn: XXX-XX-XXXX,’ and so on.)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
163
Using Message Filters to Enforce Email Policies
Description and Examples of Message Filter Rules
Description and Examples of Message Filter Rules
The following section describes the various message filter rules in use and their examples.
Related Topics
• True Rule, on page 165
• Valid Rule, on page 165
• Subject Rule, on page 165
• Envelope Recipient Rule, on page 166
• Envelope Recipient in Group Rule, on page 166
• Envelope Sender Rule, on page 167
• Envelope Sender in Group Rule, on page 167
• Sender Group Rule, on page 167
• Body Size Rule, on page 168
• Remote IP Rule, on page 169
• Receiving Listener Rule, on page 169
• Receiving IP Interface Rule, on page 169
• Date Rule, on page 169
• Header Rule, on page 170
• Random Rule, on page 170
• Recipient Count Rule, on page 171
• Address Count Rule, on page 171
• Body Scanning Rule, on page 172
• Body Scanning , on page 172
• Encryption Detection Rule, on page 173
• Attachment Type Rule, on page 173
• Attachment Filename Rule, on page 174
• DNS List Rule, on page 175
• IP Reputation Rule, on page 175
• Dictionary Rules, on page 176
• SPF-Status Rule, on page 177
• SPF-Passed Rule, on page 179
• S/MIME Gateway Message Rule, on page 179
• S/MIME Gateway Verified Rule, on page 180
• Workqueue-count Rule, on page 180
• SMTP Authenticated User Match Rule, on page 180
• Signed Rule, on page 182
• Header Repeats Rule, on page 185
• URL Reputation Rules , on page 186
• URL Category Rule , on page 187
• Corrupt Attachment Rule, on page 188
• Message Language Rule, on page 188
• Macro Detection Rule, on page 189
• Forged Email Detection Rule, on page 190
• Duplicate Boundaries Verification Rule, on page 190
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
164
Using Message Filters to Enforce Email Policies
True Rule
• Malformed MIME Header Detection Rule, on page 191
• Geolocation Rule, on page 191
• Domain Reputation Rule for ETF, on page 191
• Domain Reputation Rule for SDR, on page 192
True Rule
The true rule matches all messages. For example, the following rule changes the IP interface to external for
all messages it tests.
externalFilter:
if (true)
alt-src-host('external');
Valid Rule
The valid rule returns false if the message contains unparsable/invalid MIME parts and true otherwise. For
example, the following rule drops all unparsable messages it tests.
not-valid-mime:
if not valid
drop();
Subject Rule
The subject rule selects those messages where the value of the subject header matches the given regular
expression.
For example, the following filter discards all messages with subjects that start with the phrase Make Money...
not-valid-mime:
if not valid
drop();
You can specify non-ASCII characters to search for in the value of the header.
When working with headers, remember that the current value of the header includes changes made during
processing (such as with filter actions that add, remove, or modify message headings). See Message Header
Rules and Evaluation, on page 143 for more information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
165
Using Message Filters to Enforce Email Policies
Envelope Recipient Rule
The following filter returns true if the headers are empty or if the headers are missing from the message:
EmptySubject_To_filter:
if (header('Subject') != ".") OR
(header('To') != ".") {
drop();
Note This filter returns true for empty Subject and To headers, but it also returns true for missing headers. If the
message does not contain the specified headers, the filter still returns true.
Envelope Recipient Rule
The rcpt-to rule selects those messages where any Envelope Recipient matches the given regular expression.
For example, the following filter drops all messages sent with an email address containing the string “scarface.”
Note The regular expression for the rcpt-to rule is case insensitive .
scarfaceFilter:
if (rcpt-to == 'scarface')
drop();
Note The rcpt-to rule is message-based. If a message has multiple recipients, only one recipient has to match the
rule for the specified action to affect the message to all recipients.
Envelope Recipient in Group Rule
The rcpt-to-group rule selects those messages where any Envelope Recipient is found to be a member of
the LDAP group given. For example, the following filter drops all messages sent with an email address within
the LDAP group “ExpiredAccounts.”
expiredFilter:
if (rcpt-to-group == 'ExpiredAccounts')
drop();
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
166
Using Message Filters to Enforce Email Policies
Envelope Sender Rule
Note The rcpt-to-group rule is message-based. If a message has multiple recipients, only one recipient has to
match the rule for the specified action to affect the message to all recipients.
Envelope Sender Rule
The mail-from rule selects those messages where the Envelope Sender matches the given regular expression.
For example, the following filter immediately delivers any message sent by [email protected] .
Note The regular expression for the mail-from rule is case insensitive . Note that the period character is escaped in
the following example.
kremFilter:
if (mail-from == '^admin@yourdomain\\.com$')
skip-filters();
Envelope Sender in Group Rule
The mail-from-group rule selects those messages where the Envelope Sender is found to be in an LDAP
group given on the right side of the operator (or, in the case of inequality, where the sender’s email address
is not in the given LDAP group). For example, the following filter immediately delivers any message sent by
someone whose email address is in the LDAP group “KnownSenders.”
SenderLDAPGroupFilter:
if (mail-from-group == 'KnownSenders')
skip-filters();
Sender Group Rule
The sendergroup message filter selects a message based on which sender group was matched in a listener's
Host Access Table (HAT). This rule uses '==' (for matching) or '!=' (for not matching) to test for matching a
given regular expression (the right side of the expression). For example, the following message filter rule
evaluates to true if the sender group of the message matches the regular expression Internal, and, if so, sends
the message to an alternate mail host.
senderGroupFilter:
if (sendergroup == "Internal")
alt-mailhost("[172.17.0.1]");
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
167
Using Message Filters to Enforce Email Policies
Body Size Rule
Body Size Rule
Body size refers to the size of the message, including both headers and attachments. The body-size rule
selects those messages where the body size compares as directed to a given number. For example, the following
filter bounces any message where the body size is greater than 5 megabytes.
BigFilter:
if (body-size > 5M)
bounce();
The body-size can be compared in the following ways:
Example Comparison Type
Less than
body-size < 10M
Less than or equal
body-size <= 10M
Greater than
body-size > 10M
Greater than or equal
body-size >= 10M
Equal
body-size == 10M
Not equal
body-size != 10M
As a convenience, the size measurement may be specified with a suffix:
Quantity Description
ten bytes (same as 10)
10b
thirteen kilobytes
13k
five megabytes
5M
40 gigabytes (Note: The email gateway cannot accept messages larger than 100
40G
megabytes.)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
168
Using Message Filters to Enforce Email Policies
Remote IP Rule
Remote IP Rule
The remote-ip rule tests to see if the IP address of the host that sent that message matches a certain pattern.
The IP address can be either Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6). The IP
address pattern is specified using the allowed hosts notation described in “Sender Group Syntax”, except for
the SBO , IPR , dnslist notations and the special keyword ALL .
The allowed hosts notation can only identify sequences and numeric ranges of IP addresses (not hostnames).
For example, the following filter bounces any message not injected from IP addresses of form 10.1.1. x
where X is 50 , 51 , 52 , 53 , 54 , or 55 .
notMineFilter:
if (remote-ip != '10.1.1.50-55')
bounce();
Receiving Listener Rule
The recv-listener rule selects those messages received on the named listener. The listener name must be
the nickname of one of the listeners currently configured on the system. For example, the following filter
immediately delivers any message arriving from the listener named expedite .
expediteFilter:
if (recv-listener == 'expedite')
skip-filters();
Receiving IP Interface Rule
The recv-int rule selects those messages received via the named interface. The interface name must be the
nickname of one of the interfaces currently configured for the system. For example, the following filter bounces
any message arriving from the interface named outside .
outsideFilter:
if (recv-int == 'outside')
bounce();
Date Rule
The date rule checks the current time and date against a time and date you specify. The date rule is compares
against a string containing a timestamp of the format MM/DD/YYYY hh:mm:ss . This is useful to specify
actions to be performed before or after certain times in US format. (Note that there may be an issue if you are
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
169
Using Message Filters to Enforce Email Policies
Header Rule
searching messages with non-US date formats.) the following filter bounces all messages from
[email protected] that are injected after 1:00pm on July 28th, 2003:
TimeOutFilter:
if ((date > '07/28/2003 13:00:00') and (mail-from ==
'campaign1@yourdomain\\.com'))
bounce();
Note Do not confuse the date rule with the $Date message filter action variable.
Header Rule
The header() rule checks the message headers for a specific header, which must be specified quoted in
parentheses (“header name ”). This rule may be compared to a regular expression, much like the subject rule,
or may be used without any comparison, in which case it will be “true” if the header is found in the message,
and “false” if it is not found. For example, the following example checks to see if the header X-Sample is
found, and if its value contains the string “ sample text ”. If a match is made, the message is bounced.
FooHeaderFilter:
if (header('X-Sample') == 'sample text')
bounce();
You can specify non-ASCII characters to search for in the value of the header.
The following example demonstrates the header rule without a comparison. In this case, if the header
X-DeleteMe is found, it is removed from the message.
DeleteMeHeaderFilter:
if header('X-DeleteMe')
strip-header('X-DeleteMe');
When working with headers, remember that the current value of the header includes changes made during
processing (such as with filter actions that add, remove, or modify message headings). See Message Header
Rules and Evaluation, on page 143 for more information.
Random Rule
The random rule generates a random number from zero to N-1, where N is the integer value supplied in
parenthesis after the rule. Like the header() rule, this rule may be used in a comparison, or may be used
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
170
Using Message Filters to Enforce Email Policies
Recipient Count Rule
alone in a “unary” form. The rule evaluates to true in the unary form if the random number generated is
non-zero. For example, both of the following filters are effectively equal, choosing Virtual Gateway address
A half the time, and Virtual Gateway address B the other half of the time:
load_balance_a:
if (random(10) < 5)
{
alt-src-host('interface_a');
}
else
alt-src-host('interface_b');
load_balance_b:
if (random(2))
alt-src-host('interface_a');
else
alt-src-host('interface_b');
Recipient Count Rule
The rcpt-count rule compares the number of recipients of a message against an integer value, in a similar
way to the body-size rule. This can be useful for preventing users from sending email to large numbers of
recipients at once, or for ensuring that such large mailing campaigns go out over a certain Virtual Gateway
address. The following example sends any email with more than 100 recipients over a specific Virtual Gateway
address:
large_list_filter:
if (rcpt-count > 100) {
alt-src-host('mass_mailing_interface');
Address Count Rule
The addr-count() message filter rule takes one or more header strings, counts the number of recipients in
each line and reports the cumulative number of recipients. This filter differs from the rcpt-count filter rule
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
171
Using Message Filters to Enforce Email Policies
Body Scanning Rule
in that it operates on the message body headers instead of the envelope recipients. The following example
shows the filter rule used to replace a long list of recipients with the alias, “undisclosed-recipients”:
large_list_filter:
if (rcpt-count > 100) {
alt-src-host('mass_mailing_interface');
Body Scanning Rule
The body-contains() rule scans the incoming email and all its attachments for a particular pattern defined
by its parameter. This includes delivery-status parts and associated attachments. The body-contains() rule
does not perform multi-line matching. The scanning logic can be modified on the Scan Behavior page or using
the scanconfig command in the CLI to define which MIME types should or should not be scanned. You can
also specify a minimum number of matches that the scanning engine must find in order for the scan to evaluate
to true.
By default, the system scans all attachments except for those with a MIME type of video/* , audio/* ,
image/* . The system scans archive attachments — .zip , .bzip , .compress , .tar , or .gzip
attachments containing multiple files. You can set the number of “nested” archived attachments to scan (for
example, a .zip contained within a .zip ).
For more information, see Configuring Scan Behavior, on page 258.
Body Scanning
When AsyncOS performs body scanning, it scans the body text and attachments for the regular expression.
You can assign a minimum threshold value for the expression, and if the scanning engine encounters the
regular expression the minimum number of times, the expression evaluates to true .
AsyncOS evaluates the different MIME parts of the message, and it scans any MIME part that is textual.
AsyncOS identifies the text parts if the MIME type specifies text in the first part. AsyncOS determines the
encoding based on the encoding specified in the message, and it converts the text to Unicode. It then searches
for the regular expression in Unicode space. If no encoding is specified in the message, AsyncOS uses the
encoding you specify on the Scan Behavior page or using the scanconfig command.
For more information about how AsyncOS evaluates MIME parts when scanning messages, see Message
Bodies vs. Message Attachments, on page 143.
If the MIME part is not textual, AsyncOS extract files from a .zip or .tar archive or decompresses compressed
files. After extracting the data, a scanning engine identifies the encoding for the file and returns the data from
the file in Unicode. AsyncOS then searches for the regular expression in Unicode space.
The following example searches the body text and attachment for the phrase “Company Confidential.” The
example specifies a minimum threshold of two instances, so if the scanning engine finds two or more instances
of the phrase, it bounces any matching messages, and notifies the legal department of the attempt:
ConfidentialFilter:
if (body-contains('Company Confidential',2)) {
notify ('[email protected]');
bounce();
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
172
Using Message Filters to Enforce Email Policies
Encryption Detection Rule
To scan only the body of the message, use only-body-contains :
disclaimer:
if (not only-body-contains('[dD]isclaimer',1) ) {
notify('[email protected]');
Encryption Detection Rule
The encrypted rule examines the contents of a message for encrypted data. It does not attempt to decode the
encrypted data, but merely examines the contents of the message for the existence of encrypted data. This can
be useful for preventing users from sending encrypted email.
Note The encrypted rule can only detect encrypted data in the content of messages. It does not detect encrypted
attachments.
The encrypted rule is similar to the true rule in that it takes no parameters and cannot be compared. This rule
returns true if encrypted data is found and false if no encrypted data is found. Because this function requires
the message to be scanned, it uses the scanning settings you define on the Scan Behavior page or using the
scanconfig command. For more information about configuring these options, see Configuring Scan Behavior,
on page 258.
The following filter checks all email sent through the listener, and if a message contains encrypted data, the
message is blind-carbon-copied to the legal department and then bounced:
prevent_encrypted_data:
if (encrypted) {
bcc ('[email protected]');
bounce();
Attachment Type Rule
The attachment-type rule checks the MIME types of each attachment in a message to see if it matches the
given pattern. The pattern must be of the same form used in the Scan Behavior page or the scanconfig
command, as described in Configuring Scan Behavior, on page 258, and so may have either side of the slash
( / ) replaced by an asterisk as a wildcard. If the message contains an attachment that matches this specified
MIME type, this rule returns “true.”
Because this function requires the message to be scanned, it obeys all of the options described in Configuring
Scan Behavior, on page 258.
See Attachment Scanning, on page 225 for more information on message filter rules you can use to manipulate
attachments to messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
173
Using Message Filters to Enforce Email Policies
Attachment Filename Rule
The following filter checks all email sent through the listener, and if a message contains an attachment with
a MIME type of video/* , the message is bounced:
bounce_video_clips:
if (attachment-type == 'video/*') {
bounce();
Attachment Filename Rule
The attachment-filename rule checks the filenames of each attachment in a message to see if it matches the
given regular expression. This comparison is case-sensitive. The comparison is, however sensitive to whitespace
so if the filename has encoded whitespace at the end, the filter will skip the attachment. If one of the message’s
attachments matches the filename, this rule returns “true.”
Please note the following points:
• Each attachment’s filename is captured from the MIME headers. The filename in the MIME header may
contain trailing spaces.
• If an attachment is an archive, the email gateway will harvest the filenames from inside the archive, and
apply scan configuration rules (see Configuring Scan Behavior, on page 258) accordingly.
• If the attachment is a single compressed file (despite the file extension), it is not considered an
archive and the filename of the compressed file is not harvested. This means that the file is not
processed by the attachment-filename rule. An example of this type of file is an executable file
(.exe) compressed with gzip .
• For attachments consisting of a single compressed file, such as foo.exe.gz, use regular expression
to search for specific file types within compressed files. See Attachment Filenames and Single
Compressed Files within Archive Files, on page 174.
See Attachment Scanning, on page 225 for more information on message filter rules you can use to manipulate
attachments to messages.
The following filter checks all email sent through the listener, and if a message contains an attachment with
a filename *.mp3 , the message is bounced:
block_mp3s:
if (attachment-filename == '(?i)\\.mp3$') {
bounce();
Related Topics
• Attachment Filenames and Single Compressed Files within Archive Files, on page 174
Attachment Filenames and Single Compressed Files within Archive Files
This example shows how to match single compressed files in archives such as those created by gzip :
quarantine_gzipped_exe_or_pif:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
174
Using Message Filters to Enforce Email Policies
DNS List Rule
if (attachment-filename == '(?i)\\.(exe|pif)($|.gz$)') {
quarantine("Policy");
DNS List Rule
The dnslist() rule queries a public DNS List server that uses the DNSBL method (sometimes called “ip4r
lookups”) of querying. The IP address of the incoming connection is reversed (so an IP of 1.2.3.4 becomes
4.3.2.1) and then added as a prefix to the server name in the parenthesis (a period to separate the two is added
if the server name does not start with one). A DNS query is made, and the system is returned with either a
DNS failure response (indicating the connection's IP address was not found in the server's list) or an IP address
(indicating that the address was found). The IP address returned is usually of the form 127.0.0. x where x
can be almost any number from 0 to 255 (IP address ranges are not allowed). Some servers actually return
different numbers based on the reason for the listing, while others return the same result for all matches.
Like the header() rule, dnslist() can be used in either a unary or binary comparison. By itself, it simply
evaluates to true if a response is received and false if no response is received (for example, if the DNS server
is unreachable).
The following filter immediately delivers a message if the sender has been bonded with the Cisco Bonded
Sender information services program:
allowedlist_bondedsender:
if (dnslist('query.bondedsender.org')) {
skip-filters();
Optionally, you can compare the result to a string using the equality ( == ) or inequality ( != ) expressions.
The following filter drops a message that results in a “ 127.0.0.2 ” response from the server. If the response
is anything else, the rule returns “false” and the filter is ignored.
blockedlist:
if (dnslist('dnsbl.example.domain') == '127.0.0.2') {
drop();
IP Reputation Rule
The reputation rule checks the IP Reputation Score against another value. All the comparison operators are
allowed, such as > , == , <=, and so forth. If the message does not have a IP Reputation Score at all (because
one was never checked for it, or because the system failed to get a response from the IP Reputation Service
query server), any comparison against a reputation fails (the number will not be greater than, less than, equal
to, or not equal to any value). You can check for a IP Reputation score of “none” using the no-reputation
rule described below. The following example adjusts the “Subject:” line of a message to be prefixed by “ ***
BadRep *** ” if the reputation score returned from the IP Reputation Service is below a threshold of -7.5..
note_bad_reps:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
175
Using Message Filters to Enforce Email Policies
Dictionary Rules
if (reputation < -7.5) {
strip-header ('Subject');
insert-header ('Subject', '*** BadRep $Reputation *** $Subject');
}
For more information, see the “Sender Reputation Filtering” chapter. See also Bypass Anti-Spam System
Action, on page 219
Values for the IP Reputation rule are -10 through 10, but the value NONE may also be returned. To check
specifically for the value NONE , use the no-reputation rule.
none_rep:
if (no-reputation) {
strip-header ('Subject');
insert-header ('Subject', '*** Reputation = NONE *** $Subject');
Dictionary Rules
The dictionary-match(< dictonary_name >) rule evaluates to true if the message body contains any of
the regular expressions or terms in the content dictionary named “dictonary_name .” If the dictionary does
not exist, the rule evaluates to false . For more information on defining dictionaries (including their case
sensitivity and word boundary settings), see the “Text Resources” chapter.
The following filter blind carbon copies the administrator when the Cisco scans a message that contains any
words within the dictionary named “secret_words.”
copy_codenames:
if (dictionary-match ('secret_words')) {
bcc('[email protected]');
The following example sends the message to the Policy quarantine if the message body contains any words
within the dictionary named “secret_words.” Unlike the only-body-contains condition, the
body-dictionary-match condition does not require that all the content parts individually match the dictionary.
The scores of each content part (taking into account multipart/alternative parts) are added together.
quarantine_data_loss_prevention:
if (body-dictionary-match ('secret_words'))
quarantine('Policy');
In the following filter, a subject that matches a term in the specified dictionary is quarantined:
quarantine_policy_subject:
if (subject-dictionary-match ('gTest'))
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
176
Using Message Filters to Enforce Email Policies
SPF-Status Rule
quarantine('Policy');
This example matches an email address in the “to” header and blind copies an administrator:
headerTest:
if (header-dictionary-match ('competitorsList', 'to'))
bcc('[email protected]');
The attachment-dictionary-match(<dictonary_name>) rule works like the dictionary-match rule above,
except that it looks for matches in the attachment.
The following filter sends the message to the Policy quarantine if the message attachment contains any words
found within the dictionary named “secret_words.”
quarantine_codenames_attachment:
if (attachment-dictionary-match ('secret_words'))
quarantine('Policy');
The header-dictionary-match(<dictonary_name>, <header>) rule works like the dictionary-match rule
above, except that it looks for matches in the header specified in <header >. The header name is case insensitive,
so, for example, “subject” and “Subject” both work.
The following filter sends the message to the Policy quarantine if the message’s “cc” header contains any
words found within the dictionary named “ex_employees.”
quarantine_codenames_attachment:
if (header-dictionary-match ('ex_employees', 'cc'))
quarantine('Policy');
You can use wild cards within the dictionary terms. You do not have to escape the period in email addresses.
SPF-Status Rule
When you receive SPF/SIDF verified mail, you may want to take different actions depending on the results
of the SPF/SIDF verification. The spf-status rule checks against different SPF verification results. For more
information, see Verification Results, on page 629.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
177
Using Message Filters to Enforce Email Policies
SPF-Status Rule
Note If you have configured an SPF verification message filter rule without an SPF identity and if a message
contains different SPF identities with different verdicts, the rule is triggered if one of the verdicts in the
message matches the rule.
You can check against the SPF/SIDF verification results using the following syntax:
if (spf-status == "Pass")
If you want a single condition to check against multiple status verdicts, you can use the following syntax:
if (spf-status == "PermError, TempError")
You can also check the verification results against the HELO, MAIL FROM, and PRA identities using the
following syntax:
if (spf-status("pra") == "Fail")
The following example shows the spf-status filter in use:
skip-spam-check-for-verified-senders:
if (sendergroup == "TRUSTED" and spf-status == "Pass"){
skip-spamcheck();
quarantine-spf-failed-mail:
if (spf-status("pra") == "Fail") {
if (spf-status("mailfrom") == "Fail"){
# completely malicious mail
quarantine("Policy");
} else {
if(spf-status("mailfrom") == "SoftFail") {
# malicious mail, but tempting
quarantine("Policy");
} else {
if(spf-status("pra") == "SoftFail"){
if (spf-status("mailfrom") == "Fail"
or spf-status("mailfrom") == "SoftFail"){
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
178
Using Message Filters to Enforce Email Policies
SPF-Passed Rule
# malicious mail, but tempting
quarantine("Policy");
stamp-mail-with-spf-verification-error:
if (spf-status("pra") == "PermError, TempError"
or spf-status("mailfrom") == "PermError, TempError"
or spf-status("helo") == "PermError, TempError"){
# permanent error - stamp message subject
strip-header("Subject");
insert-header("Subject", "[POTENTIAL PHISHING] $Subject"); }
SPF-Passed Rule
The following example shows an spf-passed rule used to quarantine emails that are not marked as spf-passed:
quarantine-spf-unauthorized-mail:
if (not spf-passed) {
quarantine("Policy");
Note Unlike the spf-status rule, the spf-passed rule reduces the SPF/SIDF verification values to a simple Boolean.
The following verification results are treated as not passed in the spf-passed rule: None, Neutral, Softfail,
TempError, PermError, and Fail. To perform actions on messages based on more granular results, use the
spf-status rule.
S/MIME Gateway Message Rule
The S/MIME Gateway Message rule checks if a message is S/MIME signed, encrypted, or signed and encrypted.
The following message filter checks if the message is an S/MIME message and quarantines it if the verification
or decryption using S/MIME fails.
quarantine_smime_messages:
if (smime-gateway-message and not smime-gateway-verified) {
quarantine("Policy");
}
For more information, see S/MIME Security Services, on page 553.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
179
Using Message Filters to Enforce Email Policies
S/MIME Gateway Verified Rule
S/MIME Gateway Verified Rule
The S/MIME Gateway Message Verified rule checks if a message is successfully verified, decrypted, or
decrypted and verified. The following message filter checks if the message is an S/MIME message and
quarantines it if the verification or decryption using S/MIME fails.
quarantine_smime_messages:
if (smime-gateway-message and not smime-gateway-verified) {
quarantine("Policy");
}
For more information, see S/MIME Security Services, on page 553
Workqueue-count Rule
The workqueue-count rule checks the workqueue-count against a specified value. All the comparison operators
are allowed, such as > , == , <=, and so forth.
The following filter checks the workqueue count, and skips spam check if the queue is greater than the specified
number.
wqfull:
if (workqueue-count > 1000) {
skip-spamcheck();
For more information on SPF/SIDF, see Overview of SPF and SIDF Verification, on page 622.
SMTP Authenticated User Match Rule
If your email gateway uses SMTP authentication to send messages, the smtp-auth-id-matches (<target> [,
<sieve-char>] )rule can check a message’s headers and Envelope Sender against the sender’s SMTP
authenticated user ID to identify outgoing messages with spoofed headers. This filter allows the system to
quarantine or block potentially spoofed messages.
The smtp-auth-id-matches rule compares the SMTP authenticated ID against the following targets:
Target Description
*EnvelopeFrom Compares the address of the Envelope Sender (also known as MAIL FROM) in the
SMTP conversation
*FromAddress Compares the addresses parsed out of the From header. Since multiple addresses are
permitted in the From: header, only one has to match.
*Sender Compares the address specified in the Sender header.
*Any Matches messages that were created during an authenticated SMTP session regardless
of identity.
*None Matches messages that were not created during an authenticated SMTP session. This
is useful when authentication is optional (preferred).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
180
Using Message Filters to Enforce Email Policies
SMTP Authenticated User Match Rule
The filter performs matches loosely. It is not case-sensitive. If the optional sieve-char parameter is supplied,
the last portion of an address that follows the specified character will be ignored for the purposes of comparison.
For example, if the + character is included as a parameter, the filter ignores the portion of the address
[email protected] that follows the + character. If the address was [email protected]
, only the +folder portion is ignored. If the SMTP authenticated user ID string is a simple username and not
a fully-qualified e-mail address, only the username portion of the target will be examined to determine a
match. The domain must be verified in a separate rule.
Also, you can use the $SMTPAuthID variable to insert the STMP authenticated user ID into headers.
The following table shows examples of comparisons between the SMTP authenticated ID and email addresses
and whether they would match using the smtp-auth-id-matches filter rule:
SMTP Auth ID Sieve Char Comparison Address Matches?
someuser [email protected] No
someuser [email protected] Yes
someuser [email protected] Yes
SomeUser [email protected] Yes
someuser [email protected] No
someuser + [email protected] Yes
[email protected] [email protected] No
[email protected] [email protected] Yes
[email protected] [email protected] Yes
The following filter checks all messages created during an authenticated SMTP session to verify that the
addresses in the From header and the Envelope Sender match the SMTP authenticated user ID. If the addresses
and the ID match, the filter verifies the domain. If they do not match, the email gateway quarantines the
message.
Msg_Authentication:
if (smtp-auth-id-matches("*Any"))
# Always include the original authentication credentials in a
# special header.
insert-header("X-Auth-ID","$SMTPAuthID");
if (smtp-auth-id-matches("*FromAddress", "+") and
smtp-auth-id-matches("*EnvelopeFrom", "+"))
# Username matches. Verify the domain
if header('from') != "(?i)@(?:example\\.com|alternate\\.com)" or
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
181
Using Message Filters to Enforce Email Policies
Signed Rule
mail-from != "(?i)@(?:example\\.com|alternate\\.com)"
# User has specified a domain which cannot be authenticated
quarantine("forged");
} else {
# User claims to be an completely different user
quarantine("forged");
Signed Rule
The signed rule checks messages for a signature. The rule returns a boolean value to indicate if the message
is signed or not. This rule evaluates whether the signature is encoded according to ASN.1 DER encoding rules
and that it conforms to the CMS SignedData Type structure (RFC 3852, Section 5.1.). It does not aim to
validate whether the signature matches the content, nor does it check the validity of the certificate.
The following example shows a signed rule used to insert headers into a signed message:
signedcheck: if signed { insert-header("X-Signed", "True"); }
The following example shows a signed rule used to drop attachments from unsigned messages from a certain
sender group:
Signed: if ((sendergroup == "NOTTRUSTED") AND NOT signed) {
html-convert();
if (attachment_size > 0)
drop_attachments("");
Signed Certificate Rule
The signed-certificate rule selects those S/MIME messages where the X.509 certificate issuer or message
signer matches the given regular expression. This rule only supports X.509 certificates.
The rule’s syntax is signed-certificate (<field> [<operator> <regular expression>]) , where:
• <field> is either the quoted string “issuer” or “signer” ,
• <operator> is either == or != ,
• and <regular expression> is the value for matching the “issuer” or “signer.”
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
182
Using Message Filters to Enforce Email Policies
Signer
If the message is signed using multiple signatures, the rule returns true if any of the issuers or signers match
the regular expression. The short form of this rule, signed-certificate(“issuer”) and signed-certificate(“signer”)
, returns true if the S/MIME message contains an issuer or signer.
Related Topics
• Signer, on page 183
• Issuer, on page 183
• Escaping in Regular Expressions, on page 183
• $CertificateSigners Action Variable, on page 183
• Examples 1, on page 184
Signer
For message signers, the rule extracts the sequence of rfc822Name names from the X.509 certificate’s
subjectAltName extension. If there is no subjectAltName field in the signing certificate, or this field does not
have any rfc822Name names, the signed-certificate(“signer”) rule evaluates to false. In the rare cases of
multiple rfc822Name names, the rule tries to match all of the names to the regular expression and evaluates
as true on the first match.
Issuer
The issuer is a non-empty distinguished name in the X.509 certificate. AsyncOS extracts the issuer from the
certificate and converts it to an LDAP-UTF8 Unicode string. For example:
• C=US,S=CA,O=IronPort
• C=US,CN=Bob Smith
Since X.509 certificates require the issuer field, signed-certificate(“issuer”) evaluates whether the S/MIME
message contains an X.509 certificate.
Escaping in Regular Expressions
LDAP-UTF8 defines a mechanism for escaping that you can use in your regular expressions. For a detailed
discussion on escaping characters in LDAP-UTF8, consult Lightweight Directory Access Protocol (LDAP):
String Representation of Distinguished Names, accessible from http://www.ietf.org/rfc/rfc4514.txt .
The escaping rules for the signed-certificate rule’s regular expressions differ from the escaping rules defined
in LDAP-UTF8 by limiting escaping to only the characters that require escaping. LDAP-UTF8 allows optional
escaping for characters that can be represented without escaping. For example, the following two strings are
considered correct for “Example, Inc.” using the LDAP-UTF8 escaping rules:
• Example\, Inc.
• Example\,\ Inc\.
However, the signed-certificate rule only matches Example\, Inc. The regular expression does not allow
escaping the space and period for matching because these characters do not require escaping, even though it
is permitted in LDAP-UTF8. When creating a regular expression for the signed-certificate rule, do not escape
a character if it can be represented without escaping.
$CertificateSigners Action Variable
The action variable $CertificateSigners is a comma separated list of signers obtained from the
subjectAltName element of the signing certificate. Multiple email addresses of a single signer will be included
in the list with duplicates removed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
183
Using Message Filters to Enforce Email Policies
Examples 1
For example, Alice signs a message with her two certificates. Bob signs the message with his single certificate.
All certificates are issued by a single corporate authority. After the message passes the S/MIME scan, the
extracted data contain three items:
[
'issuer': 'CN=Auth,O=Example\, Inc.',
'signer': ['[email protected]', '[email protected]']
},
'issuer': 'CN=Auth,O=Example\, Inc.',
'signer': ['[email protected]', '[email protected]']
},
'issuer': 'CN=Auth,O=Example\, Inc.',
'signer': ['[email protected]', '[email protected]']
The $CertificateSigners variable expands to:
"[email protected], [email protected], [email protected], [email protected]"
Examples 1
The following example inserts a new header if the certificate issuer is from the US:
Issuer: if signed-certificate("issuer") == "(?i)C=US" {
insert-header("X-Test", "US issuer");
The following example notifies an administrator if the signer is not from example.com:
NotOurSigners: if signed-certificate("signer") AND
signed-certificate("signer") != "example\\.com$" {
notify("[email protected]");
The following example adds a header if the message has an X.509 certificate:
AnyX509: if signed-certificate ("issuer") {
insert-header("X-Test", "X.509 present");
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
184
Using Message Filters to Enforce Email Policies
Header Repeats Rule
The following example adds a header if the message’s certificate does not have a signer:
NoSigner: if not signed-certificate ("signer") {
insert-header("X-Test", "Old X.509?");
Header Repeats Rule
The Header Repeats rule evaluates to true if at a given point in time, a specified number of messages:
• With same subject are detected in the last one hour.
• From same envelope sender are detected in the last one hour.
You can use this rule to detect high volume emails. For example, political campaigns through certain websites
may send out emails to organizations in high volumes. Anti-spam engines treat such emails as clean, and do
not stop the delivery of these emails.
The syntax of this rule is header-repeats (<target>, <threshold> [, <direction>]) , where:
• <target> is subject or mail-from . AsyncOS counts the repetition of values of the target.
• <threshold> is the number of messages with identical values for a given target, received in the last one
hour, beyond which the rule evaluates to true.
• <direction> is incoming , outgoing , or both. If direction is not specified in this rule, incoming or outgoing
messages are counted for rule evaluation.
Every time when a Header Repeats rule evaluates to true , a System Alert is sent. SeeSystem Alerts, on page
1051.
Note If the header field includes comma or semi-colon separated values, the rule considers the complete string for
tracking. This rule ignores messages with empty subject header.
The Header Repeats rule maintains a moving sum of messages with up to one minute’s precision. As a result,
after the set threshold has reached, there can be a delay of one minute before this rule is triggered.
Related Topics
• Using Header Repeats Rule with Other Rules, on page 185
• Examples, on page 186
Using Header Repeats Rule with Other Rules
You can use the Header Repeats rule with other rules using AND or OR operators. For example, you can
categorize an allowed list for a subset of messages using the following filter:
F1: if (recv_listener == 'Gray') AND (header-repeats('subject', X, 'incoming') { drop();}
When you use a Header Repeats rule with another rule using AND or OR operators, the Header Repeats rule
is evaluated last, and only if needed. If a Header Repeats rule is not evaluated for a given message, subject
or mail-from is not counted to compare with the supplied threshold.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
185
Using Message Filters to Enforce Email Policies
Examples
As Header Repeats rule is evaluated last and only if needed, the behavior of this rule may vary when used
with other rules using an OR operator. The following sample filter uses an OR condition of Signed and Header
Repeats rule.
f1: if signed OR (header-repeats('subject', 10)) { drop();}
In this example, if the first nine messages processed by this filter are signed messages with identical subject,
the Header Repeats rule will not process these messages. If the tenth message is an unsigned message with
identical subject header as the previous nine messages, the filter will not perform the configured action, even
though the threshold has reached.
Examples
In the following example, at any given point in time, if the filter detects X or more incoming messages with
identical subject in the last one hour, the subsequent messages with identical subject are sent to Policy
quarantine.
f1 : if header-repeats('subject', X, 'incoming') { quarantine('Policy');}
In the following example, at any given point in time, if the filter detects X or more outgoing messages from
same envelope sender in the last one hour, the subsequent messages from the same envelope sender are dropped
and discarded.
f2 : if header-repeats('mail-from', X, 'outgoing') {drop();}
In the following example, at any given point in time, if the filter detects X or more incoming or outgoing
messages with identical subject in the last one hour, the administrator is notified for every subsequent message
with identical subject.
f3: if header-repeats('subject', X) {notify('[email protected]');}
URL Reputation Rules
Use a URL reputation rule to define message actions based on the reputation score of any URL in the message.
For important details, see Filtering by URL Reputation or URL Category: Conditions and Rules , on page
457 in Protecting Against Malicious or Undesirable URLs, on page 449
For these rules:
• msg_filter_name : is the name of this message filter.
• allowedlist is the name of a defined URL list (via the urllistconfig command.) Specifying an allowed
list is optional.
To take action when the reputation service provides a score:
Use the url-reputation rule.
Filter syntax when using a url-reputation rule is:
<msg_filter_name>:
if url-reputation('<min_score'>, <'max_score'>, '<allowedlist>',
'<include_attachments>','<include_message_body_subject>')
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
186
Using Message Filters to Enforce Email Policies
URL Category Rule
{<action>}
Where:
• min_score and max_score are the minimum and maximum scores in the range for which the action should
apply. The values that you specify are included in the range.
Minimum and maximum scores must be between -10.0 and 10.0 .
• include_attachments to scan for URLs in the message attachments. A value of '1' indicates that URL
scanning for message attachments is enabled and a value of '0' indicates that URL scanning for message
attachments is not enabled.
• include_message_body_subject to scan for URLs in the message body and subject. A value of '1'
indicates that URL scanning for message body and subject is enabled and a value of '0' indicates that
URL scanning for message body and subject is not enabled.
To take action when the reputation service does not provide a score:
Use the url-no-reputation rule.
Filter syntax when using a url-no-reputation rule is:
<msg_filter_name>:
if url_no_reputation('<allowedlist>',
'<include_attachments>','<include_message_body_subject>')
{<action>}
URL Category Rule
Use URL categories to define message actions based on the category of URLs in the message. For important
details, see Filtering by URL Reputation or URL Category: Conditions and Rules , on page 457 in Protecting
Against Malicious or Undesirable URLs, on page 449.
Filter syntax when using a url-category rule is:
<msg_filter_name>: if url-category ([‘<category-name1>’,’<category-name2>’,...,
‘<category-name3>’],’<url_allowed_list>’,'<include_attachments>','<include_message_body_subject>')
<action>
Where:
• msg_filter_name is the name of this message filter.
• action is any message filter action.
• category-name is the URL category. Separate multiple categories with commas. To obtain correct
category names, look at a URL Category condition or action in a Content Filter. For descriptions and
examples of the categories, see About URL Categories, on page 467.
• url_allowed_list is the name of a defined URL list (via the urllistconfig command.)
• include_attachments to scan for URLs in message attachments. A value of '1' indicates that URL
scanning for message attachments is enabled and a value of '0' indicates that URL scanning for message
attachments is not enabled.
• include_message_body_subject to scan for URLs in the message body and subject. A value of '1'
indicates that URL scanning for the message body and subject is enabled and a value of '0' indicates that
URL scanning for the message body and subjects is not enabled.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
187
Using Message Filters to Enforce Email Policies
Corrupt Attachment Rule
Corrupt Attachment Rule
The Corrupt Attachment rule evaluates to true if a message contains corrupt attachment. A corrupt attachment
is an attachment that the scanning engine cannot scan and identified as corrupt.
Related Topics
• Example, on page 188
Example
In the following example, if the filter detects a corrupt attachment in a message, the message is quarantined
to Policy Quarantine.
quar_corrupt_attach: if (attachment-corrupt) { quarantine("Policy"); }
Message Language Rule
You may want to take different message actions based on the message language. For example, you may want
to:
• Add a disclaimer in Russian to the messages that are in Russian
• Drop the messages whose language could not be determined
Use the message-language rule to take message actions depending on the language of the message subject
and body.
Note This rule will not check for the language in attachments and headers.
How Does Language Detection Work
The email gateway uses the built-in language detection engine to detect the language in a message. The email
gateway extracts the subject and the message body and passes it to the language detection engine.
The language detection engine determines the probability of each language in the extracted text and passes it
back to the email gateway. The email gateway considers the language with the highest probability as the
language of the message. The email gateway considers the language of the message as ‘undetermined’ in one
of the following scenarios:
• If the detected language is not supported by the email gateway
• If the email gateway is unable to detect the language of the message
• If the total size of the extracted text sent to the language detection engine is less than 50 bytes.
Message Filter Syntax
<msg_filter_name>: if (message-language <operator> "<language1>, <language2>,..., <language
n>") {<action>}
Where:
• msg_filter_name is the name of this message filter.
• operator is == or != .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
188
Using Message Filters to Enforce Email Policies
Examples
• language is the value of message language that you want to specify in this message filter. Separate
multiple entries with commas. For a list of supported message languages and values, look at the Message
Language condition in a content filter. Values are enclosed with brackets ([ and ]).
• action is any message filter action.
Examples
The following example shows how to drop the messages whose language could not be determined:
DropMessagesWithUndeterminedLanguage: if (message-language == "unknown") { drop(); }
The following example shows how to add a disclaimer in Russian to the messages in Russian:
ussianDisclaimerRule: if (message-language == "ru") { add-heading("RussianDisclaimer");
Macro Detection Rule
You can use the Macro Detection rule to detect macro-enabled attachments in messages for the specified file
types.
Note If an archive or embedded file contains macros, the parent file is dropped from the message.
Macro Detection Syntax
<msg_filter_name>: if (macro-detection-rule (['file_type-1', 'file_type-2',...
,’file_type-n'])) {<action>}
Where:
• msg_filter_name is the name of this message filter.
• file_type can be any one of the following supported file types:
• Adobe Portable Document Format
• Microsoft Office Files
• OLE File types
• action is any message filter action.
Examples
The following example shows how to drop a message that contains a macro-enabled Microsoft Office
attachment:
Drop_Messages_With_Macro-enabled_Office_Files: if (macro-detection-rule (['Microsoft Office
Files'])) { drop(); }
In the following example, if a message containing a macro-enabled attachment in a PDF format is sent to a
specific user, the message is dropped:
Strip_Macro_enabled_PDF: if (rcpt-to == "[email protected]") {
drop-macro-enabled-attachments(['Adobe Portable Document Format']); }
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
189
Using Message Filters to Enforce Email Policies
Forged Email Detection Rule
Forged Email Detection Rule
You may want to detect fraudulent messages with forged sender address (From: header) and perform actions
on such messages.
Use the forged-email-detection rule to detect such messages. While configuring this rule, you must specify a
content dictionary and the threshold value (1 through 100) for considering a message as potentially forged.
The forged-email-detection rule compares the From: header with the users in the content dictionary. During
this process, depending on the similarity, the email gateway assigns similarity score to each of the users in
the dictionary. The following are some examples:
• If the From: header is <[email protected]> and the content dictionary contains a user ‘John
Simons,’ the email gateway assigns a similarity score of 82 to the user.
• If the From: header is <[email protected]> and the content dictionary contains a user ‘John
Simons,’ the email gateway assigns a similarity score of 100 to the user.
The higher the similarity score, the higher the probability that the message is forged. If the similarity score is
greater than or equal to the specified threshold value, the filter action is triggered.
For more information, see Forged Email Detection, on page 640.
Message Filter Syntax
<filter_name>: if (forged-email-detection(“<content_dictionary>”, threshold)) {<action>;}
Where:
• filter_name is the name of the message filter
• content_dictionary is the name of content dictionary
• threshold is the threshold value (1 through 100) for considering a message as potentially forged
Example
The following message filter compares the From: header in the message with the terms in dictionary and if
the similarity score of a user in the content dictionary is greater than or equal to 70, the message filter strips
the From: header and replaces it with the Envelope Sender.
FED_CF: if (forged-email-detection("Execs", 70)) { fed("from", ""); }
Duplicate Boundaries Verification Rule
You can use the duplicate_boundaries rule to detect messages that contain duplicate MIME boundaries.
Note Attachment-based rules (for example, attachment-contains ) or actions (for example,
drop-attachments-where-contains ) will not work on malformed messages (with duplicate MIME boundaries).
Message Filter Syntax
<filter_name>: if (duplicate_boundaries){<action>;}
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
190
Using Message Filters to Enforce Email Policies
Malformed MIME Header Detection Rule
Example
The following message filter will quarantine all the messages that contain duplicate MIME boundaries.
DuplicateBoundaries: if (duplicate_boundaries) { quarantine("Policy"); }
Malformed MIME Header Detection Rule
You can use the malformed-header rule to detect messages that contain malformed MIME headers.
Message Filter Syntax
<filter_name>: if (malformed-header){<action>;}
Example
The following example shows how to quarantine all the messages with malformed MIME headers:
quarantine_malformed_headers: if (malformed-header)
{
quarantine("Policy");
}
Geolocation Rule
You can use the Geolocation rule to handle incoming messages from particular countries that you select.
Geolocation Syntax
<msg_filter_name>: if (geolocation-rule (['country_name-1', 'country_name-2',...
,’country_name-n'])) {<action>}
Where:
• msg_filter_name is the name of this message filter.
• country_name can be name of any country that you select.
• action is any message filter action.
Example
The following example shows how to quarantine an incoming message from Country1 and Country2:
Quarantine_Incoming_Messages_from_Country1_and_Country2: if (geolocation-rule
(['Country1', 'Country2'])) {quarantine("Policy");}
Domain Reputation Rule for ETF
As an example, use the following message filter rule syntax to detect malicious domains in messages using
the ETF engine, and take appropriate actions on such messages.
Syntax:
quarantine_msg_based_on_ETF: if (domain-external-threat-feeds (['etf_source1'],
['mail-from', 'from'], <'domain_exception_list'>)) { quarantine("Policy"); }
Where
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
191
Using Message Filters to Enforce Email Policies
Domain Reputation Rule for SDR
• ‘domain-external-threat-feeds' is the Domain reputation message filter rule.
• ‘etf_source1' is the ETF source(s) used to detect malicious domain(s) in the header(s) of a message.
• ‘mail-from','from' are the required header(s) used to check for the reputation of the domain.
• 'domain_exception_list' is the name of a domain exception list. If a domain exception list is not
present it is displayed as "".
Example
In the following example, if the domain in the ‘Errors To:’ custom header is detected as malicious by the ETF
engine, the message is quarantined.
Quaranting_Messages_with_Malicious_Domains: if domain-external-threat-feeds
(['threat_feed_source'], ['Errors-To'], "")) {quarantine("Policy");}
Domain Reputation Rule for SDR
You can use the Domain Reputation rule to filter messages based on SDR, and take appropriate actions on
such messages:
• Sender Domain Verdict
• Sender Domain Age
• Sender Domain Unscannable
Filtering Messages based on Sender Domain Verdict
Note The recommended blocking threshold is "Poor." For more information about SDR, contact Cisco Talos at
https://www.talosintelligence.com.
Syntax:
drop_msg_based_on_sdr_verdict:
if sdr-reputation (['awful', 'poor'], "<domain_exception_list>")
{drop();}
Where:
• 'drop_msg_based_on_sdr_verdict' is the name of the message filter.
• 'sdr-reputation'is the Domain Reputation message filter rule.
• 'awful','poor' is the range of the sender domain verdict used to filter messages based on SDR.
• 'domain_exception_list' is the name of a domain exception list. If a domain exception list is not
present it is displayed as "".
• 'drop' is the action applied on the message.
Example
In the following message, if the SDR verdict is 'Unknownr', the message is quarantined.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
192
Using Message Filters to Enforce Email Policies
Filtering Messages based on Sender Domain Age
quarantine_unknown_sdr_verdicts:
if sdr-reputation (['unknown'], "")
{quarantine("Policy")}
Filtering Messages based on Sender Domain Age
Note The Sender Domain Age option will be removed in the next AsyncOS release.
Syntax:
<msg_filter_name>
if sdr-age (<‘unit'>, <‘operator'> <‘actual value’>)
{<action>}
Where:
• ‘sdr-reputation' is the Domain Reputation message filter rule.
• ‘sdr_age’ is the age of the sender domain used to filter messages based on SDR.
• ‘unit' is the number of ‘days,’ ‘years,’ ‘months,’ or 'weeks' option used to filter messages based on the
sender domain age.
• ‘operator' are the following comparison operators used to filter messages based on the sender domain
age:
• – > (Greater than)
• – >= (Greater than or equal to)
• – < (Lesser than)
• – <= (Lesser than or equal to)
• – == (Equal to)
• – != (Not equal to)
• – Unknown
• ‘actual value' is the number used to filter messages based on the sender domain age.
Examples
In the following message, if the age of the sender domain is unknown, the message is dropped.
Drop_Messages_Based_On_SDR_Age: if (sdr-age ("unknown", "")) {drop();}
In the following message, if the age of the sender domain is less than one month, the message is dropped.
Drop_Messages_Based_On_SDR_Age: if (sdr-age ("months", <, 1, "")) { drop(); }
Filtering Messages based on Sender Domain Unscannable
Syntax:
<msg_filter_name>
if sdr-unscannable (<'domain_exception_list'>)
{<action>}
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
193
Using Message Filters to Enforce Email Policies
Message Filter Actions
Where:
• 'sdr-unscannable' is the Domain Reputation message filter rule.
'domain_exception_list' is the name of a domain exception list. If a domain exception list is not
present it is displayed as "".
Example
In the following message, if the message failed the SDR check, the message is quarantined.
Quarantine_Messages_Based_On_Sender_Domain_Unscannable: if (sdr-unscannable (""))
{quarantine("Policy");}
Message Filter Actions
The purpose of message filters is to perform actions on selected messages.
The two types of actions are:
• Final actions — such as deliver , drop , and bounce — end the processing of a message, and permit no
further processing through subsequent filters.
• Non-final actions perform an action which permits the message to be processed further.
Note Non-final message filter actions are cumulative. If a message matches multiple filters where each filter specifies
a different action, then all actions are accumulated and enforced. However, if a message matches multiple
filters specifying the same action, the prior actions are overridden and the final filter action is enforced.
Related Topics
• Filter Actions Summary Table, on page 194
• Action Variables, on page 203
• Matched Content Visibility, on page 205
• Description and Examples of Message Filter Actions, on page 206
Filter Actions Summary Table
Message filters can apply the following actions to an email message as shown in the following table:
Table 24: Message Filter Actions
Action Syntax Description
Alter source host alt-src-host Change the source hostname and IP interface
(Virtual Gateway address) to send the
message. See Alter Source Host (Virtual
Gateway address) Action, on page 215.
Alter recipient alt-rcpt-to Change a recipient of the message. See Alter
Recipient Action, on page 214.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
194
Using Message Filters to Enforce Email Policies
Filter Actions Summary Table
Action Syntax Description
Alter mailhost alt-mailhost Change the destination mail host for the
message. See Alter Delivery Host Action,
on page 214.
Notify notify Report this message to another recipient.
See Notify and Notify-Copy Actions, on
page 209.
Notify Copy notify-copy Perform just like the notify action, but also
sends a copy as with the bcc-scan action.
See Notify and Notify-Copy Actions, on
page 209.
Blind carbon copy bcc Copy this message (message replication)
anonymously to another recipient. See Blind
Carbon Copy Actions, on page 211.
Blind carbon copy bcc-scan Copy this message anonymously to another
with scan recipient, and process that message through
the work queue as if it were a new message.
See Blind Carbon Copy Actions, on page
211.
Archive archive Archive this message into an mbox-format
file. See Archive Action, on page 215.
Quarantine quarantine Flag this message to be sent to the
(quarantine_name
quarantine named quarantine_name . See
Quarantine and Duplicate Actions, on page
213.
Duplicate duplicate-quarantine Send a copy of the message to the specified
(quarantine_name
(Quarantine) quarantine. See Quarantine and Duplicate
Actions, on page 213.
Remove headers strip-header Remove specified headers from the message
before delivering. See Strip Header Action,
on page 216.
Insert headers insert-header Insert a header and value pair into the
message before delivering. See Insert
Header Action , on page 216.
Edit header text edit-header-text Replace specified header text with a text
string you specify in the filter condition. See
Edit Header Text Action, on page 217.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
195
Using Message Filters to Enforce Email Policies
Filter Actions Summary Table
Action Syntax Description
Edit body text edit-body-text() Strip a regular expression from a message
body and replaces it with text that you
specify. You might want to use this filter if
you want to remove and replace specific
content, such as a URL within a message
body. See Edit Body Text Action, on page
217.
Convert HTML html-convert() Strip HTML tags from message bodies and
leaves the plain text content of the message.
You might want to use this filter if you want
to convert all HTML text in a message to
plain text. HTML Convert Action, on page
218.
Assign bounce bounce-profile Assign a specific bounce profile to the
profile message. See Bounce Profile Action, on
page 219.
Bypass Anti-Spam skip-spamcheck Ensure that the anti-spam systems in the
System Cisco system are not applied to this
message. See Bypass Anti-Spam System
Action, on page 219.
Bypass Graymail skip-marketingcheck Bypass actions on marketing emails. See
Actions Bypassing Graymail Actions, on page 220.
skip-socialcheck Bypass actions on social network emails.
See Bypassing Graymail Actions, on page
220.
skip-bulkcheck Bypass actions on bulk emails. See
Bypassing Graymail Actions, on page 220.
Bypass Anti-Virus skip-viruscheck Ensure that the anti-virus systems in the
System Cisco system are not applied to this
message. See Bypass Anti-Virus System
Action, on page 220.
Bypass File skip-ampcheck Ensure that File Reputation Filtering and
Reputation Filtering File Analysis are not applied to this
and File Analysis message. See Bypass File Reputation
Filtering and File Analysis System Actions,
on page 221.
Skip Outbreak Filter skip-vofcheck Ensure that this message is not processed
Scanning by the Outbreak Filters scanning. See
Bypass Anti-Virus System Action, on page
220.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
196
Using Message Filters to Enforce Email Policies
Filter Actions Summary Table
Action Syntax Description
Drop Attachments drop-attachments-by-name Drop all attachments on messages that have
by Name a filename that match the given regular
expression. Archive file attachments (zip,
tar), Microsoft Office attachments (doc,
docx), and Email attachments (winmail.dat)
will be dropped if they contain a file that
matches. See Examples of Attachment
Scanning Message Filters, on page 232.
Drop Attachments drop-attachments-by-type Drop all attachments on messages that have
by Type a MIME type, determined by either the
given MIME type or the file extension.
Archive file attachments (zip, tar) will be
dropped if they contain a file that matches.
See Examples of Attachment Scanning
Message Filters, on page 232.
Drop Attachments drop-attachments-by-filetype Drop all attachments on messages that match
by File Type the given “fingerprint” of the file. Archive
file attachments (zip, tar) will be dropped if
they contain a file that matches. For more
information, see Examples of Attachment
Scanning Message Filters, on page 232.
Drop Attachments drop-attachments-by-mimetype Drop all attachments on messages that have
by MIME Type a given MIME type. This action does not
attempt to ascertain the MIME type by file
extension and so it also does not examine
the contents of archives. See Examples of
Attachment Scanning Message Filters, on
page 232.
Drop Attachments drop-attachments-by-hash Drop all message attachments in messages
based on File Hash that match the specific file SHA-256 value
List in the file hash list. See Drop Message
Attachments that match File SHA-256 Filter,
on page 258 and Drop Messages if
Attachment matches File SHA-256 Filter,
on page 258.
Drop Attachments Drop all attachments on the message that,
drop-attachments-by-size
by Size in raw encoded form, are equal to or greater
than the size (in bytes) given. Note that for
archive or compressed files, this action does
not examine the uncompressed size, but
rather the size of the actual attachment prior
to any decoding. See Examples of
Attachment Scanning Message Filters, on
page 232.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
197
Using Message Filters to Enforce Email Policies
Filter Actions Summary Table
Action Syntax Description
Drop Attachments drop-attachments-where-contains Drop all attachments on message that
by Content contain the regular expression. Does the
pattern occur the minimum number of times
you specified for the threshold value?
Archive files (zip, tar) will be dropped if
any of the files they contain match the
regular expression pattern. See Examples of
Attachment Scanning Message Filters, on
page 232.
The optional comment serves as the means
to modify the text used to replace the
attachment that was dropped. Attachment
footers simply append to the message.
Drop Attachments drop-macro-enabled-attachments Drops all macro-enabled attachments of the
with Macro specified file type.
Note If an archive or embedded file
contains macros, the parent file
is dropped from the message.
Syntax
drop-macro-enabled-attachments
([‘file_type-1', 'file_type-2',
…,'file_type-n'],
“custom_replacement_message”)
Where:
• file_type can be any one of the
following supported file types:
• Adobe Portable Document
Format
• Microsoft Office Files
• OLE File types
• custom replacement message is
an optional message to replace the
default system generated message
added to the bottom of the message
body when an attachment is dropped.
See Macro Detection Rule, on page 189
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
198
Using Message Filters to Enforce Email Policies
Filter Actions Summary Table
Action Syntax Description
Drop Attachments drop-attachments-where-dictionary-match Strip attachments based on matches to
by Dictionary dictionary terms. If the terms in the MIME
Matches parts considered to be an attachment match
a dictionary term (and the user-defined
threshold is met), the attachment is stripped
from the email. See Examples of Attachment
Scanning Message Filters, on page 232.
Add Footer add-footer(footer-name) Add disclaimer text as a footer to the
message. See “Message Disclaimer
Stamping” in the “Text Resources” chapter
for more information.
Add Heading add-heading(heading-name) Add disclaimer text as a heading to the
message. See “Message Disclaimer
Stamping” in the “Text Resources” chapter
for more information.
Encrypt on Delivery encrypt-deferred Encrypt message on delivery, which means
that the message continues to the next stage
of processing, and when all processing is
complete, the message is encrypted and
delivered.
S/MIME smime-gateway-deferred Performs an S/MIME signing or encryption
(“sending_profile”)
Sign/Encrypt on of the message using the specified sending
Delivery profile during the delivery. See S/MIME
Sign or Encrypt on Delivery Action, on page
208.
S/MIME smime-gateway(“sending_profile”) Performs an S/MIME signing or encryption
Sign/Encrypt using the specified sending profile and
delivers the message, skipping any further
processing. See S/MIME Sign or Encrypt
Action, on page 208.
Add Message Tag tag-message(tag-name) Add a custom term into the message to use
with DLP policy filtering. You can configure
a DLP policy to limit scanning to messages
with the message tag. The message tag is
not visible to recipients. See Add Message
Tag Action, on page 221 and the “Data Loss
Prevention” chapter.
Add Log Entry log-entry Adds customized text into the Text Mail
logs at the INFO level. The text can include
action variables. The log entry appears in
message tracking. See Add Log Entry
Action, on page 222.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
199
Using Message Filters to Enforce Email Policies
Filter Actions Summary Table
Action Syntax Description
Replace URL with • url-reputation-replace Modify URLs or their behavior based on the
text, based on URL • url-no-reputation-replace reputation of the URL.
reputation
Use a separate action to handle the case in
Defang URL based • url-reputation-defang which the reputation service does not
on URL reputation provide a score for a URL.
• url-no-reputation-defang
See URL Reputation Actions , on page 222.
Redirect URL to a • url-reputation-proxy-redirect
Cisco security proxy, • url-no-reputation-proxy-redirect
based on URL
reputation
Replace URL with url-category-replace Modify URLs or their behavior based on the
text, based on URL category of the URL.
Category
See URL Category Actions , on page 224.
Defang URL based url-category-defang
on URL category
Redirect URL to url-category-proxy-redirect
Cisco security proxy,
based on URL
category
Forged Email fed Strips the From: header from the forged
Detection message and replaces it with the Envelope
Sender. See Forged Email Detection Action,
on page 225.
No Operation no-op No action is performed. See No Operation,
on page 225.
*Skip Remaining skip-filters Ensure that this message is not processed
Message Filters by any other message filters and continues
through the email pipeline. See Skip
Remaining Message Filters Action, on page
207.
*Drop message drop Drop and discard the message. See Drop
Action, on page 207.
*Bounce message bounce Send the message back to the sender. See
Bounce Action, on page 208.
*Encrypt and encrypt Use Cisco Email Encryption to encrypt
Deliver Now outgoing messages. See Encrypt Action, on
page 208.
* Final Actions
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
200
Using Message Filters to Enforce Email Policies
Attachment Groups
Related Topics
• Attachment Groups, on page 201
Attachment Groups
You can specify a particular file type (“exe” files for example) or common groups of attachments in the
attachment-filetype and drop-attachments-by-filetype rules . AsyncOS divides the attachments into
the groups listed in the following table.
If you create a message filter that uses the != operator to match a message that does not contain an attachment
with a specific file type, the filter will not perform any action on the message if there is at least one attachment
with the file type you want to filter out. For example, the following filter drops any message with an attachment
that is not an .exe file type:
exe_check: if (attachment-filetype != "exe") {
drop();
If a message has multiple attachments, the email gateway does not drop the message if at least one of the
attachments is an .exe file, even if the other attachments not .exe files.
Table 25: Attachment Groups
Attachment Group Name Scanned File Types
Document • doc
• docx
• mdb
• mpp
• ole
• pdf
• ppt
• pptx
• rtf
• wps
• x-wmf
• xls
• xlsx
Executable • exe
• java
• msi
• pif
Note Filtering the Executable group will also scan .dll and .scr files, but
you cannot filter these file types individually.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
201
Using Message Filters to Enforce Email Policies
Attachment Groups
Attachment Group Name Scanned File Types
Compressed • ace (ACE Archiver compressed file)
• arc (SQUASH Compressed archive)
• arj (Robert Jung ARJ compressed archive)
• binhex
• bz (Bzip compressed file)
• bz2 (Bzip compressed file)
• cab (Microsoft cabinet file)
• gzip* (Compressed file - UNIX gzip)
• lha (Compressed Archive [LHA/LHARC/LZH])
• rar (Compressed archive
• sit (Compressed archive - Macintosh file [Stuffit])
• tar* (Compressed archive)
• unix (UNIX compress file)
• zip* (Compressed archive - Windows)
• zoo (ZOO Compressed Archive File)
* These file types can be “body-scanned”
Text • txt
• html
• xml
Image • bmp
• cur
• gif
• ico
• jpeg
• pcx
• png
• psd
• psp
• tga
• tiff
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
202
Using Message Filters to Enforce Email Policies
Action Variables
Attachment Group Name Scanned File Types
Media • aac
• aiff
• asf
• avi
• flash
• midi
• mov
• mp3
• mpeg
• ogg
• ram
• snd
• wav
• wma
• wmv
Action Variables
The bcc() , bcc-scan() , notify() , notify-copy() , add-footer() , add-heading() , and insert-headers() actions
have parameters that may use certain variables that will be automatically replaced with information from the
original message when the action is executed. These special variables are called action variables. Your email
gatewaysupports the following set of action variables:
Table 26: Message Filter Action Variables
Variable Syntax Description
All Headers Returns the message headers.
$AllHeaders
Body Size Returns the size, in bytes, of the message.
$BodySize
Certificate Signers Returns the signers from the subjectAltName element of a
$CertificateSigners
signing certificate. See $CertificateSigners Action Variable,
on page 183 for more information.
Date Returns the current date, using the format MM/DD/YYYY.
$Date
Dropped File Name Returns only the most recently dropped filename.
$dropped_filename
Dropped File Names Displays list of dropped files (similar to $filenames .
$dropped_filenames
Dropped File Types Displays list of dropped file types (similar to $filetypes) .
$dropped_filetypes
Envelope Sender Returns the Envelope Sender (Envelope From, <MAIL
$EnvelopeFrom
FROM>) of the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
203
Using Message Filters to Enforce Email Policies
Action Variables
Variable Syntax Description
Envelope Recipients Returns all Envelope Recipients (Envelope To, <RCPT TO>)
$EnvelopeRecipients
of the message.
File Names Returns a comma-separated list of the message’s attachments’
$filenames
filenames.
File Sizes Returns a comma-separated list of the message’s attachments
$filesizes
file sizes.
File Types Returns a comma-separated list of the message's attachments'
$filetypes
file types.
Filter Name Returns the name of the filter being processed.
$FilterName
GMTimeStamp Returns the current time and date, as would be found in the
$GMTimeStamp
Received: line of an email message, using GMT.
HAT Group Name Returns the name of the sender group the sender matched on
$Group
when injecting the message. If the sender group had no name,
the string “ >Unknown< ” is inserted.
Matched Content Returns the content that triggered a scanning filter rule
$MatchedContent
(including filter rules such as body-contains and content
dictionaries).
Mail Flow Policy Returns the name of the HAT policy applied to the sender
$Policy
when injecting the message. If no predefined policy name was
used, the string “ >Unknown< ” is inserted.
Header Returns the value of the quoted header, if the original message
$Header['string
contains a matching header. Note that double quotes may also
']
be used.
Hostname Returns the hostname of the email gateway.
$Hostname
Internal Message ID Returns the Message ID, or “MID” used internally to identify
$MID
the message. Not to be confused with the RFC822
“Message-Id” value (use $Header to retrieve that).
Receiving Listener Replaced by the nickname of the listener that received the
$RecvListener
message.
Receiving Interface Returns the nickname of the interface that received the
$RecvInt
message.
Remote IP Address Returns the IP address of the system that sent the message to
$RemoteIP
the email gateway.
Remote Host Address Returns the hostname of the system that sent the message to
$remotehost
the email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
204
Using Message Filters to Enforce Email Policies
Non-ASCII Character Sets and Message Filter Action Variables
Variable Syntax Description
IP Reputation Score Returns the IP Reputation score of the sender. If there is no
$Reputation
reputation score, it is replaced with “ None ”.
Subject Returns the subject of the message.
$Subject
Time Returns the current time, in the local time zone.
$Time
Timestamp Returns the current time and date, as would be found in the
$Timestamp
Received: line of an email message, in the local time zone.
Related Topics
• Non-ASCII Character Sets and Message Filter Action Variables, on page 205
Non-ASCII Character Sets and Message Filter Action Variables
The system supports the expansion of action variables that contain ISO-2022 style character codings (the style
of encoding used in header values) and also supports international text in the notification. These will be merged
together to generate a notification that will then be sent as a UTF-8, quoted printable message.
Matched Content Visibility
When you configure a quarantine action for messages that match Attachment Content conditions, Message
Body or Attachment conditions, Message body conditions, or the Attachment content conditions, you can
view the matched content in the quarantined message. When you display the message body, the matched
content is highlighted in yellow. You can also use the $MatchedContent action variable to include the matched
content in the message subject.
When you view messages in the local quarantine that have triggered message or content filter rules, the GUI
may display content that did not actually trigger the filter action (along with content that triggered the filter
action). The GUI display should be used as a guideline for locating content matches, but does not necessarily
reflect an exact list of content matches. This occurs because the GUI uses less strict content matching logic
than is used in the filters. This issue applies only to the highlighting in the message body. The table that lists
the matched strings in each part of the message along with the associated filter rule is correct.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
205
Using Message Filters to Enforce Email Policies
Description and Examples of Message Filter Actions
Figure 17: Matched Content Viewed in the Policy Quarantine
Description and Examples of Message Filter Actions
The following section describes the various message filter actions in use and their examples.
• Skip Remaining Message Filters Action, on page 207
• Drop Action, on page 207
• Bounce Action, on page 208
• Encrypt Action, on page 208
• Notify and Notify-Copy Actions, on page 209
• Blind Carbon Copy Actions, on page 211
• Quarantine and Duplicate Actions, on page 213
• Alter Recipient Action, on page 214
• Alter Delivery Host Action, on page 214
• Alter Source Host (Virtual Gateway address) Action, on page 215
• Archive Action, on page 215
• Strip Header Action, on page 216
• Insert Header Action , on page 216
• Edit Header Text Action, on page 217
• Edit Body Text Action, on page 217
• HTML Convert Action, on page 218
• Bounce Profile Action, on page 219
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
206
Using Message Filters to Enforce Email Policies
Skip Remaining Message Filters Action
• Bypass Anti-Spam System Action, on page 219
• Bypassing Graymail Actions, on page 220
• Bypass Anti-Virus System Action, on page 220
• Bypass File Reputation Filtering and File Analysis System Actions, on page 221
• Bypass Anti-Virus System Action, on page 220
• Add Message Tag Action, on page 221
• Add Log Entry Action, on page 222
• URL Reputation Actions , on page 222
• URL Category Actions , on page 224
• No Operation, on page 225
• Forged Email Detection Action, on page 225
Skip Remaining Message Filters Action
The skip-filters action ensures that the message skips any further processing from message filters and
continues through the email pipeline. The message that incurs the skip-filters action will be subject to
anti-spam scanning and anti-virus scanning, if it is available on the email gateway. The skip-filters action
is the default final action for message filters.
The following filter notifies [email protected] and then immediately delivers any message addressed
to boss@admin .
bossFilter:
if(rcpt-to == 'boss@admin$')
notify('[email protected]');
skip-filters();
Drop Action
The drop action discards a message without any delivery. The message is not returned to the sender, not sent
to the intended recipient, nor processed further in any way.
The following filter first notifies [email protected] and then discards any message where the subject
begins with SPAM .
spamFilter:
if(subject == '^SPAM.*')
notify('[email protected]');
drop();
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
207
Using Message Filters to Enforce Email Policies
Bounce Action
Bounce Action
The bounce action sends the message back to the sender (Envelope Sender) without further processing.
The following filter returns (bounces) any message from an email address that ends in @yahoo\\.com .
yahooFilter:
if(mail-from == '@yahoo\\.com$')
bounce();
Encrypt Action
The encrypt action uses the configured encryption profile to deliver encrypted messages to email recipients.
The following filter encrypts messages if they contain the term [encrypt] in the subject:
Encrypt_Filter:
if ( subject == '\\[encrypt\\]' )
encrypt('My_Encryption_Profile');
Note You must have a Cisco Encryption Appliance in your network or a hosted key service configured to use this
filter action. You must also have configured an encryption profile to use this filter action.
S/MIME Sign or Encrypt on Delivery Action
The smime-gateway-deferred action performs an S/MIME signing or encryption of the message using the
specified sending profile during the delivery. This means that the message continues to the next stage of
processing, and when all processing is complete, the message is signed or encrypted and delivered.
The following filter performs an S/MIME encryption on all the outgoing messages from a particular sender
during the delivery:
smime-deferred:if(mail-from == "[email protected]"){smime-gateway-deferred("smime-encrypt");}
S/MIME Sign or Encrypt Action
The smime-gateway action performs an S/MIME signing or encryption using the specified sending profile
and delivers the message, skipping any further processing.
The following filter performs an S/MIME signing on all the outgoing messages from a particular sender and
delivers them immediately:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
208
Using Message Filters to Enforce Email Policies
Notify and Notify-Copy Actions
smime-deliver-now:if(mail-from == "[email protected]"){smime-gateway("smime-sign");}
Notify and Notify-Copy Actions
The notify and notify-copy actions send an email summary of the message to the specified email address.
The notify-copy action also sends a copy of the original message, similar to the bcc-scan action. The
notification summary contains:
• The contents of the Envelope Sender and Envelope Recipient ( MAIL FROM and RCPT TO ) directives from
the mail transfer protocol conversation for the message.
• The message headers of the message.
• The name of the message filter that matched the message.
You can specify the recipient, subject line, from address, and notification template. the following filter selects
messages with sizes larger than 4 megabytes, sends a notification email of each matching message to
[email protected] , and finally discards the message:
bigFilter:
if(body-size >= 4M)
notify('[email protected]');
drop();
Or
bigFilterCopy:
if(body-size >= 4M)
notify-copy('[email protected]');
drop();
The Envelope Recipient parameter may be any valid email address (for example, [email protected] in the
example above), or alternatively, may be the action variable $EnvelopeRecipients (see Action Variables,
on page 203), which specifies all Envelope Recipients of the message:
bigFilter:
if(body-size >= 4M)
notify('$EnvelopeRecipients');
drop();
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
209
Using Message Filters to Enforce Email Policies
Notification Template
The notify action also supports up to three additional, optional arguments that allow you to specify the subject
header, the Envelope Sender, and a pre-defined text resource to use for the notification message. These
parameters must appear in order, so a subject must be provided if the Envelope Sender is to be set or a
notification template specified.
The subject parameter may contain action variables (see Action Variables, on page 203) that will be replaced
with data from the original message. By default, the subject is set to Message Notification .
The Envelope Sender parameter may be any valid email address, or alternatively, may be the action variable
$EnvelopeFrom , which will set the return path of the message to the same as the original message
The notification template parameter is the name of an existing notification template. For more information,
see Notifications, on page 232.
This example extends the previous one, but changes the subject to look like [bigFilter] Message too large
, sets the return path to be the original sender, and uses the “message.too.large” template:
bigFilter:
if (body-size >= 4M)
notify('[email protected]', '[$FilterName] Message too large',
'$EnvelopeFrom', 'message.too.large');
drop();
You can also use the $MatchedContent action variable to notify senders or administrators that a content filter
was triggered. The $MatchedContent action variable displays the content that triggered the filter. For example,
the following filter sends a notification to an administrator if the email contains ABA account information.
ABA_filter:
if (body-contains ('*aba')){
notify('[email protected]','[$MatchedContent]Account Information Displayed');
Related Topics
• Notification Template, on page 210
Notification Template
You can use the Text Resources page or the textconfig CLI command to configure custom notification
templates as text resources for use with the notify() and notify-copy() actions. If you do not create a
custom notification template, a default template is used. The default template includes message headers, but
the custom notification template does not include message headers by default. To include message headers
in the custom notification, include the $AllHeaders action variable.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
210
Using Message Filters to Enforce Email Policies
Blind Carbon Copy Actions
For more information, see the “Text Resources” chapter.
In the following example, when a large message triggers the filter shown below, an email is sent to the intended
recipients explaining that the message was too large:
bigFilter:
if (body-size >= 4M)
notify('$EnvelopeRecipients', '[$FilterName] Message too large',
'$EnvelopeFrom', 'message.too.large');
drop();
Blind Carbon Copy Actions
The bcc action sends an anonymous copy of the message to a specified recipient. This is sometimes referred
to as message replication. Because no mention of the copy is made in the original message and the anonymous
copy will never successfully bounce back to the recipient, the original sender and recipients of the message
will not necessarily know that the copy was sent.
The following filter sends a blind carbon copy to [email protected] for each message addressed to sue from
johnny :
momFilter:
if ((mail-from == '^johnny$') and (rcpt-to == '^sue$'))
bcc('[email protected]');
The bcc action also supports up to three additional, optional arguments that allow you to specify the subject
header and Envelope Sender to use on the copied message, as well as an alt-mailhost. These parameters must
appear in order, so a subject must be provided if the Envelope Sender is to be set.
The subject parameter may contain action variables (see Action Variables, on page 203) that will be replaced
with data from the original message. By default, this is set to the subject of the original message (the equivalent
of $Subject ).
The Envelope Sender parameter may be any valid email address, or alternatively, may be the action variable
$EnvelopeFrom , which will set the return path of the message to the same as the original message.
This example expands the previous one by setting the subject to be [Bcc] <original subject> , and the
return path set to [email protected] :
momFilter:
if ((mail-from == '^johnny$') and (rcpt-to == '^sue$'))
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
211
Using Message Filters to Enforce Email Policies
The bcc-scan() Action
bcc('[email protected]', '[Bcc] $Subject', '[email protected]');
The alt-mailhost is the fourth parameter:
momFilterAltM:
if ((mail-from == '^johnny$') and (rcpt-to == '^sue$'))
bcc('[email protected]', '[Bcc] $Subject', '$EnvelopeFrom',
'momaltmailserver.example.com');
Caution The Bcc() , notify() , and bounce() filter actions can allow viruses through your network. The blind carbon
copy filter action creates a new message which is a full copy of the original message. The notify filter action
creates a new message that contains the headers of the original message. While it is rare, headers can contain
viruses. The bounce filter action creates a new message which contains the first 10k of the original message.
In all three cases, the new message will not be processed by anti-virus or anti-spam scanning.
To send to multiple hosts, you can call the bcc() action multiple times:
multiplealthosts:
if (recv-listener == "IncomingMail")
insert-header('X-ORIGINAL-IP', '$remote_ip');
bcc ('$EnvelopeRecipients', '$Subject', '$EnvelopeFrom', '10.2.3.4');
bcc ('$EnvelopeRecipients', '$Subject', '$EnvelopeFrom', '10.2.3.5');
bcc ('$EnvelopeRecipients', '$Subject', '$EnvelopeFrom', '10.2.3.6');
Related Topics
• BCC and Scan Mail Sent to Competitors, on page 252
The bcc-scan() Action
The bcc-scan action functions similarly to the bcc action, except that the message that is sent is treated as a
brand new message and is therefore sent through the entire email pipeline.
momFilter:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
212
Using Message Filters to Enforce Email Policies
Quarantine and Duplicate Actions
if ((mail-from == '^johnny$') and (rcpt-to == '^sue$'))
bcc-scan('[email protected]');
Quarantine and Duplicate Actions
The quarantine(‘quarantine_name’) action flags a message for inclusion into a queue called a quarantine.
For more information about quarantines, see the “Quarantines” chapter. The duplicate-quarantine (
‘quarantine_name’) action immediately places a copy of the message into the specified quarantine and the
original message continues through the email pipeline. The quarantine name is case sensitive.
When flagged for quarantine, the message continues through the rest of the email pipeline. When the message
reaches the end of the pipeline, if the message has been flagged for one or more quarantines then it enters
those queues. Otherwise, it is delivered. Note that if the message does not reach the end of the pipeline, it is
not placed in a quarantine.
Accordingly, if a message filter contains a quarantine() action followed by a bounce() or drop() action,
the message will not enter the quarantine, since the final action prevents the message from reaching the end
of the pipeline. The same is true if a message filter includes a quarantine action, but the message is later
dropped by anti-spam or anti-virus scanning, or a content filter. The skip-filters() action causes the message
to skip any remaining message filters, but content filters may still apply. For example, if a message filter flags
a message for quarantine and also includes the skip-filters() action, the message skips all remaining
message filters and will be quarantined, unless another action in the email pipeline causes the message to be
dropped.
In the following example, the message is sent to the Policy quarantine if the message contains any words
within the dictionary named “secret_word.”
quarantine_codenames:
if (dictionary-match ('secret_words'))
quarantine('Policy');
In the following example, suppose a company has an official policy to drop all .mp3 file attachments. If an
inbound message has a .mp3 attachment, the attachment is stripped and the remaining message (original body
and remaining attachments) is sent to the original recipient. Another copy of the original message with all
attachments will be quarantined (sent to the Policy quarantine). If it is necessary to receive the blocked
attachment(s), the original recipient would then request that the message be released from the quarantine.
strip_all_mp3s:
if (attachment-filename == '(?i)\\.mp3$') {
duplicate-quarantine('Policy');
drop-attachments-by-name('(?i)\\.mp3$');
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
213
Using Message Filters to Enforce Email Policies
Alter Recipient Action
Alter Recipient Action
The alt-rcpt-to action changes all recipients of the message to the specified recipient upon delivery.
The following filter sends all messages with an Envelope Recipient address that contain .freelist.com and
changes all recipients for the message to [email protected] :
freelistFilter:
if(rcpt-to == '\\.freelist\\.com$')
alt-rcpt-to('[email protected]');
Alter Delivery Host Action
The alt-mailhost action changes the IP address for all recipients of the selected message to the numeric IP
address or hostname given.
Note The alt-mailhost action prevents a message classified as spam by an anti-spam scanning engine from being
quarantined. The alt-mailhost action overrides the quarantine action and sends it to the specified mail host.
The following filter redirects recipient addresses to the host example.com for all messages.
localRedirectFilter:
if(true)
alt-mailhost('example.com');
Thus, a message directed to [email protected] is delivered to the mailhost at example.com with the Envelope
To address [email protected] . Note that any additional routing information specified by the smtproutes
command still affects the routing of the message. (See Routing Email for Local Domains, on page 697.)
Note The alt-mailhost action does not support specifying a port number. To do this, add an SMTP route instead.
The following filter redirects all messages to 192.168.12.5 :
local2Filter:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
214
Using Message Filters to Enforce Email Policies
Alter Source Host (Virtual Gateway address) Action
if(true)
alt-mailhost('192.168.12.5');
Alter Source Host (Virtual Gateway address) Action
The alt-src-host action changes the source host for the message to the source specified. The source host
consists of the IP interface or group of IP interfaces that the messages should be delivered from. If a group
of IP interfaces is selected, the system round-robins through all of the IP interfaces within the group as the
source interface when delivering email. In essence, this allows multiple Virtual Gateway addresses to be
created on a single email gateway. For more information, see Configuring Mail Gateways for all Hosted
Domains Using Virtual Gateway™ Technology, on page 749.
The IP interface may only be changed to an IP interface or interface group currently configured in the system.
the following filter creates a Virtual Gateway using the outbound (delivery) IP interface outbound2 for all
messages received from a remote host with the IP address 1.2.3.4 .
externalFilter:
if(remote-ip == '1.2.3.4')
alt-src-host('outbound2');
The following filter uses the IP interface group Group1 for all messages received from a remote host with the
IP address 1.2.3.4 .
groupFilter:
if(remote-ip == '1.2.3.4')
alt-src-host('Group1');
Archive Action
The archive action saves a copy of the original message, including all message headers and recipients into
an mbox-format file on the email gateway. The action takes a parameter that is the name of the log file in
which to save the message. The system automatically creates a log subscription with the specified filename
when you create the filter, or you can also specify an existing filter log file. After the filter and the filter log
file are created, the filter log options may then be edited with the filters -> logconfig subcommand.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
215
Using Message Filters to Enforce Email Policies
Strip Header Action
Note The logconfig command is a subcommand of filters . See Using the CLI to Manage Message Filters, on
page 236 for a full description of how to use this subcommand.
The mbox format is a standard UNIX mailbox format, and there are many utilities available to make viewing
the messages easier. Most UNIX systems allow you to type “ mail -f mbox.filename ” to view the files. The
mbox format is in plain text, so you can use a simple text editor to view the contents of the messages.
In the following example, a copy of the message is saved to a log named joesmith if the Envelope Sender
matches [email protected] :
logJoeSmithFilter:
if(mail-from == '^joesmith@yourdomain\\.com$')
archive('joesmith');
Strip Header Action
The strip-header action examines the message for a particular header and removes those lines from the
message before delivering it. When there are multiple headers, all instances of the header are removed (for
example, the “Received:” header.)
In the following example, all messages have the header X-DeleteMe removed before transmission:
stripXDeleteMeFilter:
if (true)
strip-header('X-DeleteMe');
When working with headers, remember that the current value of the header includes changes made during
processing (such as with filter actions that add, remove, or modify message headings). See Message Header
Rules and Evaluation, on page 143 for more information.
Insert Header Action
The insert-header action inserts a new header into a message. AsyncOS does not verify the compliance to
standards of the header you insert; you are responsible for ensuring that the resulting message complies with
Internet standards for email.
The following example inserts a header named X-Company with the value set to My Company Name if the header
is not already found in the message:
addXCompanyFilter:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
216
Using Message Filters to Enforce Email Policies
Edit Header Text Action
if (not header('X-Company'))
insert-header('X-Company', 'My Company Name');
The insert-header() action allows the use of non-ASCII characters in the text of the header, while restricting
the header name to be ASCII (to comply with standards). The transport encoding will be quoted-printable to
maximize the readability.
Note The strip-headers and insert-header actions can be used in combination to rewrite any message headers
in the original message. In some case, it is valid to have multiple instances of the same header (for example,
Received: ) where in other cases, multiple instances of the same header could confuse a MUA (for example,
multiple Subject: headers.)
When working with headers, remember that the current value of the header includes changes made during
processing (such as with filter actions that add, remove, or modify message headings). See Message Header
Rules and Evaluation, on page 143 for more information.
Edit Header Text Action
The edit-header-text action allows you to rewrite specified header text using the regular expression
substitution function. The filter matches the regular expression within the header and replaces it with a regular
expression you specify.
For example, an email contains the following subject header:
Subject: SCAN Marketing Messages
The following filter removes the “SCAN” text, and leaves the text, “Marketing Messages”, in the header:
Remove_SCAN: if true
edit-header-text (‘Subject’, ‘^SCAN\\s*’,’’);
After the filter processes the message, it returns the following header:
Subject: Marketing Messages
Edit Body Text Action
The edit-body-text() message filter is similar to the Edit-Header-Text() filter, but it operates across the
body of the message instead of one of the headers.
The edit-body-text() message filter uses the following syntax where the first parameter is the regular
expression to search for and the second parameter is the replacement text:
Example: if true {
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
217
Using Message Filters to Enforce Email Policies
HTML Convert Action
edit-body-text("parameter 1","parameter 2");
The edit-body-text() message filter only works on the message body parts. For more information about
whether a given MIME part is considered a message “body” or a message “attachment”, see Message Bodies
vs. Message Attachments, on page 143.
The following example shows a URL removed from a message and replaced with the text, ‘URL REMOVED’:
URL_Replaced: if true {
edit-body-text("(?i)(?:https?|ftp)://[^\\s\">]+", "URL REMOVED");
The following example shows a social security number removed from the body of a message and replaced
with the text, “XXX-XX-XXXX’:
ssn: if true {
edit-body-text("(?!000)(?:[0-6]\\d{2}|7(?:[0-6]\\d|7[012]))([
-]?)(?!00)\\d\\d\\1(?!0000)\\d{4}",
"XXX-XX-XXXX");
Note You cannot use smart identifiers with the edit-body-text() filter at this time.
HTML Convert Action
While RFC 2822 defines a text format for email messages, there are extensions (such as MIME) to provide
the transport of other content within an RFC 2822 message. AsyncOS can now use the html-convert()
message filter to convert HTML to plain text using the following syntax:
Convert_HTML_Filter:
if (true)
html-convert();
The Cisco message filters make a determination on whether a given MIME part is considered a message
“body” or a message “attachment”. The html-convert() filter only works on the message body parts. For
more information about message bodies and attachments, see Message Bodies vs. Message Attachments, on
page 143.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
218
Using Message Filters to Enforce Email Policies
Bounce Profile Action
Depending on the format, the html-convert() filter uses different methods to strip the HTML from within
the documents.
If the message is plain text (text/plain), the message passes through the filter unchanged. If the message is a
simple HTML message (text/html), all the HTML tags are stripped out of the message and the resulting body
replaces the HTML message. The lines are not reformatted, and the HTML is not rendered in plain text. If
the structure is MIME (with a multipart/alternative structure) and it contains both a text/plain part and text/html
part with the same content, the filter removes the text/html part of the message and leaves the text/plain part
of the message. For all other MIME types (such as multipart/mixed), all HTML body parts are stripped of
their tags and reinserted into the message.
When encountered in a message filter, the html-convert() filter action only tags the message to be processed
but does not immediately make a change to the message structure. The changes to the message only take effect
after all processing is complete. This allows the other filter actions to process the original message body prior
to modification.
Bounce Profile Action
The bounce-profile action assigns a previously-configured bounce profile to the message. (See Directing
Bounced Email, on page 726.) If the message is undeliverable, the bounce options configured via the bounce
profile are used. Using this feature overrides the bounce profile assigned to the message from the listener’s
configuration (if one is assigned).
The following filter example assigns the bounce profile “fastbounce” to all email sent with the header
X-Bounce-Profile: fastbounce :
fastbounce:
if (header ('X-Bounce-Profile') == 'fastbounce') {
bounce-profile ('fastbounce');
Bypass Anti-Spam System Action
The skip-spamcheck action instructs the system to allow the message to bypass any content-based anti-spam
filtering configured on the system. This action does nothing to the message if no content-based anti-spam
filtering is configured, or if the message was never flagged to be scanned for spam in the first place.
The following example allows messages that have a high IP Reputation Score to bypass the content-based
anti-spam filtering feature:
allowed_list_on_reputation:
if (reputation > 7.5)
skip-spamcheck();
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
219
Using Message Filters to Enforce Email Policies
Bypassing Graymail Actions
Related Topics
• How Incoming Relays Affect Functionality , on page 418
• Protecting Email Gateway-Generated Messages From the Spam Filter, on page 405
Bypassing Graymail Actions
If you do not want to apply graymail actions on certain messages, you can bypass them using the following
message filter actions:
Message Filter Action Description
skip-marketingcheck Bypass actions on marketing emails
skip-socialcheck Bypass actions on social network emails
skip-bulkcheck Bypass actions on bulk emails
The following example specifies that messages received on the listener “private_listener” must bypass graymail
actions on social network emails.
internal_mail_is_safe:
if (recv-listener == 'private_listener')
skip-socialcheck();
Bypass Anti-Virus System Action
The skip-viruscheck action instructs the system to allow the message to bypass any virus protection system
configured on the system. This action does nothing to the message if there is no anti-virus system configured,
or if the message was never flagged to be scanned for viruses in the first place.
The following example specifies that messages received on the listener “private_listener” should bypass the
anti-spam and the anti-virus systems.
internal_mail_is_safe:
if (recv-listener == 'private_listener')
skip-spamcheck();
skip-viruscheck();
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
220
Using Message Filters to Enforce Email Policies
Bypass File Reputation Filtering and File Analysis System Actions
Bypass File Reputation Filtering and File Analysis System Actions
The skip-ampcheck action instructs the system to allow message to bypass File Reputation Filtering and File
Analysis configured on the system. This action does nothing to the message if File Reputation Filtering and
File Analysis is not configured, or if the message was never flagged to be scanned for File Reputation Filtering
and File Analysis in the first place.
The following example specifies that messages with PDF attachments should bypass File Reputation Filtering
and File Analysis.
skip_amp_scan:
if (attachment-filetype == 'pdf')
{
skip-ampcheck();
}
Bypass Outbreak Filter Scanning Action
The skip-vofcheck action instructs the system to allow the message to bypass the Outbreak Filters scanning.
This action does nothing to the message if Outbreak Filters scanning is not enabled.
The following example specifies that messages received on the listener “private_listener” should bypass
Outbreak Filter scanning.
internal_mail_is_safe:
if (recv-listener == 'private_listener') Outbreak Filters
skip-vofcheck();
Add Message Tag Action
The tag-message action inserts a custom term into an outgoing message to use with DLP policy filtering.
You can configure a DLP policy to limit scanning to messages with the message tag. The message tag is not
visible to recipients. The tag name can contain any combination of characters from the set [a-zA-Z0-9_-.]
.
For information on configuring a DLP policy to filter messages, see the “Data Loss Prevention” chapter.
The following example inserts a message tag into a message with “[Encrypt]” in the subject. You can then
create a DLP policy that will encrypt messages with this message tag before delivering them if Cisco Email
Encryption is available:
Tag_Message:
if (subject == '^\\[Encrypt\\]')
tag-message('Encrypt-And-Deliver');
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
221
Using Message Filters to Enforce Email Policies
Add Log Entry Action
Add Log Entry Action
The log-entry action inserts customized text into the Text Mail logs at the INFO level. The text can include
action variables. You can use this action to insert useful text for debugging purposes and information on why
a message filter performed a certain action. The log entry also appears in message tracking.
The following example inserts a log entry explaining that message was bounced because it possibly contained
confidential company information:
CompanyConfidential:
if (body-contains('Company Confidential'))
log-entry('Message may have contained confidential information.');
bounce();
URL Reputation Actions
Use the reputation score of URLs in messages to modify the URLs or their behavior. For important details
and examples, see Modifying URLs in Messages: Using URL Reputation and URL Category Actions in Filters
, on page 458 in Protecting Against Malicious or Undesirable URLs, on page 449
No rule is needed with these actions.
In URL Reputation actions:
• msg_filter_name : is the name of this message filter.
• min_score and max_score are the minimum and maximum scores in the range for which the action should
apply. The applicable range includes the values that you specify.
Minimum and maximum scores must be between -10.0 and 10.0 .
• To specify an action when the reputation service does not provide a score, use the corresponding
"no-reputation" version of the action, as shown in the following subsections.
• allowedlist is the name of a defined URL list (via the urllistconfig command.) Specifying an allowed
list is optional.
• In place of Preserve_signed , enter 0 or 1:
• 1 - Apply this action to unsigned messages only
• 0 - Apply this action to all messages
If you do not specify a preserve_signed value, the action is applied to unsigned messages only.
Related Topics
• Replace URL with Text, Based on URL Reputation, on page 223
• Defang URL, Based on URL Reputation, on page 223
• Redirect URL to Cisco Security Proxy, Based on URL Reputation , on page 223
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
222
Using Message Filters to Enforce Email Policies
Replace URL with Text, Based on URL Reputation
Replace URL with Text, Based on URL Reputation
To take action when the reputation service provides a score:
Use the url-reputation-replace action.
The syntax of a filter using the url-reputation-replace action is:
<msg_filter_name>:
if <condition>
{url-reputation-replace(<min_score>, <max_score>,’<replace_text>’, '< allowedlist> ', <
Preserve_signed> );}
Where replace_text is the text with which to replace the URL.
To take action when the reputation service does not provide a score:
Use the url-no-reputation-replace action.
The syntax of a filter using the url-no-reputation-replace action is:
<msg_filter_name>:
if <condition>
{url-no-reputation-replace ('<replace_text>', '<allowedlist>', <Preserve_signed>);}
Where replace_text is the text with which to replace the URL.
Defang URL, Based on URL Reputation
To take action when the reputation service provides a score:
Use the url-reputation-defang action.
The syntax of a filter using the url-reputation-defang action is:
<msg_filter_name>:
if <condition>
{url-reputation-defang (<min_score>, <max_score>, '<allowedlist>', <Preserve_signed>);}
To take action when the reputation service does not provide a score:
Use the url-no-reputation-defang action.
The syntax of a filter using the url-no-reputation-defang action is:
<msg_filter_name>:
if <condition>
{url-no-reputation-defang ('<allowedlist>', <Preserve_signed>);}
Redirect URL to Cisco Security Proxy, Based on URL Reputation
To take action when the reputation service provides a score:
Use the url-reputation-proxy-redirect action.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
223
Using Message Filters to Enforce Email Policies
URL Category Actions
The syntax of a filter using the url-reputation-proxy-redirect action is:
<msg_filter_name>:
if <condition>
{url-reputation-proxy-redirect (<min_score>, <max_score>, '<allowedlist>',
<Preserve_signed>);}
To take action when the reputation service does not provide a score:
Use the url-no-reputation-proxy-redirect action.
The syntax of a filter using the url-no-reputation-proxy-redirect action is:
<msg_filter_name>:
if <condition>
{url-no-reputation-proxy-redirect ('<allowedlist>', <Preserve_signed>);}
URL Category Actions
Use the categories of URLs in messages to modify the URLs or their behavior. For important details, see
Modifying URLs in Messages: Using URL Reputation and URL Category Actions in Filters , on page 458 in
Protecting Against Malicious or Undesirable URLs, on page 449
No rule is needed with these actions.
In all URL Category actions:
• msg_filter_name : is the name of the message filter.
• category-name is the URL category. Separate multiple categories with commas. To obtain correct category
names, look at a URL Category condition or action in a Content Filter. For descriptions and examples
of the categories, see About URL Categories, on page 467.
• url_allowed_list is the name of a defined URL list (via the urllistconfig command.)
• unsigned-only : Enter 0 or 1.
• 1 - Apply this action to unsigned messages only
• 0 - Apply this action to all messages
Related Topics
• Replace URL with Text, Based on URL Category , on page 224
• Defang URL, Based on URL Category , on page 225
• Redirect URL to Cisco Security Proxy, Based on URL Category , on page 225
Replace URL with Text, Based on URL Category
The syntax of a filter using the url-category-replace action is
<msg_filter_name>:
if <condition>
url-category-replace([‘<category-name1>’,’<category-name2>’,...,
‘<category-name3>’],’<replacement-text>’, ’<url_allowed_list>’, <unsigned-only>);
Where replacement-text is the text that you want to use to replace the URL.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
224
Using Message Filters to Enforce Email Policies
Defang URL, Based on URL Category
Defang URL, Based on URL Category
The syntax of a filter using the url-category-defang action is:
<msg_filter_name>:
if <condition>
url-category-defang([‘<category-name1>’,’<category-name2>’,..., ‘<category-name3>’],
’<url_allowed_list>’, <unsigned-only>);
Redirect URL to Cisco Security Proxy, Based on URL Category
The syntax of a filter using the url-category-proxy-redirect action is:
<msg_filter_name>:
if <condition>
url-category-proxy-redirect([‘<category-name1>’,’<category-name2>’,..., ‘<category-name3>’],
’<url_allowed_list>’, <unsigned-only>);
No Operation
The No Operation action performs a no-op, or no operation. You can use this action in a message filter if you
do not want to use any of the other actions such as Notify, Quarantine, or Drop. For example, to understand
the behavior of a new message filter that you created, you can use the No Operation action. After the message
filter is operational, you can monitor the behavior of the new message filter using the Message Filters report
page, and fine-tune the filter to match your requirements.
The following example shows how to use No Operation action in a message filter.
new_filter_test: if header-repeats ('subject', X, 'incoming') {no-op();}
Forged Email Detection Action
Strips the From: header from the forged message and replaces it with the Envelope Sender.
The following message filter compares the From: header in the message with the terms in dictionary and if
the matching score of a term in the content dictionary is greater than or equal to 70, the message filter strips
the From: header and replaces it with the Envelope Sender.
FED_CF: if (forged-email-detection("Execs", 70)) { fed("from", ""); }
Attachment Scanning
The email gateway uses Content Scanner to strip attachments from messages that are inconsistent with your
corporate policies, while still retaining the ability to deliver the original message.
You can filter attachments based on their specific file type, fingerprint, or based on the content of the
attachment. Using the fingerprint to determine the exact type of attachment prevents users from renaming a
malicious attachment extension (for example, .exe ) to a more commonly used extension (for example, .doc
) in the hope that the renamed file would bypass attachment filters.
When you scan attachments for content, the Content Scanner extracts data from attachment files to search for
the regular expression. It examines both data and metadata in the attachment file. If you scan an Excel or
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
225
Using Message Filters to Enforce Email Policies
Attachment Scanning
Word document, the attachment scanning engine can also detect the following types of embedded files: .exe,
.dll, .bmp, .tiff, .pcx, .gif, .jpeg, .png, and Photoshop images.
The Content Scanner in your email gateway can perform content scanning on the following archive file
formats:
• ACE Archive
• ALZ Archive
• Apple Disk Image
• ARJ Archive
• bzip2 Archive
• EGG Archive
• GNU Zip
• ISO Disk Image
• Java Archive
• LZH
• Microsoft Cabinet Archive
• RAR Multi-Part File
• RedHat Package Manager Archive
• Roshal Archive (RAR)
• Unix AR Archive
• UNIX Compress Archive
• UNIX cpio
• UNIX Tar
• XZ Archive
• Zip Archive
• 7-Zip
• ARC
Note You can view the details of the Content Scanner-related files using the Security Services > Scan Behavior
page in web interface or using the contentscannerstatus command in CLI. These files are automatically updated
using update server. If you want to manually update these files, see Configuring Scan Behavior, on page 258.
Related Topics
• Message Filters for Scanning Attachments, on page 227
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
226
Using Message Filters to Enforce Email Policies
Message Filters for Scanning Attachments
• Image Analysis, on page 228
• Configuring the Image Analysis Scanning Engine, on page 228
• Configuring the Message Filter to Perform Actions Based on Image Analysis Results, on page 230
• Notifications, on page 232
• Examples of Attachment Scanning Message Filters, on page 232
Message Filters for Scanning Attachments
The message filter actions described in the following table are non-final actions. (Attachments are dropped
and the message processing continues.)
The optional comment is text that is added to the message, much like a footer, and it can contain Message
Filter Action Variables (see Examples of Attachment Scanning Message Filters, on page 232).
Table 27: Message Filter Actions for Attachment Filtering
Action Syntax Description
Drop Attachments by Drops all attachments on messages that have a
drop-attachments-by-name
Name filename that matches the given regular
(<regular expression
>[, <optional expression. Archive file attachments (zip, tar)
comment will be dropped if they contain a file that
>]) matches. See Examples of Attachment Scanning
Message Filters, on page 232.
Drop Attachments by Drops all attachments on messages that have a
drop-attachments-by-type
Type MIME type, determined by either the given
(<MIME type
>[, <optional comment MIME type or the file extension. Archive file
>]) attachments (zip, tar) will be dropped if they
contain a file that matches.
Drop Attachments by File Drops all attachments on messages that match
drop-attachments-by-filetype
Type the given “fingerprint” of the file. Archive file
(<fingerprint name attachments (zip, tar) will be dropped if they
>[, <optional comment contain a file that matches.
>])
Drop Attachments by Drops all attachments on messages that have a
drop-attachments-by-mimetype
MIME Type given MIME type. This action does not attempt
(<MIME type to ascertain the MIME type by file extension
>[, <optional comment and so it also does not examine the contents of
>]) archives.
Drop Attachments by Size Drops all attachments on the message that, in
drop-attachments-by-size
raw encoded form, are equal to or greater than
(<number
>[, <optional comment the size (in bytes) given. Note that for archive
>]) or compressed files, this action does not
examine the uncompressed size, but rather the
size of the actual attachment itself.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
227
Using Message Filters to Enforce Email Policies
Image Analysis
Action Syntax Description
Attachment Scanning Drops all attachments on message that contain
drop-attachments-where-contains
the regular expression. Archive files (zip, tar)
(<regular expression will be dropped if any of the files they contain
>[, <optional comment match the regular expression pattern.
>])
Drop Attachments by This filter action strips attachments based on
drop-attachments-where-dictionary
Dictionary Matches matches to dictionary terms. If the terms in the
-match(<dictionary name>)
MIME parts considered to be an attachment
match a dictionary term (and the user-defined
threshold is met), the attachment is stripped
from the email. See Examples of Attachment
Scanning Message Filters, on page 232.
Image Analysis
Some messages contain images that you may wish to scan for inappropriate content. Use the image analysis
engine to search for inappropriate content in email.
The image analyzer uses algorithms that measure image attributes to determine the likelihood of inappropriate
content. These algorithms can detect, for example, the shapes and color palette in an image. The analyzer can
identify the type of shapes in an image and the percentage of any flesh-tone colors relative to the other colors
in the image to help identify inappropriate content. Images with a high percentage of flesh-tone colors are
more likely to be inappropriate. The algorithms do not discriminate in any way.
Image analysis is not designed to supplement or replace your Anti-Virus and Anti-Spam scanning engines.
Its purpose is to enforce acceptable use by identifying inappropriate content in email. Use the image analysis
scanning engine to quarantine and analyze mail and to detect trends.
After you configure your email gateway for image analysis, you can use image analysis filter rules to perform
actions on suspect or inappropriate emails. Image scanning allows you to scan the following types of attached
files: BMP, JPG, TIF, PNG, GIF, TGA, and PCX.
When you scan image attachments, Cisco fingerprinting determines the file type, and the image analyzer uses
algorithms to analyze the image content. If the image is embedded in another file, the Content Scanner extracts
the file. The image analysis verdict is computed on the message as a whole. If the message does not include
any images, the message receives a score of “0” which maps to a “clean” verdict. Therefore, a message without
any images will receive a "clean" verdict.
Configuring the Image Analysis Scanning Engine
To enable image analysis from the GUI:
Procedure
Step 1 Go to Security Services > IronPort Image Analysis.
Step 2 Click Enable.
A success message displays, and the verdict settings display.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
228
Using Message Filters to Enforce Email Policies
Tuning Image Analysis Settings
The image analysis filter rule allows you to determine the actions to take based on the following verdicts:
• Clean: The image is free of inappropriate content. The image analysis verdict is computed on the message
as a whole, so a message without any images will receive a "clean" verdict if scanned.
• Suspect: The image may contain inappropriate content.
• Inappropriate: The image contains inappropriate content.
These verdicts represent a numeric value assigned by the image analyzer algorithm to determine probability
of inappropriate content.
The following values are recommended:
• Clean: 0 to 49
• Suspect: 50 to 74
• Inappropriate: 75 to 100
What to do next
You can fine-tune image scanning by configuring the sensitivity setting, which helps reduce the number of
false positives. For example, if you find that you are getting false positives, you can decrease the sensitivity
setting. Or, conversely, if you find that the image scanning is missing inappropriate content, you may want
to set the sensitivity higher. The sensitivity setting is a value between 0 (no sensitivity) and 100 (highly
sensitive). The default sensitivity setting of 65 is recommended.
Related Topics
• Tuning Image Analysis Settings, on page 229
Tuning Image Analysis Settings
Procedure
Step 1 Go to Security Services > IronPort Image Analysis.
Step 2 Click Edit Settings.
Step 3 Configure the settings for image analysis sensitivity. The default sensitivity setting of 65 is recommended.
Step 4 Configure the settings for Clean, Suspect, and Inappropriate verdicts.
When you configure the value ranges, ensure that you do not overlap values and that you use whole integers.
Step 5 Optionally, configure AsyncOS to bypass scanning images that do not meet a minimum size requirement
(recommended). By default, this setting is configured for 100 pixels. Scanning images that are smaller than
100 pixels can sometimes result in false positives.
You can also enable image analysis settings from the CLI using the imageanalysisconfig command:
What to do next
Related Topics
• Viewing the Verdict Score of a Particular Message, on page 230
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
229
Using Message Filters to Enforce Email Policies
Viewing the Verdict Score of a Particular Message
Viewing the Verdict Score of a Particular Message
To see the verdict score for a particular message, you can view the mail logs. The mail logs display the image
name or file name, the score for a particular message attachment. In addition, the log displays information
about whether the images in a file were scannable or unscannable. Note that information in the log describes
the result for each message attachment, rather than each image. For example, if the message had a zip attachment
that contained a JPEG image, the log entry would contain the name of the zip file rather than the name of the
JPEG. Also, if the zip file included multiple images then the log entry would include the maximum score of
all the images. The unscannable notation indicates whether any of the images were unscannable.
The log does not contain information about how the scores translate to a particular verdict (clean, suspect or
inappropriate). However, because you can use mail logs to track the delivery of specific messages, you can
determine by the actions performed on the messages whether the mail contained inappropriate or suspect
images.
For example, the following mail log shows attachments dropped by message filter rules as a result of Image
Analysis scanning:
Thu Apr 3 08:17:56 2009 Debug: MID 154 IronPort Image Analysis: image 'Unscannable.jpg'
is unscannable.
Thu Apr 3 08:17:56 2009 Info: MID 154 IronPort Image Analysis: attachment
'Unscannable.jpg' score 0 unscannable
Thu Apr 3 08:17:56 2009 Info: MID 6 rewritten to MID 7 by
drop-attachments-where-image-verdict filter 'f-001'
Thu Apr 3 08:17:56 2009 Info: Message finished MID 6 done
Configuring the Message Filter to Perform Actions Based on Image Analysis
Results
Once you enable image analysis, you must create a message filter to perform different actions for different
message verdicts. For example, you may wish to deliver messages with a clean verdict, but quarantine messages
that are determined to have inappropriate content.
Note Cisco recommends you do not drop or bounce messages with inappropriate or suspect verdicts. Instead, send
copies of violations to a quarantine for later review and better understanding of trend analysis.
The following filter shows messages tagged if the content is inappropriate or suspect:
image_analysis: if image-verdict == "inappropriate" {
strip-header("Subject");
insert-header("Subject", "[inappropriate image] $Subject");
else {
if image-verdict == "suspect" {
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
230
Using Message Filters to Enforce Email Policies
Creating Content Filters to Strip Attachments Based on Image Analysis Verdicts
strip-header("Subject");
insert-header("Subject", "[suspect image] $Subject");
Related Topics
• Creating Content Filters to Strip Attachments Based on Image Analysis Verdicts , on page 231
Creating Content Filters to Strip Attachments Based on Image Analysis Verdicts
After you enable image analysis, you can create a content filter to strip attachments based on image analysis
verdicts, or you can configure a filter to perform different actions for different message verdicts. For example,
you might decide to quarantine messages that contain inappropriate content.
To strip attachments based on image analysis verdicts:
Procedure
Step 1 Click Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 Enter a name for the content filter.
Step 4 Under Actions, click Add Action.
Step 5 Under Strip Attachment by File Info, click Image Analysis Verdict is:
Step 6 Select from the following image analysis verdicts:
• Suspect
• Inappropriate
• Suspect or Inappropriate
• Unscannable
• Clean
Configuring an Action Based on Image Analysis Verdicts
To configure an action based on image analysis verdicts:
Procedure
Step 1 Click Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 Enter a name for the content filter.
Step 4 Under Conditions, click Add Condition.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
231
Using Message Filters to Enforce Email Policies
Notifications
Step 5 Under Attachment File Info, click Image Analysis Verdict.
Step 6 Choose from one of the following verdicts:
• Suspect
• Inappropriate
• Suspect or Inappropriate
• Unscannable
• Clean
Step 7 Click Add Action.
Step 8 Select an action to perform on messages based on the image analysis verdict.
Step 9 Submit and commit your changes.
Notifications
Using the Text Resources page in the GUI or the textconfig CLI command to configure custom notification
templates as text resources is another useful tool when used in conjunction with attachment filtering rules.
The notification template supports non-ASCII characters (you are prompted to choose an encoding while
creating the template).
In the following example, the textconfig command was first used to create a notification template named
strip.mp3 that will be inserted into to the body of the notification message. Then, an attachment filtering rule
is created so that when an .mp3 file has been stripped from a message, a notification email is sent to the
intended recipients explaining that the .mp3 file has been deleted.
drop-mp3s:
if (attachment-type == '*/mp3')
{ drop-attachments-by-filetype('Media');
notify ('$EnvelopeRecipients', 'Your mp3 has been removed', '$EnvelopeFrom',
'strip.mp3');
For more information, see Notify and Notify-Copy Actions, on page 209.
Examples of Attachment Scanning Message Filters
The following examples shows actions performed on attachments:
• Inserting Headers, on page 233
• Dropping Attachments by File Type, on page 233
• Dropping Attachments by Dictionary Matches, on page 234
• Quarantining Protected Attachments, on page 235
• Detecting Unprotected Attachments, on page 235
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
232
Using Message Filters to Enforce Email Policies
Inserting Headers
Inserting Headers
In these examples, AsyncOS inserts headers when the attachments contain specified content.
In the following example, all of the attachments on the message are scanned for a keyword. If the keyword
is present in all of the attachments, a custom X-Header is inserted:
attach_disclaim:
if (every-attachment-contains('[dD]isclaimer') ) {
insert-header("X-Example-Approval", "AttachOK");
In the following example, the attachment is scanned for a pattern in the binary data. The filter uses the
attachment-binary-contains filter rule to search for a pattern that indicates that the PDF document is
encrypted. If the pattern is present in the binary data, a custom header is inserted:
match_PDF_Encrypt:
if (attachment-filetype == 'pdf' AND
attachment-binary-contains('/Encrypt')){
strip-header (‘Subject’);
insert-header (‘Subject’, ‘[Encrypted] $Subject’);
Dropping Attachments by File Type
In the following example, the “executable” group of attachments ( .exe , .dll , and .scr ) is stripped
from messages and text is added to the message, listing the filenames of the dropped files (using the
$dropped_filename action variable). Note that the drop-attachments-by-filetype action examines
attachments and strips them based on the fingerprint of the file, and not just the three-letter filename extension.
Note also that you can specify a single file type (“mpeg”) or you can refer to all of the members of the file
type (“Media”):
strip_all_exes: if (true) {
drop-attachments-by-filetype ('Executable', “Removed attachment:
$dropped_filename”);
In the following example, the same “executable” group of attachments ( .exe , .dll , and .scr ) are stripped
from messages whose Envelope Sender is not within the domain example.com .
strip_inbound_exes: if (mail-from != "@example\\.com$") {
drop-attachments-by-filetype ('Executable');
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
233
Using Message Filters to Enforce Email Policies
Dropping Attachments by Dictionary Matches
In the following example, a specific member of a file type (“wmf”) as well as a the same “executable” group
of attachments ( .exe , .dll , and .scr ) are stripped from messages whose Envelope Sender is not within
the domain example.com .
strip_inbound_exes_and_wmf: if (mail-from != "@example\\.com$") {
drop-attachments-by-filetype ('Executable');
drop-attachments-by-filetype ('x-wmf');
In the following example, the “executable” pre-defined group of attachments is extended to include more
attachment names. (Note that this action will not examine the attachments’ file type.)
strip_all_dangerous: if (true) {
drop-attachments-by-filetype ('Executable');
drop-attachments-by-name('(?i)\\.(cmd|pif|bat)$');
The drop-attachments-by-name action supports non-ASCII characters.
Note The drop-attachments-by-name action matches the regular expression against the filename captured from
the MIME header. The filename captured from the MIME header may contain trailing spaces.
In the following example, a message is dropped if the attachment is not an .exe executable file type. However,
the filter will not perform any action on the message if there is at least one attachment with the file type you
want to filter out. For example, the following filter drops any message with an attachment that is not an .exe
file type:
exe_check: if (attachment-filetype != "exe") {
drop();
If a message has multiple attachments, the email gateway does not drop the message if at least one of the
attachments is an .exe file, even if the other attachments not .exe files.
Dropping Attachments by Dictionary Matches
This drop-attachments-where-dictionary-match action strips attachments based on matches to dictionary
terms. If the terms in the MIME parts considered to be an attachment match a dictionary term (and the
user-defined threshold is met), the attachment is stripped from the email. The following example shows
attachment drops if words in the “secret_words” dictionary are detected in the attachment. Note that the
threshold for the matches is set to one:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
234
Using Message Filters to Enforce Email Policies
Quarantining Protected Attachments
Data_Loss_Prevention: if (true) {
drop-attachments-where-dictionary-match("secret_words", 1);
Quarantining Protected Attachments
The attachment-protected filter tests whether any attachment in the message is password protected. You
might use this filter on incoming mail to ensure that the attachments are scannable. According to this definition,
a zip file containing one encrypted member along with unencrypted members will be considered protected.
Similarly, PDF file that has no open password will not be considered protected, even though it may restrict
copying or printing with a password. The following example shows protected attachments sent to a policy
quarantine:
quarantine_protected:
if attachment-protected
quarantine("Policy");
Detecting Unprotected Attachments
The attachment-unprotected filter tests whether any attachment in the message is not password protected.
This message filter complements the attachment-protected filter. You might use this filter on outgoing mail
to detect outgoing mail that is unprotected. The following example shows AsyncOS detecting unprotected
attachments on an outgoing listener and quarantining the messages:
quarantine_unprotected:
if attachment-unprotected
quarantine("Policy");
Detecting Malicious Files in Messages Attachments Using
Message Filter
As an example, use the following message filter rule syntax to detect files in message attachments categorized
as malicious by the ETF engine, and take appropriate actions on such messages.
Syntax:
Strip_malicious_files: if (file-hash-etf-rule (['etf_source1'], <'file_hash_exception_list'>))
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
235
Using Message Filters to Enforce Email Policies
Using the CLI to Manage Message Filters
{ file-hash-etf-strip-attachment-action (['etf_source1'], <'file_hash_exception_list>,
"file stripped from message attachment"); }
Where:
• ‘file-hash-etf-rule' is the Attachment File Info message filter rule
• ‘etf_source1' is the ETF source(s) used to detect malicious files in the messages based on the file hash.
• 'file_hash_exception_list' is the name of a file hash exception list. If a file hash exception list is
not present, it is displayed as “”.
• 'file-hash-etf-strip-attachment-action' is the name of the action that you want to apply on
messages that contain malicious files.
In the following example, if a message contains a message attachment detected as malicious by the
ETF engine, the attachment is stripped.
Strip_Malicious_Attachment: if (true) {file-hash-etf-strip-attachment-action
(['threat_feed_source'], "", “Malicious message attachment has been stripped from
the message.");}
Using the CLI to Manage Message Filters
You can use the CLI to add, delete, activate and de-activate, import and export, and set logging options for
message filters. The table below shows a summary of the commands and subcommands. The table below
shows a summary of the commands and subcommands.
Table 28: Message Filters Subcommands
Syntax Description
filters The main command. This command is interactive; it asks you for more information (for
example, new , delete , import ).
new Creates a new filter. If no location is given, it is appended to the current sequence.
Otherwise, the filter will be inserted into the specific place in the sequence. For more
information, see Creating a New Message Filter, on page 238.
delete Deletes a filter by name or by sequence number. For more information, see Deleting a
Message Filter, on page 238.
move Rearranges the existing filters. For more information, see Creating a New Message Filter,
on page 238.
set Sets filter to active or inactive state. For more information, see Creating a New Message
Filter, on page 238.
import Replaces the current set of filters with a new set stored in a file (in the /configuration
directory of the email gateway). For more information, see Creating a New Message Filter,
on page 238.
export Exports the current set of filters to a file (in the /configuration directory of the email
gateway). For more information, see Exporting Message Filters, on page 242 .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
236
Using Message Filters to Enforce Email Policies
Using the CLI to Manage Message Filters
Syntax Description
list Lists information about a filter or filters. For more information, see Displaying a Message
Filter List, on page 242.
detail Prints detailed information about a specific filter, including the body of the filter rule itself.
For more information, see Displaying Message Filter Details, on page 243 .
logconfig Enters the logconfig submenu of filters, allowing you to edit the log subscriptions from
archive() filter actions. For more information, see Configuring Filter Log Subscriptions,
on page 243.
Note You must issue the commit command for filters to take effect.
Three types of parameters are:
Table 29: Filter Management Parameters
seqnum An integer representing a filter based on its position in the list of filters. A seqnum of
2 represents the second filter in the list, for example.
filtname The colloquial name of a filter.
range A range may be used to represent more than one filter, and appears in the form of X Y
, where X and Y are the first and last seqnums that identify the extent. For example,
2-4 represents filters in the second, third, and fourth positions. Either X or Y may be
left off to represent an open-ended list. For example, -4 represents the first four filters,
and 2- represents all filters except the first. You can also use the keyword all to represents
all the filters in the filter list.
Related Topics
• Creating a New Message Filter, on page 238
• Deleting a Message Filter, on page 238
• Moving a Message Filter, on page 238
• Activating and Deactivating a Message Filter, on page 238
• Importing Pre-Policy Filters, on page 241
• Exporting Message Filters, on page 242
• Viewing Non-ASCII Character Sets, on page 242
• Displaying a Message Filter List, on page 242
• Displaying Message Filter Details, on page 243
• Configuring Filter Log Subscriptions, on page 243
• Changing Message Encoding, on page 244
• Sample Message Filters, on page 246
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
237
Using Message Filters to Enforce Email Policies
Creating a New Message Filter
Creating a New Message Filter
new [seqnum|filtname|last]
Specifies the position at which to insert the new filter(s). If omitted, or given the keyword last , the filters
entered in are appended to the list of filters. No gaps in the sequence numbers are allowed; you are not allowed
to enter a seqnum outside the boundaries of the current list. If you enter an unknown filtname , you are prompted
to enter a valid filtname , seqnum , or last .
After a filter has been entered, you may manually enter the filter script. When you are finished typing, end
the entry by typing a period ( . ) on a line by itself.
The following conditions can cause errors:
• Sequence number beyond the current range of sequence numbers.
• Filter with a non-unique filtname .
• Filter with a filtname that is a reserved word.
• Filter with a syntax error.
• Filter with actions referring to non-existent system resources such as interfaces.
Deleting a Message Filter
delete [seqnum|filtname|range]
Deletes the filter(s) identified.
The following conditions can cause errors:
• No filter with a given filter name.
• No filter with a given sequence number.
Moving a Message Filter
move [seqnum|filtname|rangeseqnum|last]
Moves the filters identified by the first parameter to the position identified by the second parameter. If the
second parameter is the keyword last , the filters are moved to the end of the list of filters. If more than one
filter is being moved, their ordering remains the same in relation to one another.
The following conditions can cause errors:
• No filter with a given filter name.
• No filter with a given sequence number.
• Sequence number beyond the current range of sequence numbers.
• Movement would result in no change of sequence.
Activating and Deactivating a Message Filter
A given message filter is either active or inactive and it is also either valid or invalid . A message filter is only
used for processing if it is both active and valid . You change an existing filter from active to inactive (and
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
238
Using Message Filters to Enforce Email Policies
Activating and Deactivating a Message Filter
back again) using the CLI. A filter is invalid if it refers to a listener or interface which does not exist (or has
been removed).
Note You can determine if a filter is inactive by its syntax; AsyncOS changes the colon after the filter name to an
exclamation point for inactive filters. If you use this syntax when entering or importing a filter, AsyncOS
marks the filter as inactive.
For example, the following benign filter named “filterstatus” is entered. It is then made inactive using the
filter -> set subcommand. Note that when the details of the filter are shown, the colon has been changed
to an exclamation point (and is bold in the following example).
mail3.example.com> filters
Choose the operation you want to perform:
- NEW - Create a new filter.
- IMPORT - Import a filter script from a file.
[]> new
Enter filter script. Enter '.' on its own line to end.
filterstatus: if true{skip-filters();}
1 filters added.
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> list
Num Active Valid Name
1 Y Y filterstatus
Choose the operation you want to perform:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
239
Using Message Filters to Enforce Email Policies
Activating and Deactivating a Message Filter
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> set
Enter the filter name, number, or range:
[all]> all
Enter the attribute to set:
[active]> inactive
1 filters updated.
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> detail
Enter the filter name, number, or range:
[]> all
Num Active Valid Name
1 N Y filterstatus
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
240
Using Message Filters to Enforce Email Policies
Activating or Deactivating a Message Filter
filterstatus! if (true) {
skip-filters();
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]>
Related Topics
• Activating or Deactivating a Message Filter, on page 241
Activating or Deactivating a Message Filter
set [seqnum|filtname|range] active|inactive
Sets the filters identified to have the given state. Legal states are:
• active: Set the state of the selected filters to be active.
• inactive: Set the state of the selected filters to be inactive.
The following conditions can cause errors:
• No filter with a given filtname .
• No filter with a given sequence number.
Note A filter which is inactive may also be noted in its syntax; the colon after the label (name of the filter) is changed
to an exclamation point ( ! ). A filter entered manually from the CLI, or imported, that contains this syntax,
will automatically be marked inactive. For example, mailfrompm! instead of mailfrompm: is displayed.
Importing Pre-Policy Filters
import filename
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
241
Using Message Filters to Enforce Email Policies
Exporting Message Filters
The name of the file containing filters to be processed. This file must reside in the configuration directory of
the FTP/SCP root directory on the appliance, if you enabled FTP/SCP access for the interface with the
interfaceconfig command. It is ingested and parsed, and any errors are reported. The filters imported replace
all filters existing in the current filter set. See FTP, SSH, and SCP Access, on page 1297 for more information.
Consider exporting the current filter list (see Exporting Message Filters, on page 242) and then editing that
file before importing.
When importing message filters, you are prompted to select the encoding used.
The following conditions can cause errors:
• File does not exist.
• Filter with a non-unique filter name.
• Filter with a filtname that is a reserved word.
• Filter with a syntax error.
• Filter with actions referring to non-existent system resources such as interfaces.
Exporting Message Filters
export filename[seqnum|filtname|range]
Output a formatted version of the existing filter set to a file in the configuration directory of the FTP/SCP
root directory on the email gateway. See FTP, SSH, and SCP Access, on page 1297 for more information.
When exporting message filters, you are prompted to select the encoding used.
The following conditions can cause errors:
• No filter with a given filter name.
• No filter with a given sequence number.
Viewing Non-ASCII Character Sets
The system displays filters containing non-ASCII characters in the CLI in UTF-8. If your terminal/display
does not support UTF-8, the filter will unreadable.
The best way to manage non-ASCII characters in filters is to edit the filter in a text file and then import that
text file (see Importing Pre-Policy Filters, on page 241) into the email gateway.
Displaying a Message Filter List
list [seqnum|filtname|range]
Shows summarized information about the identified filters in a tabular form without printing the filter body.
The information displayed includes:
• Filter name
• Filter sequence number
• Filter's active/inactive state
• Filter’s valid/invalid state
The following conditions can cause errors:
• Illegal range format.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
242
Using Message Filters to Enforce Email Policies
Displaying Message Filter Details
Displaying Message Filter Details
detail [seqnum|filtname|range]
Provides full information about the identified filters, including the body of the filter and any additional state
information.
Configuring Filter Log Subscriptions
logconfig
Enters a submenu that allows you to configure the filter log options for the mailbox files generated by the
archive() action. These options are very similar to those used by the regular logconfig command, but the
logs may only be created or deleted by adding or removing filters that reference them.
Each filter log subscription has the following default values, which can be modified using the logconfig
subcommand:
• Retrieval method - FTP Poll
• File size - 10MB
• Max number of files - 10
For more information, see the “Logging” chapter.
mail3.example.com> filters
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> logconfig
Currently configured logs:
1. "joesmith" Type: "Filter Logs" Retrieval: FTP Poll
Choose the operation you want to perform:
- EDIT - Modify a log setting.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
243
Using Message Filters to Enforce Email Policies
Changing Message Encoding
[]> edit
Enter the number of the log you wish to edit.
[]> 1
Choose the method to retrieve the logs.
1. FTP Poll
2. FTP Push
3. SCP Push
[1]> 1
Please enter the filename for the log:
[joesmith.mbox]>
Please enter the maximum file size:
[10485760]>
Please enter the maximum number of files:
[10]>
Currently configured logs:
1. "joesmith" Type: "Filter Logs" Retrieval: FTP Poll
Enter "EDIT" to modify or press Enter to go back.
[]>
Changing Message Encoding
You can use the localeconfig command to set the behavior of AsyncOS regarding modifying the encoding
of message headings and footers during message processing:
example.com> localeconfig
Behavior when modifying headers: Use encoding of message body
Behavior for untagged non-ASCII headers: Impose encoding of message body
Behavior for mismatched footer or heading encoding: Try both body and footer or heading
encodings
Behavior when decoding errors found: Disclaimer is displayed as inline content and the
message body is added as an attachment.
Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
[]> setup
If a header is modified, encode the new header in the same encoding as the message body?
(Some MUAs incorrectly handle headers encoded in a different encoding than the body.
However, encoding a modified header in the same encoding as the message body may cause
certain
characters in the modified header to be lost.) [Y]>
If a non-ASCII header is not properly tagged with a character set and is being used or
modified,
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
244
Using Message Filters to Enforce Email Policies
Changing Message Encoding
impose the encoding of the body on the header during processing and final representation
of the message?
(Many MUAs create non-RFC-compliant headers that are then handled in an undefined way.
Some MUAs handle headers encoded in character sets that differ from that of the main body
in an incorrect way.
Imposing the encoding of the body on the header may encode the header more precisely.
This will be used to interpret the content of headers for processing, it will not modify
or rewrite the
header unless that is done explicitly as part of the processing.) [Y]>
Disclaimers (as either footers or headings) are added in-line with the message body whenever
possible.
However, if the disclaimer is encoded differently than the message body, and if imposing a
single encoding
will cause loss of characters, it will be added as an attachment. The system will always
try to use the
message body's encoding for the disclaimer. If that fails, the system can try to edit the
message body to
use an encoding that is compatible with the message body as well as the disclaimer. Should
the system try to
re-encode the message body in such a case? [Y]>
If the disclaimer that is added to the footer or header of the message generates an error
when decoding the message body,
it is added at the top of the message body. This prevents you to rewrite a new message
content that must merge with
the original message content and the header/footer-stamp. The disclaimer is now added as
an additional MIME part
that displays only the header disclaimer as an inline content, and the rest of the message
content is split into
separate email attachments. Should the system try to ignore such errors when decoding the
message body? [N]>
Behavior when modifying headers: Use encoding of message body
Behavior for untagged non-ASCII headers: Impose encoding of message body
Behavior for mismatched footer or heading encoding: Try both body and footer or heading
encodings
Behavior when decoding errors found: Disclaimer is displayed as inline content and the
message body
is added as an attachment.
Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
[]>
The first prompt determines whether or not a message header’s encoding should be changed to match that of
the message body if the header is changed (via a filter, for example).
The second prompt controls whether or not the email gateway should impose the encoding of the message
body on the header if the header is not properly tagged with a character set.
The third prompt is used to configure how disclaimer stamping (and multiple encodings) in the message body
works. Please see “Disclaimer Stamping and Multiple Encodings” in the “Text Resources” chapter for more
information.
The fourth prompt is used to configure the behaviour of disclaimer stamping, if an error is generated during
the decoding of the message body. If you select ‘Yes’, the decoding errors are ignored and the disclaimer is
stamped. If you select ‘No’, the disclaimer text is added as an attachment to the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
245
Using Message Filters to Enforce Email Policies
Sample Message Filters
Sample Message Filters
In the following example, the filter command is used to create three new filters:
• The first filter is named big_messages. It uses the body-size rule to drop messages larger than 10
megabytes.
• The second filter is named no_mp3s. It uses the attachment-filename rule to drop messages that contain
attachments with the filename extension of .mp3 .
• The third filter is named mailfrompm. It uses mail-from rule examines all mail from
[email protected] and blind-carbon copies [email protected] .
Using the filter -> list subcommand, the filters are listed to confirm that they are active and valid, and
then the first and last filters are switched in position using the move subcommand. Finally, the changes are
committed so that the filters take effect.
mail3.example.com> filters
Choose the operation you want to perform:
- NEW - Create a new filter.
- IMPORT - Import a filter script from a file.
[]> new
Enter filter script. Enter '.' on its own line to end.
big_messages:
if (body-size >= 10M) {
drop();
1 filters added.
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> new
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
246
Using Message Filters to Enforce Email Policies
Sample Message Filters
Enter filter script. Enter '.' on its own line to end.
no_mp3s:
if (attachment-filename == '(?i)\\.mp3$') {
drop();
1 filters added.
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> new
Enter filter script. Enter '.' on its own line to end.
mailfrompm:
if (mail-from == "^postmaster$")
{ bcc ("[email protected]");}
1 filters added.
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
247
Using Message Filters to Enforce Email Policies
Sample Message Filters
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> list
Num Active Valid Name
1 Y Y big_messages
2 Y Y no_mp3s
3 Y Y mailfrompm
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> move
Enter the filter name, number, or range to move:
[]> 1
Enter the target filter position number or name:
[]> last
1 filters moved.
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
248
Using Message Filters to Enforce Email Policies
Sample Message Filters
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> list
Num Active Valid Name
1 Y Y no_mp3s
2 Y Y mailfrompm
3 Y Y big_messages
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> move
Enter the filter name, number, or range to move:
[]> 2
Enter the target filter position number or name:
[]> 1
1 filters moved.
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
249
Using Message Filters to Enforce Email Policies
Sample Message Filters
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]> list
Num Active Valid Name
1 Y Y mailfrompm
2 Y Y no_mp3s
3 Y Y big_messages
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]>
mail3.example.com> commit
Please enter some comments describing your changes:
[]> entered and enabled 3 filters: no_mp3s, mailfrompm, big_messages
Do you want to save the current configuration for rollback? [Y]> n
Changes committed: Fri May 23 11:42:12 2014 GMT
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
250
Using Message Filters to Enforce Email Policies
Message Filter Examples
Message Filter Examples
This section contains some real world examples of filters with a brief discussion of each.
Related Topics
• Open-Relay Prevention Filter, on page 251
• Policy Enforcement Filters, on page 251
• Routing and Domain Spoofing, on page 255
• Drop Message Attachments that match File SHA-256 Filter, on page 258
• Drop Messages if Attachment matches File SHA-256 Filter, on page 258
Open-Relay Prevention Filter
This filter bounces messages with addresses using % , extra @ , and ! characters in email addresses:
• user%otherdomain@validdomain
• user@otherdomain@validdomain:
• domain!user@validdomain
sourceRouted:
if (rcpt-to == "(%|@|!)(.*)@") {
bounce();
The email gateways are not susceptible to these third party relay hacks that are often used to exploit traditional
Sendmail/Qmail systems. As many of these symbols (for example % ) can be part of a perfectly legal email
address, email gateways will accept these as valid addresses, verify them against the configured recipient lists,
and pass them on to the next internal server. The email gateways do not relay these messages to the world.
These filters are put in place to protect users who may have open-source MTAs that are misconfigured to
allow relay of these types of messages.
Note You can also configure a listener to handle these types of addresses. See Listening for Connection Requests
by Creating a Listener Using Web Interface, on page 83 for more information.
Policy Enforcement Filters
• Notify Based on Subject Filter, on page 252
• BCC and Scan Mail Sent to Competitors, on page 252
• Block Specific User Filter, on page 252
• Archive and Drop Messages Filter, on page 252
• Large “To:” Header Filter, on page 253
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
251
Using Message Filters to Enforce Email Policies
Notify Based on Subject Filter
• Blank “From:” Filter, on page 253
• IP Reputation Filter, on page 254
• Alter IP Reputation Filter, on page 254
• Filename Regex Filter, on page 254
• Show IP Reputation Score in Header Filter, on page 254
• Insert Policy into Header Filter, on page 254
• Too Many Recipients Bounce Filter, on page 255
Notify Based on Subject Filter
This filter sends notification based on whether the subject contains specific words:
search_for_sensitive_content:
if (Subject == "(?i)plaintiff|lawsuit|judge" ) {
notify ("[email protected]");
BCC and Scan Mail Sent to Competitors
This filter scans and blind copies messages that are sent to competitors. Note that you could use a dictionary
and the header-dictionary-match() rule to specify a more flexible list of competitors (see Dictionary Rules,
on page 176):
competitorFilter:
if (rcpt-to == '@competitor1.com|@competitor2.com') {
bcc-scan('[email protected]');
Block Specific User Filter
Use this filter to block email from a specific address:
block_harrasing_user:
if (mail-from == "ex-employee@hotmail\\.com") {
notify ("[email protected]");
drop ();
Archive and Drop Messages Filter
Log and drop only the messages that have matching filetypes:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
252
Using Message Filters to Enforce Email Policies
Large “To:” Header Filter
drop_attachments:
if (mail-from != "[email protected]") AND (attachment-filename ==
'(?i)\\.(asp|bas|bat|cmd|cpl|exe|hta|ins|isp|js)$')
archive("Drop_Attachments");
insert-header("X-Filter", "Dropped by: $FilterName MID: $MID");
drop-attachments-by-name("\\.(asp|bas|bat|cmd|cpl|exe|hta|ins|isp|js)$");
Large “To:” Header Filter
Find messages with very large “To” headers.
Use the archive() line for verification of proper action, with drop() enabled or disabled for extra safety:
toTooBig:
if(header('To') == "^.{500,}") {
archive('tooTooBigdropped');
drop();
Blank “From:” Filter
Identify blank “From” headers,
This filter can alleviate various forms of blank “from” addresses:
blank_mail_from_stop:
if (recv-listener == "InboundMail" AND header("From") == "^$|<\\s*>") {
drop ();
If you also want to drop messages with a blank envelope from, use this filter:
blank_mail_from_stop:
if (recv-listener == "InboundMail" AND (mail-from == "^$|<\\s*>" OR header ("From") ==
"^$|<\\s*>"))
drop ();
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
253
Using Message Filters to Enforce Email Policies
IP Reputation Filter
IP Reputation Filter
IP Reputation filter:
note_bad_reps:
if (reputation < -2) {
strip-header ('Subject');
insert-header ('Subject', '***BadRep $Reputation *** $Subject');
}
Alter IP Reputation Filter
Alter the IP Reputation Score threshold for certain domains:
mod_ipr:
if ( (rcpt-count == 1) AND (rcpt-to == "@domain\\.com$") AND (reputation < -2) ) {
drop ();
}
Filename Regex Filter
This filter specifies a range of size for the body of the message, and looks for an attachment that matches the
regular expression (this matches files named “readme.zip”, “readme.exe”, “attach.exe”, and so forth.):
filename_filter:
if ((body-size >= 9k) AND (body-size <= 20k)) {
if (body-contains ("(?i)(readme|attach|information)\\.(zip|exe)$")) {
drop ();
Show IP Reputation Score in Header Filter
Remember to log the headers (see the “Logging” chapter) so they appear in the mail log:
Check_ipr:
if (true) {
insert-header('X-ipr', '$Reputation');
Insert Policy into Header Filter
Show which mail flow policy accepted the connection:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
254
Using Message Filters to Enforce Email Policies
Too Many Recipients Bounce Filter
Policy_Tracker:
if (true) {
insert-header ('X-HAT', 'Sender Group $Group, Policy $Policy applied.');
Too Many Recipients Bounce Filter
Bounce all outbound email messages with more than 50 recipients from more than two unique domains:
bounce_high_rcpt_count:
if ( (rcpt-count > 49) AND (rcpt-to != "@example\\.com$") ) {
bounce-profile ("too_many_rcpt_bounce"); bounce ();
Routing and Domain Spoofing
• Using Virtual Gateways Filter, on page 255
• Same Listener for Deliver and Listener Filter, on page 255
• Single Listener Filter, on page 256
• Drop Spoofed Domain Filter (Single Listener), on page 256
• Drop Spoofed Domain Filter (Multiple Listeners), on page 256
• Another Drop Spoofed Domain Filter, on page 257
• Detect Looping Filter, on page 257
Using Virtual Gateways Filter
Segment traffic using virtual gateways. Assuming you have two Interfaces on the system, 'public1' and 'public2',
and the default delivery interface is 'public1'. This would force all of your outbound traffic over the second
interface; since bounces and other similar types of mail do not go through filters, they will be delivered from
public1:
virtual_gateways:
if (recv-listener == "OutboundMail") {
alt-src-host ("public2");
Same Listener for Deliver and Listener Filter
Use the same listener for delivery and receiving. This filter will allow you to send any messages received on
the public listener “listener1” out the interface “listener1” (you will have to set up a unique filter for each
public listener configured):
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
255
Using Message Filters to Enforce Email Policies
Single Listener Filter
same_listener:
if (recv-inj == 'listener1') {
alt-src-host('listener1');
Single Listener Filter
Make the filter work on a single listener. For example, specify a specific listener for message filter processing
instead of being performed system wide.
textfilter-new:
if (recv-inj == 'inbound' and body-contains("some spammy message")) {
alt-rcpt-to ("[email protected]");
Drop Spoofed Domain Filter (Single Listener)
Drop email with a spoofed domain (pretending to be from an internal address; works with a single listener).
IP addresses below represent fictional domain for mycompany.com :
DomainSpoofed:
if (mail-from == "mycompany\\.com$") {
if ((remote-ip != "1.2.") AND (remote-ip != "3.4.")) {
drop();
Drop Spoofed Domain Filter (Multiple Listeners)
As above, but works with multiple listeners:
domain_spoof:
if ((recv-listener == "Inbound") and (mail-from == "@mycompany\\.com")) {
archive('domain_spoof');
drop ();
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
256
Using Message Filters to Enforce Email Policies
Another Drop Spoofed Domain Filter
Another Drop Spoofed Domain Filter
Summary: Anti domain spoof filter:
reject_domain_spoof:
if (recv-listener == "MailListener") {
insert-header("X-Group", "$Group");
if ((mail-from == "@test\\.mycompany\\.com") AND (header("X-Group") != "RELAYLIST")) {
notify("[email protected]");
drop();
strip-header("X-Group");
Detect Looping Filter
This filter is used to detect, stop, and determine what is causing, a mail loop. This filter can help determine a
configuration issue on the Exchange server or elsewhere.
External_Loop_Count:
if (header("X-ExtLoop1")) {
if (header("X-ExtLoopCount2")) {
if (header("X-ExtLoopCount3")) {
if (header("X-ExtLoopCount4")) {
if (header("X-ExtLoopCount5")) {
if (header("X-ExtLoopCount6")) {
if (header("X-ExtLoopCount7")) {
if (header("X-ExtLoopCount8")) {
if (header("X-ExtLoopCount9")) {
notify ('[email protected]');
drop();
else {insert-header("X-ExtLoopCount9", "from
$RemoteIP");}}
else {insert-header("X-ExtLoopCount8", "from $RemoteIP");}}
else {insert-header("X-ExtLoopCount7", "from $RemoteIP");}}
else {insert-header("X-ExtLoopCount6", "from $RemoteIP");}}
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
257
Using Message Filters to Enforce Email Policies
Drop Message Attachments that match File SHA-256 Filter
else {insert-header("X-ExtLoopCount5", "from $RemoteIP");}}
else {insert-header("X-ExtLoopCount4", "from $RemoteIP");}}
else {insert-header("X-ExtLoopCount3", "from $RemoteIP");}}
else {insert-header("X-ExtLoopCount2", "from $RemoteIP");}}
else {insert-header("X-ExtLoop1", "1");
Note By default, AsyncOS automatically detects mail loops and will drop messages after 100 loops.
Drop Message Attachments that match File SHA-256 Filter
Use this filter to drop all message attachments in messages that match the specific file SHA-256 value in the
file hash list
File_Hash_Message_Filter: if (true)
{ drop-attachments-by-hash("SHA-256_hash_list"); }
Drop Messages if Attachment matches File SHA-256 Filter
Use this filter to drop all messages if the message attachments match the specific file SHA-256 value in the
file hash list.
File_Hash_Message_Filter: if (attachment-hashlist-match("SHA-256_hash_list"))
{ drop(); }
Configuring Scan Behavior
You can control the behavior of body and attachment scanning, such as the attachment types to be skipped
during a scan by configuring the scanning parameters. Use the Scan Behavior page or the scanconfig command
to configure these parameters. Scan behavior settings are global settings, meaning that they affect the behavior
of all the scans.
Note If you want to scan a MIME type that may be included in a zip or compressed file, you must include list
'compressed' or 'zip' or 'application/zip' in the scan list.
Procedure
Step 1 Click Security Services > Scan Behavior.
Step 2 Define the attachment type mapping. Do one of the following:
• Add a new attachment type mapping. Click Add Mapping.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
258
Using Message Filters to Enforce Email Policies
Configuring Scan Behavior
• Import a list of attachment type mappings using a configuration file. Click Import List, and import the
desired configuration file from the configuration directory.
Note To perform this step, the configuration file must be present in the configuration directory of
your email gateway. See Managing the Configuration File, on page 1017.
• Click Edit to modify an existing attachment type mapping.
Step 3 Configure the global settings. Do the following:
a) Under Global Settings, click Edit Global Settings.
b) Edit the required fields:
Field Description
Action for attachments with MIME types / Choose whether to scan or skip attachments types
fingerprints in table above defined in the attachment type mapping.
Maximum depth of attachment recursion to scan Specify the level up to which the recursive
attachments are to be scanned.
Maximum attachment size to scan Specify the maximum size of attachments to scan.
Attachment Metadata scan Specify whether to scan or skip metadata of the
attachments.
Attachment scanning timeout Specify the scanning time-out period.
Assume attachment matches pattern if not Specify whether to consider unscanned attachments
scanned for any reason as match to the search pattern.
Action when message cannot be deconstructed Specify the action to be taken when a message could
to remove specified attachments not be deconstructed to remove specified
attachments.
Bypass all filters in case of a content or message Specify whether to bypass all filters in case of a
filter error content or message filter error.
Encoding to use when none is specified Specify the encoding to be used if no encoding is
specified.
Convert opaque-signed messages to clear-signed Specify whether to convert opaque-signed messages
(S/MIME unpacking) to clear-signed (S/MIME unpacking).
Safe Print Settings
Maximum File Size Enter the maximum attachment size for a
safe-printed attachment.
Note If the ‘Maximum File Size’ value
exceeds the 'Maximum Message Size to
Scan' value configured for Outbreak
Filters on your email gateway, then the
message and the message attachment is
not scanned by Outbreak Filters in the
email pipeline.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
259
Using Message Filters to Enforce Email Policies
Configuring Scan Behavior
Field Description
Maximum Page Count Enter the maximum number of pages that you want
to safe print in a message attachment.
Document Quality Select the Use Default Value (70) option to use the
recommended image quality value for a safe-printed
attachment.
Note You can also select the Enter Custom
Value option and enter a custom image
quantity value for a safe-printed
attachment.
File Type Selection Select the required file types from the appropriate
file groups (for example, “Microsoft Documents”)
that you can use to safe print a message attachment.
Watermark Select Enabled option to add a watermark to a
safe-printed attachment.
Note You can enter a custom text for the
watermark in the Enter Custom Text:
field.
Cover Page Select Enabled option to add a cover page to a
safe-printed attachment.
Note You can enter a custom text for the cover
page in the Enter Custom Text field.
For more information, see How to Configure Email Gateway to Safe Print Message Attachments, on
page 348.
Scanning of Password-protected Attachments
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
260
Using Message Filters to Enforce Email Policies
Configuring Scan Behavior
Field Description
Enable Scanning of Password-Protected Select the Enabled option under Inbound Mail
Attachments: Traffic or Outbound Mail Traffic to allow the
Content Scanner in your email gateway to scan the
contents of password-protected attachments in
incoming or outgoing messages.
Note Suppose the DLP scanning engine is
enabled in your email gateway. In that
case, if the password extraction is
successful, the password-protected
attachment contents are scanned by the
DLP engine per the configured DLP
policies.
Important • Suppose the Content Scanner can
extract the password from the body
of the message and scan the
attachment contents successfully.
In that case, the password and
attachment is sent to Cisco AMP
Threat Grid, if configured in your
email gateway and the file is
recommended for file analysis.
• The Content Scanner extracts the
password from the body of the
message with the best effort. The
extracted password is not stored in
your email gateway after the
scanning is complete.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
261
Using Message Filters to Enforce Email Policies
Configuring Scan Behavior
Field Description
Probable Password for Analysis: Select the Enabled option to create a user-defined
passphrase to open password-protected attachments
in incoming or outgoing messages.
Click Add Row if you want to add more than one
user-defined passphrase.
Notes:
• You can create a user-defined passphrase up
to 128 characters only. .
• You can create up to a maximum of five
user-defined passphrases.
• You can change the priority of the user-defined
passphrase by entering the required
user-defined passphrase in the Password field
that corresponds to the required priority.
• [For Inbound Mail only] The passphrases
extracted from the message body take
precedence over the user-defined passphrases
used to open the password-protected
attachments for incoming messages.
• [For Outbound Mail only] The user-defined
passphrases take precedence over the
passphrases extracted from the message body
used to open the password-protected
attachments for outgoing messages.
Actions for Unscannable Messages due to Specify the actions to take when a message cannot
decoding errors found during URL Filtering be scanned by the Content Scanner due to decoding
Actions errors found during URL filtering actions.
Action for unscannable messages due to Specify the actions to take when a message cannot
extraction failures be scanned by the Content Scanner because of an
attachment extraction failure.
Action for unscannable messages due to RFC Specify the actions to take when a message cannot
violations be scanned by the Content Scanner because of an
RFC violation.
c) Click Submit.
Step 4 (Optional) Manually update the Content Scanner files. Under Current Content Scanner files, click Update
Now.
Usually, these files are automatically updated using update server.
Note You can also use the contentscannerupdate in CLI to manually update these files.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
262
Using Message Filters to Enforce Email Policies
Configuring Message Handling Actions for Unscannable Messages
Step 5 Commit the changes.
Configuring Message Handling Actions for Unscannable Messages
The Content Scanner in your email gateway can now handle messages that are not scanned due to the following
reasons:
• File extraction failure
• RFC violation
• Decoding errors found during URL Filtering actions
You can configure any one of the following message handling actions on messages that are not scanned by
the Content Scanner:
• Drop the message
• Deliver the message as it is
• Send the message to the policy quarantine
You can click on the Edit Global Settings button in the Security Services > Scan Behavior page of the web
interface, to enable and configure message handling actions on messages that are not scanned by the Content
Scanner.
Delivering the Message
You can perform the following additional actions, if you choose to deliver the message:
• Modify the message subject
• Add a custom header to the message
• Modify the message recipient
• Send message to alternate destination host
Note These actions are not mutually exclusive; you can combine some or all of them differently within different
incoming or outgoing policies for different processing needs for groups of users.
Modifying Message Subject
You can alter the text of messages that are not scanned by the Content Scanner by prepending or appending
certain text strings to help users easily identify and sort identified messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
263
Using Message Filters to Enforce Email Policies
Sending Message to Policy Quarantine
Note White space is not ignored in the “Modify message subject” field. Add spaces after (if prepending) or before
(if appending) the text you enter in this field to separate your added text from the original subject of the
message. For example, add the text [WARNING: UNSCANNABLE EXTRACTION FAILURE] with a few trailing spaces
if you are prepending.
The default text that is added to the subject of the message that is not scanned by the Content Scanner:
Reason Default Text Added to Subject
Extraction failure [WARNING: UNSCANNABLE EXTRACTION FAILED]
RFC Violation [WARNING: UNSCANNABLE RFC NON-COMPLIANT]
Decoding errors found during URL [WARNING: DECODING ERRORS WHEN APPLYING URL
Filtering actions FILTERING ACTIONS]
Adding Custom Header to Message
You can define an additional, custom header to add to all messages that are not scanned by the Content Scanner.
Click Yes and define the header name and text.
Modifying Message Recipient
You can modify the message recipient, causing the message that is not scanned by the Content Scanner to be
delivered to a different address. Click Yes and enter the new recipient address.
Sending Message to Alternate Destination Host
You can choose to send the notification to a different recipient or destination host for messages that are not
scanned by the Content Scanner. Click Yes and enter an alternate address or host.
For example, you can route messages that are not scanned by the Content Scanner to an administrator’s
mailbox or a special mail server for subsequent examination. In the case of a multi-recipient message, only a
single copy is sent to the alternative recipient.
Sending Message to Policy Quarantine
When flagged for quarantine, the message that is not scanned by the Content Scanner continues through the
rest of the email pipeline. When the message reaches the end of the pipeline, if the message has been flagged
for one or more quarantines then it enters those queues. Note that if the message does not reach the end of the
pipeline, it is not placed in a quarantine.
For example, a content filter can cause a message to be dropped or bounced, in which case the message will
not be quarantined.
Note If a policy quarantine is not defined in your email gateway, you cannot sent the message to the quarantine.
You can perform the following additional actions, if you choose to send the message to the policy quarantine:
• Modify the message subject
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
264
Using Message Filters to Enforce Email Policies
Sending Message to Policy Quarantine
• Add a custom header to the message
Modifying Message Subject Header
You can alter the text of messages that are sent to the policy quarantine by prepending or appending certain
text strings to help users easily identify and sort identified messages.
Note White space is not ignored in the “Modify message subject” field. Add spaces after (if prepending) or before
(if appending) the text you enter in this field to separate your added text from the original subject of the
message. For example, add the text [WARNING: UNSCANNABLE EXTRACTION FAILURE] with a few trailing spaces
if you are prepending.
The default text that is added to the subject of the message that is sent to the policy quarantine:
Reason Default Text Added to Subject
Extraction failure [WARNING: UNSCANNABLE EXTRACTION FAILED]
RFC Violation [WARNING: UNSCANNABLE RFC NON-COMPLIANT]
Decoding errors found during URL [WARNING: DECODING ERRORS WHEN APPLYING URL
Filtering actions FILTERING ACTIONS]
Adding Custom Header to Message
You can define an additional, custom header to add to all messages that are sent to the policy quarantine.
Click Yes and define the header name and text.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
265
Using Message Filters to Enforce Email Policies
Sending Message to Policy Quarantine
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
266
CHAPTER 10
Mail Policies
This chapter contains the following sections:
• Overview of Mail Policies, on page 267
• How to Enforce Mail Policies on a Per-User Basis, on page 268
• Handling Incoming and Outgoing Messages Differently, on page 269
• Matching Users to a Mail Policy, on page 269
• Message Splintering, on page 271
• Configuring Mail Policies, on page 273
• Setting Priority for Message Headers, on page 278
Overview of Mail Policies
The email gateway enforces your organization’s policies for messages sent to and from your users through
the use of mail policies. These are sets of rules that specify the types of suspect, sensitive, or malicious content
that your organization may not want entering or leaving your network. This content may include:
• spam
• legitimate marketing messages
• graymail
• viruses
• phishing and other targeted mail attacks
• confidential corporate data
• personally identifiable information
You can create multiple policies that satisfy the disparate security needs of the different user groups within
your organization. The email gateway uses the rules defined in these policies to scan each message and, if
necessary, perform an action to protect your user. For example, policies can prevent the delivery of suspected
spam messages to executives while allowing their delivery to IT staff but with a modified subject to warn
them of the content, or drop dangerous executable attachments for all users except those in the System
Administrator group.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
267
Mail Policies
How to Enforce Mail Policies on a Per-User Basis
How to Enforce Mail Policies on a Per-User Basis
Procedure
Command or Action Purpose
Step 1 Enable the content-scanning features that you The features you can enable and configure one
want the email gateway to use for incoming or or more of the following:
outgoing messages.
• Anti-Virus, on page 365
• File Reputation Filtering and File Analysis,
on page 481 (incoming messages only)
• Managing Spam and Graymail, on page
383
• Graymail Detection and Safe Unsubscribe.
See Managing Spam and Graymail, on
page 383.
• Outbreak Filters, on page 425
• Data Loss Prevention, on page 509
(outgoing messages only)
• Content Filters, on page 281
Step 2 (Optional) Create content filters for actions to See Content Filters, on page 281
take on messages that contain specific data.
Step 3 (Optional) Define an LDAP group query in See Using Group LDAP Queries to Determine
order to specify users to whom the mail policy if a Recipient is a Group Member, on page 796.
rules apply.
Step 4 (Optional) Define the default mail policies for See Configuring the Default Mail Policy for
incoming or outgoing messages. Incoming or Outgoing Messages , on page 273.
Step 5 Define the group of users for whom you want Create an incoming or outgoing mail policy.
to set up user-specific mail policies.
See Configuring Mail Policies, on page 273 for
more information.
Step 6 Configure the content security features and the Configure the different content security features
content filter actions the email gateway takes for the mail policy.
on messages.
• Content Filters: Applying the Content
Filter to Messages for a Certain User
Group, on page 301
• Anti-Virus: Configuring Virus Scanning
Actions for Users, on page 371
• File Reputation Filtering and File Analysis:
File Reputation Filtering and File Analysis,
on page 481
• Anti-Spam: Defining Anti-Spam Policies
, on page 399
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
268
Mail Policies
Handling Incoming and Outgoing Messages Differently
Command or Action Purpose
• Graymail Detection and Safe Unsubscribe:
Configuring the Incoming Mail Policy for
Graymail Detection and Safe
Unsubscribing, on page 394
• Outbreak Filters: The Outbreak Filters
Feature and the Outbreak Quarantine, on
page 443
• Data Loss Prevention: Using Outgoing
Mail Policies to Assign DLP Policies to
Senders and Recipients , on page 529.
Handling Incoming and Outgoing Messages Differently
The email gateway uses two different sets of mail policies for message content security:
• Incoming mail policies for messages are messages received from connections that match an ACCEPT
HAT policy in any listener.
• Outgoing mail policies for messages are messages from connections that match a RELAY HAT policy
in any listener. This includes any connection that was authenticated with SMTP AUTH.
Having separate sets of policies allow you to define different security rules for messages sent to your users
and messages sent from your users. You manage these policies using the Mail Policies > Incoming Mail
Policies or Outgoing Mail Policies pages in the GUI, or the policyconfig command in the CLI.
Note Some features can be applied only to incoming or to outgoing mail policies. For example, Data Loss Prevention
scanning can only be performed on outgoing messages. Advanced Malware Protection (File Reputation
scanning and File Analysis) is available in Incoming Mail Policies and Outgoing Mail Policies.
In certain installations, “internal” mail being routed through the Cisco appliance may be considered outgoing
, even if all the recipients are addressed to internal addresses. For example, by default for C170 and C190
appliances, the system setup wizard will configure only one physical Ethernet port with one listener for
receiving inbound email and relaying outbound email.
Matching Users to a Mail Policy
As messages are received by the email gateway, the email gateway attempts to match each message recipient
and sender to a mail policy in the Incoming or Outgoing Mail Policies table, depending on whether it is an
incoming or outgoing message.
Matches are based on the recipient’s address, the sender’s address, or both:
• Recipient address matches the Envelope Recipient address
When matching recipient addresses, the recipient addresses entered are the final addresses after processing
by preceding parts of the email pipeline. For example, if enabled, the default domain, LDAP routing or
masquerading, alias table, domain map, and message filters features can rewrite the Envelope Recipient
address and may affect whether the message matches a mail policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
269
Mail Policies
First Match Wins
• Sender address matches:
• Envelope Sender (RFC821 MAIL FROM address)
• Address found in the RFC822 From: header
• Address found in the RFC822 Reply-To: header
Addresses may be matched on either a full email address, user, domain, or partial domain, and addresses may
also match LDAP group membership.
Related Topics
• First Match Wins, on page 270
• Examples of Policy Matching, on page 270
First Match Wins
Each user (sender or recipient) is evaluated for each mail policy defined the appropriate mail policy table in
a top-down fashion.
For each user, the first matching policy wins. If a user does not match any specific policy, user will automatically
match the default policy of the table.
If a match is made based on a sender address, all remaining recipients of a message will match that policy.
(This is because there can be only one sender per message.)
The envelope sender and the envelope recipeint have a higher priority over the sender header when you match
a message to a mail policy. If you configure a mail policy to match a specific user, the messages are
automatically classified into the mail policy based on the envelope sender and the envelope recipient.
Examples of Policy Matching
The following examples help show how the policy tables are matched in a top-down fashion.
Given the following Incoming Mail Email Security Policy table shown in the following table, incoming
messages will match different policies.
Table 30: Policy Matching Example
Order Policy Name Users
Sender Recipient
1 special_people ANY [email protected]
[email protected]
2 from_lawyers @lawfirm.com ANY
3 acquired_domains ANY @newdomain.com
@anotherexample.com
4 engineering ANY PublicLDAP.ldapgroup:
engineers
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
270
Mail Policies
Example 1
Order Policy Name Users
5 sales_team ANY jim@john@larry@
6 Default Policy ANY ANY
Related Topics
• Example 1, on page 271
• Example 2, on page 271
• Example 3, on page 271
Example 1
A message from sender [email protected] sent to recipient [email protected] matches:
• Policy #2 when the user description matches the sender ( @lawfirm.com ) and the recipient ( ANY ).
• Policy #2 when the envelope sender is [email protected].
• Policy #5 when the header sender is [email protected] but the enveloper sender does not match
@lawfirm.com.
Example 2
Sender [email protected] sends an incoming message with three recipients: [email protected],
[email protected], and [email protected] :
• The message for recipient [email protected] will receive the anti-spam, anti-virus, outbreak filters,
and content filters defined in policy #3.
• The message for recipient [email protected] will receive the settings defined in policy #5.
• Because the recipient [email protected] does not match the engineering LDAP query, the message will
receive the settings defined by the default policy.
This example shows how messages with multiple recipients can incur message splintering . See Message
Splintering, on page 271 for more information.
Example 3
Sender [email protected] ([email protected] is used for envelope sender) sends a message to recipients
[email protected] and [email protected] :
• The recipient [email protected] will receive the anti-spam, anti-virus, outbreak filters, and content filters
defined in policy #1.
• The recipient [email protected] will receive the anti-spam, anti-virus, outbreak filters, and content
filters defined in policy #2, because the sender ( @lawfirm.com ) and the recipient ( ANY ) matches.
Message Splintering
Intelligent message splintering is the mechanism that allows for differing recipient-based content security
rules to be applied independently to message with multiple recipients.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
271
Mail Policies
Message Splintering
Each recipient is evaluated for each policy in the appropriate mail policy table (Incoming or Outgoing) in a
top-down fashion.
Each policy that matches a message creates a new message with those recipients. This process is defined as
message splintering :
• If some recipients match different policies, the recipients are grouped according to the policies they
matched, the message is split into a number of messages equal to the number of policies that matched,
and the recipients are set to each appropriate “splinter.”
• If all recipients match the same policy, the message is not splintered. Conversely, a maximum splintering
scenario would be one in which a single message is splintered for each message recipient.
• Each message splinter is then processed by anti-spam, anti-virus, Advanced Malware Protection (incoming
messages only), DLP scanning (outgoing messages only), Outbreak Filters, and content filters
independently in the email pipeline.
The following table illustrates the point at which messages are splintered in the email pipeline.
Work Message Filters Email Security ↓ Message for all recipients
Queue Manager
(filters)
Scanning (Per
Anti-Spam Recipient) Messages are splintered immediately after
message filter processing but before
(antispamconfig,
anti-spam processing:
antispamupdate)
Message for all recipients matching policy
Anti-Virus 1
(antivirusconfig, Message for all recipients matching policy
antivirusupdate) 2
File Reputation and Analysis Message for all other recipients (matching
(Advanced Malware Protection) the default policy)
(ampconfig) Note DLP scanning is only
performed on outgoing
Graymail Management messages.
Content Filters
(policyconfig -> filters)
Outbreak Filters
(outbreakconfig,
outbreakflush, outbreakstatus,
outbreakupdate)
Data Loss Prevention
(policyconfig)
Note New MIDs (message IDs) are created for each message splinter (for example, MID 1 becomes MID 2 and
MID 3). For more information, see the “Logging” chapter. In addition, the trace function shows which policies
cause a message to be split.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
272
Mail Policies
Managed Exceptions
Policy matching and message splintering in Email Security Manager policies obviously affect how you manage
the message processing available on the email gateway.
Related Topics
• Managed Exceptions, on page 273
Managed Exceptions
Because the iterative processing of each splinter message impacts performance, Cisco recommends configuring
your content security rules on a managed exception basis. In other words, evaluate your organization’s needs
and try to configure the feature so that the majority of messages will be handled by the default mail policy
and the minority of messages will be handled by a few additional “exception” policies. In this manner, message
splintering will be minimized and you are less likely to impact system performance from the processing of
each splinter message in the work queue.
Configuring Mail Policies
Mail policies map different user groups to specific security settings, such as Anti-Spam or Anti-Virus.
Related Topics
• Configuring the Default Mail Policy for Incoming or Outgoing Messages , on page 273
• Creating a Mail Policy for a Group of Senders and Recipients, on page 274
• Finding Which Policies Apply to a Sender or Recipient, on page 277
Configuring the Default Mail Policy for Incoming or Outgoing Messages
The default mail policies apply to messages that are not covered by any other mail policy. If no other policies
are configured, the default policies apply to all messages.
Before You Begin
Understand how you can define the individual security services for the mail policy. See How to Enforce Mail
Policies on a Per-User Basis, on page 268.
Procedure
Step 1 Depending on your requirements, choose one of the following:
• Mail Policies > Incoming Mail Policies
• Mail Policies > Outgoing Mail Policies.
Step 2 Click the link for the security service you want to configure for the Default mail policy.
Note For default security service settings, the first setting on the page defines whether the service is
enabled for the policy. You can click “Disable” to disable the service altogether.
Step 3 Configure the settings for the security service.
Step 4 Click Submit.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
273
Mail Policies
Creating a Mail Policy for a Group of Senders and Recipients
Step 5 Submit and commit your changes.
Creating a Mail Policy for a Group of Senders and Recipients
Before You Begin
• Understand how you can define the individual security services for the mail policy. See How to Enforce
Mail Policies on a Per-User Basis, on page 268.
• Remember that each recipient is evaluated for each policy in the appropriate table (incoming or outgoing)
in a top-down fashion. See First Match Wins, on page 270 for more information.
• (Optional) Define the delegated administrators who will be responsible for managing the mail policy.
Delegated administrators can edit a policy’s Anti-Spam, Anti-Virus, Advanced Malware Protection, and
Outbreak Filters settings and enable or disable content filters for the policy. Only operators and
administrators can modify a mail policy’s name or its senders, recipients, or groups. Custom user roles
that have full access to mail policies are automatically assigned to mail policies.
Procedure
Step 1 Choose Mail Policies > Incoming Mail Policies or Mail Policies > Outgoing Mail Policies.
Step 2 Click Add Policy.
Step 3 Enter a name for the mail policy.
Step 4 (Optional) Click the Editable by (Roles) link and select the custom user roles for the delegated administrators
who will be responsible for managing the mail policy.
Step 5 Define users for the policy. For instructions to define users, see Defining Senders and Recipients for Mail
Policies, on page 274.
Step 6 Click Submit.
Step 7 Click the link for the content security service you want to configure for the mail policy.
Step 8 From the drop-down list, select the option to customize the settings for the policy instead of using the default
settings.
Step 9 Customize the security service settings.
Step 10 Submit and commit your changes.
What to do next
Related Topics
• Defining Senders and Recipients for Mail Policies, on page 274
• How to Configure the Email Gateway to Scan Messages for Spam, on page 384
Defining Senders and Recipients for Mail Policies
You can define senders and recipients to whom the policy applies in the following ways:
• Full email address: [email protected]
• Partial email address: user@
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
274
Mail Policies
Defining Senders and Recipients for Mail Policies
• All users in a domain: @example.com
• All users in a partial domain: @.example.com
• By matching an LDAP Query
Note Entries for users are case-insensitive in both the GUI and CLI in AsyncOS. For example, if you enter the
recipient Joe@ for a user, a message sent to [email protected] will match.
While defining senders and recipients for mail policies, keep in mind that:
• You must specify at least one sender and recipient.
• You can set the policy to match if,
• The message is from any sender, one or more of the specified senders, or none of the specified
senders.
• The message is sent to any recipient, one or more of the specified recipients, or all of the specified
recipients and none of the specified recipients.
Procedure
Step 1 Under Users section, click Add User.
Step 2 Define the senders for the policy. Choose one of the following options:
• Any Sender. The policy is matched if the message is from any sender.
• Following Senders. The policy is matched if the message is from one or more of the specified senders.
Select this option and enter sender details in the text box or choose an LDAP group query.
• Following Senders are Not. The policy is matched if the message is not from none of the specified
senders. Select this option and enter sender details in the text box or choose an LDAP group query.
To understand how sender conditions are set while choosing the above fields, see Examples, on page 276.
Step 3 Define the recipients for the policy. Choose one of the following options:
• Any Recipient. The policy is matched if the message is sent to any recipient.
• Following Recipients. The policy is matched if the message is sent to the specified recipients. Select
this option, enter the recipient details in the text box or choose an LDAP group query.
You can choose whether policy is matched if the message is sent to one or more of the specified recipients or
all of the specified recipients. Choose one of the following options from the drop-down list: If one more
conditions match or Only if all conditions match.
• Following Recipients are Not. The policy is matched if the message is sent to none of the specified
recipients. Select this option, enter the recipient details in the text box or choose an LDAP group query.
Note You can configure this option only if you have selected Following Recipients and chosen Only if
all conditions match from the drop-down list.
To understand how recipient conditions are set while choosing the above fields, see Examples, on page 276.
Step 4 Click Submit.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
275
Mail Policies
Examples
Step 5 Review the selected conditions on the Users section.
What to do next
Related Topics
• Creating a Mail Policy for a Group of Senders and Recipients, on page 274
• Examples, on page 276
Examples
The following table describes how conditions are set when you choose various options on the Add User page.
Sender Recipient Condition
Any Following Following Any Following Following
Sender Senders Senders Recipient Recipients Recipients are
are Not Not
Selected - - - Selected - Sender: Any
(Default) Only Recipient:
if all
user1@[AND]user2@
conditions
match option is
selected
Values:
user1@,
user2@
- Selected - - Selected Selected Sender:
Values: (Default) Only Values: [email protected][OR][email protected]
if all
[email protected], [email protected], Recipient:
conditions
[email protected] match option is [email protected] [[email protected][AND][email protected]]
selected
[AND]
Values:
[[NOT]
[email protected], [[email protected][AND][email protected]]]
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
276
Mail Policies
Finding Which Policies Apply to a Sender or Recipient
- - Selected - Selected - Sender:
Values: If one or more [NOT]
conditions [[email protected][OR][email protected]]
[email protected],
match option is
Recipient:
[email protected] also selected
[email protected] [OR] [email protected]
Values:
[email protected],
Related Topics
• Defining Senders and Recipients for Mail Policies, on page 274
Finding Which Policies Apply to a Sender or Recipient
Use the Find Policies section at the top of the Mail Policies page to search for users already defined in incoming
or outgoing mail policies.
For example, type [email protected] and click the Find Policies button to display results showing which
policies contain defined users that will match the policy.
Click the name of the policy to edit the users for that policy.
Note that the default policy will always be shown when you search for any user, because, by definition, if a
sender or recipient does not match any other configured policies, it will always match the default policy.
Related Topics
• Managed Exceptions, on page 273
Managed Exceptions
Using the steps shown in the two examples above, you can begin to create and configure policies on a managed
exception basis. In other words, after evaluating your organization’s needs you can configure policies so that
the majority of messages will be handled by the default policy. You can then create additional “exception”
policies for specific users or user groups, managing the differing policies as needed. In this manner, message
splintering will be minimized and you are less likely to impact system performance from the processing of
each splinter message in the work queue.
You can define policies based on your organizations’ or users’ tolerance for spam, viruses, and policy
enforcement. The following table outlines several example policies. “Aggressive” policies are designed to
minimize the amount of spam and viruses that reach end-users mailboxes. “Conservative” policies are tailored
to avoid false positives and prevent users from missing messages, regardless of policies.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
277
Mail Policies
Setting Priority for Message Headers
Table 31: Aggressive and Conservative Email Security Manager Settings
Aggressive Settings Conservative Settings
Anti-Spam Positively identified spam: Drop Positively identified spam: Quarantine
Suspected spam: Quarantine Suspected spam: Deliver and prepend “ [Suspected
Spam] ” to the subject of messages
Marketing mail: Deliver and prepend “
[Marketing] ” to the subject messages Marketing mail: Disabled
Anti-Virus Repaired messages: Deliver Repaired messages: Deliver
Encrypted messages: Drop Encrypted messages: Quarantine
Unscannable messages: Drop Unscannable messages: Quarantine
Infectious messages: Drop Infectious messages: Drop
Advanced Malware Unscanned attachments: Drop Unscanned attachments: Deliver and prepend “
Protection [WARNING: ATTACHMENT UNSCANNED] ” to the subject of
Messages with Malware Attachments: Drop
messages.
(File Reputation
Messages with pending File Analysis: Quarantine
Filtering and File Messages with Malware Attachments: Drop
Analysis)
Messages with pending File Analysis: Deliver and
prepend “ [WARNING: ATTACHMENT(S) MAY CONTAIN
MALWARE] ” to the subject of messages.
Virus Filters Enabled, no specific filename extensions or domains Enabled with specific filename extensions or domains
allowed to bypass allowed to bypass
Enable message modification for all messages Enable message modification for unsigned messages
Setting Priority for Message Headers
You can set the priority for a message header to match the incoming and outgoing messages in your email
gateway.
Important You can set the priority in which the email gateway checks for message headers in the incoming and outgoing
messages. The email gateway first checks for the message header with the highest priority for all the mail
policies. If there is no header match in any of the mail policies, the email gateway looks for the next message
header in the priority list for all the mail policies. If none of the message headers match in any of the mail
policies, the default mail policy settings are used.
Procedure
Step 1 Go to Mail Policies > Mail Policy Settings.
By default, the Envelope Sender header is set to a priority 1. You can click on the Envelope Sender link to
change the priority.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
278
Mail Policies
Setting Priority for Message Headers
Step 2 Click Add Priority and check the appropriate header name (for example, Header “From’”) check box to add
a new priority.
Step 3 Click Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
279
Mail Policies
Setting Priority for Message Headers
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
280
CHAPTER 11
Content Filters
This chapter contains the following sections:
• Overview of Content Filters , on page 281
• How Content Filters Work, on page 281
• Content Filter Conditions, on page 282
• Content Filter Actions, on page 290
• How to Filter Messages Based on Content, on page 299
Overview of Content Filters
Use content filters to customize handling of messages beyond the standard routine handling by the other
content security features such as anti-virus scanning or DLP. For example, you can use a content filter if the
content warrants quarantining for later examination, or because corporate policy requires certain messages to
be encrypted before delivery.
How Content Filters Work
Content filters are similar to message filters, except that they are applied later in the email pipeline — after
message filtering, after a message has been “splintered” into a number of separate messages for each matching
mail policy, (see Message Splintering, on page 271 for more information), and after the message has undergone
anti-spam and anti-virus scanning.
A content filter scans either incoming or outgoing messages. You cannot define a filter that scans both types
of messages. The email gateway has a separate “primary list” of content filters for each type of message. The
primary list also determines in which order the appliance runs the content filters. However, each individual
mail policy determines which particular filters will be executed when a message matches the policy.
Content filters scan messages on a per-user (sender or recipient) basis.
Content filters have the following components:
• conditions that determine when the email gateway uses a content filter to scan a message (optional)
• actions that the email gateway takes on a message (required)
• action variables that the email gateway can add to a message when modifying it (optional)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
281
Content Filters
How to Scan Message Content Using a Content Filter
Related Topics
• How to Scan Message Content Using a Content Filter, on page 282
• Content Filter Conditions, on page 282
• Content Filter Actions, on page 290
• Action Variables, on page 297
How to Scan Message Content Using a Content Filter
Procedure
Command or Action Purpose
Step 1 (Optional) Define the supporting features for Create any of the following items that you want
the content filter. to use with your content filter:
• Encryption Profile
• Disclaimer template
• Notification template
• Policy quarantine
• URL allowed lists
Step 2 Define the incoming or outgoing content filter. A content filter may be comprised of:
• Content Filter Conditions, on page 282
(optional)
• Content Filter Actions, on page 290
• Action Variables, on page 297 (optional)
Creating a Content Filter, on page 299
Step 3 Define the group of users for whom you want Create an incoming or outgoing mail policy.
to set up content security rules.
Step 4 Assign the content filter to the group of user See Mail Policies, on page 267
whose incoming or outgoing messages you want
to use the filter for.
Content Filter Conditions
A condition is a “trigger” that determines whether the email gateway uses the filter on a message that matches
the associated mail policy. Specifying conditions for a content filter is optional. Content filters without a
condition are applied to all messages that match the associated mail policy.
In the content filter conditions, when you add filter rules that search for certain patterns in the message body
or attachments, you can specify the minimum threshold for the number of times the pattern must be found.
When AsyncOS scans the message, it totals the “score” for the number of matches it finds in the message and
attachments. If the minimum threshold is not met, the regular expression does not evaluate to true. You can
specify this threshold for text, smart identifiers, or content dictionary terms.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
282
Content Filters
Content Filter Conditions
Multiple conditions may be defined for each filter. When multiple conditions are defined, you can choose
whether the conditions are tied together as a logical OR (“Any of the following conditions...”) or a logical
AND (“All of the following conditions”).
Table 32: Content Filter Conditions
Condition Description
(no conditions) Specifying conditions in content filters is optional. If no conditions are specified,
a true rule is implied. The true rule matches all messages, and the actions are
always performed.
Message Body or Contains text: Does the message body contain text or an attachment that matches
Attachments a specific pattern?
Contains smart identifier: Does content in the message body or attachment match
a smart identifier?
Contains term in content dictionary: Does the message body contain any of the
regular expressions or terms in the content dictionary named <dictionary name>
?
For this option to be enabled, the dictionary must already have been created. See
Content Dictionaries, on page 643.
Note The dictionary-related conditions are only available if you have one or
more dictionaries enabled. For information about creating content
dictionaries, see Content Dictionaries, on page 643.
Number of matches required. Specify the number of matches required for the
rule to evaluate to true. You can specify this threshold for text, smart identifiers,
or content dictionary terms.
This includes delivery-status parts and associated attachments.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
283
Content Filters
Content Filter Conditions
Condition Description
Message Body Contains text: Does the message body contain text that matches a specific pattern?
Contains smart identifier: Does content in the message body match a smart
identifier? Smart identifiers can detect the following patterns:
• Credit card numbers
• U.S. Social Security numbers
• CUSIP (Committee on Uniform Security Identification Procedures) numbers
• ABA (American Banking Association) routing numbers
Contains term in content dictionary: Does the message body contain any of the
regular expressions or terms in the content dictionary named <dictionary name>
?
For this option to be enabled, the dictionary must already have been created. See
Content Dictionaries, on page 643.
Note The dictionary-related conditions are only available if you have one or
more dictionaries enabled. For information about creating content
dictionaries, see Content Dictionaries, on page 643.
Number of matches required. Specify the number of matches required for the
rule to evaluate to true. You can specify this threshold for text or smart identifiers.
This rule applies to the body of the message only. It does not include attachments
or headers.
URL Category See Filtering by URL Reputation or URL Category: Conditions and Rules , on
page 457 and About URL Categories, on page 467.
Message Size Is the body size within a specified range? Body size refers to the size of the
message, including both headers and attachments. The body-size rule selects those
messages where the body size compares as directed to a specified number.
Macro Detection Does the incoming or outgoing message contain macro-enabled attachments?
You can use the Macro Detection condition to detect macro-enabled attachments
in messages for the selected file type(s).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
284
Content Filters
Content Filter Conditions
Condition Description
Attachment Content Contains text. Does the message contain an attachment that contains text or another
attachment that matches a specific pattern? This rule is similar to the
body-contains() rule, but it attempts to avoid scanning the entire “body” of the
message. That is, it attempts to scan only that which the user would view as being
an attachment.
Contains a smart identifier. Does content in the message attachment match the
specified smart identifier?
Contains terms in content dictionary. Does the attachment contain any of the
regular expressions or terms in the content dictionary named <dictionary name>
?
To search for dictionary terms, the dictionary must already have been created. See
Content Dictionaries, on page 643.
Note The dictionary-related conditions are only available if you have one or
more dictionaries enabled. For information about creating content
dictionaries, see Content Dictionaries, on page 643.
Number of matches required. Specify the number of matches required for the
rule to evaluate to true. You can specify this threshold for text, smart identifier,
or content dictionary matches.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
285
Content Filters
Content Filter Conditions
Condition Description
Attachment File Info Filename. Does the message have an attachment with a filename that matches a
specific pattern?
Filename contains term in content dictionary. Does the message have an
attachment with a filename that contains any of the regular expressions or terms
in the content dictionary named <dictionary name> ?
For this option to be enabled, the dictionary must already have been created. See
Content Dictionaries, on page 643.
Note The dictionary-related conditions are only available if you have one or
more dictionaries enabled. For information about creating content
dictionaries, see Content Dictionaries, on page 643.
File type. Does the message have an attachment of a file type that matches a
specific pattern based on its fingerprint (similar to a UNIX file command)?
MIME type. Does the message have an attachment of a specific MIME type?
This rule is similar to the attachment-type rule, except only the MIME type given
by the MIME attachment is evaluated. (The email gateway does not try to “guess”
the type of the file by its extension if there is no explicit type given.)
File Hash List. Does the message have an attachment that matches a specific file
SHA-256 value? Select the required file hash list from the drop-down list.
Note You can only select a file hash list that contains the SHA-256 file hash
type.
Image Analysis. Does the message have an image attachment that matches the
image verdict specified? Valid image analysis verdicts include: Suspect,
Inappropriate, Suspect or Inappropriate, Unscannable , or Clean.
External Threat Feeds: Does the file match the threat information from the
selected external threat feed source(s)?
Select a File Hash Exception List: (Optional) Select the list of allow listed file
hashes that you do not want the email gateway to detect for threats.
For more information, see Configuring Email Gateway to Consume External Threat
Feeds, on page 305.
Attachment is Corrupt. Does this message have an attachment that is corrupt?
Note A corrupt attachment is an attachment that the scanning engine cannot
scan and identified as corrupt.
Attachment Protection Contains an attachment that is password-protected or encrypted.
(For example, use this condition to identify attachments that are potentially
unscannable.)
Contains an attachment that is NOT password-protected or encrypted.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
286
Content Filters
Content Filter Conditions
Condition Description
Subject Header Subject Header: Does the subject header match a certain pattern?
Contains terms in content dictionary: Does the subject header contain any of
the regular expressions or terms in the content dictionary <dictionary name> ?
To search for dictionary terms, the dictionary must already have been created. See
Content Dictionaries, on page 643.
Note The dictionary-related conditions are only available if you have one or
more dictionaries enabled. For information about creating content
dictionaries, see Content Dictionaries, on page 643.
Other Header Header name: Does the message contain a specific header?
Header value: Does the value of that header match a certain pattern?
Header value contains terms in the content dictionary. Does the specified
header contain any of the regular expressions or terms in the content dictionary
named <dictionary name> ?
To search for dictionary terms, the dictionary must already have been created. See
Content Dictionaries, on page 643
Note The dictionary-related conditions are only available if you have one or
more dictionaries enabled. For information about creating content
dictionaries, see Content Dictionaries, on page 643.
For an example showing how this option can be used, see Using Custom Headers
to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy:
Configuration Example , on page 403.
Envelope Sender Envelope Sender. Does the Envelope Sender (i.e., the Envelope From, <MAIL
FROM>) match a given pattern?
Matches LDAP group. Is the Envelope Sender, i.e., the Envelope From, <MAIL
FROM>) in a given LDAP group?
Contains term in content dictionary. Does the envelope sender contain any of
the regular expressions or terms in the content dictionary named <dictionary name>
?
To search for dictionary terms, the dictionary must already have been created. See
Content Dictionaries, on page 643.
Note The dictionary-related conditions are only available if you have one or
more dictionaries enabled. For information about creating content
dictionaries, see Content Dictionaries, on page 643.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
287
Content Filters
Content Filter Conditions
Condition Description
Envelope Recipient Envelope Recipient. Does the Envelope Recipient, (i.e. the Envelope To, <RCPT
TO>) match a given pattern?
Matches LDAP group. Is the Envelope Recipient, (i.e. the Envelope To, <RCPT
TO>) in a given LDAP group?
Contains term in content dictionary. Does the envelope recipient contain any
of the regular expressions or terms in the content dictionary named <dictionary
name> ?
To search for dictionary terms, the dictionary must already have been created. See
Content Dictionaries, on page 643.
Note The dictionary-related conditions are only available if you have one or
more dictionaries enabled. For information about creating content
dictionaries, see Content Dictionaries, on page 643.
The Envelope Recipient rule is message-based. If a message has multiple
recipients, only one recipient has to be found in a group for the specified
action to affect the message to all recipients.
Is the Envelope Sender (i.e., the Envelope From, <MAIL FROM>) in a given
LDAP group?
Receiving Listener Did the message arrive via the named listener? The listener name must be the name
of a listener currently configured on the system.
Remote IP Was the message sent from a remote host that matches a given IP address or IP
block? The Remote IP rule tests to see if the IP address of the host that sent that
message matches a certain pattern. This can be an Internet Protocol version 4
(IPv4) or version 6 (IPv6) address. The IP address pattern is specified using the
allowed hosts notation described in Sender Group Syntax, on page 103, except for
the SBO, IPR, dnslist notations and the special keyword ALL.
Reputation Score What is the sender’s IP Reputation Score? The Reputation Score rule checks the
IP Reputation Score against another value.
DKIM Authentication Did DKIM authentication pass, partially verify, return temporarily unverifiable,
permanently fail, or were no DKIM results returned?
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
288
Content Filters
Content Filter Conditions
Condition Description
Forged Email Detection Is the sender address of the message forged? The rule checks if the From: header
in the message is similar to any of the users in the content dictionary.
Select a content dictionary and enter the threshold value (1 through 100) for
considering a message as potentially forged.
The Forged Email Detection condition compares the From: header with the users
in the content dictionary. During this process, depending on the similarity, the
email gateway assigns similarity score to each of the users in the dictionary. The
following are some examples:
• If the From: header is <[email protected]> and the content dictionary
contains a user ‘John Simons,’ the email gateway assigns a similarity score
of 82 to the user.
• If the From: header is <[email protected]> and the content
dictionary contains a user ‘John Simons,’ the email gateway assigns a
similarity score of 100 to the user.
The higher the similarity score, the higher the probability that the message is
forged. If the similarity score is greater than or equal to the specified threshold
value, the filter action is triggered.
If you want to skip the Forged email detection filter for messages from specific
senders, choose the address list from the Exception List drop-down list.
Note You can choose only the address lists that are created using the full
email addresses. For more information, refer to Using a List of Sender
Addresses for Incoming Connection Rules, on page 122.
For more information, see Forged Email Detection, on page 640.
SPF Verification What was the SPF verification status? This filter rule allows you to query for
different SPF verification results. For more information about SPF verification,
see the “Email Authentication” chapter.
Note If you have configured an SPF verification content filter condition
without an SPF identity and if a message contains different SPF
identities with different verdicts, the condition is triggered if one of the
verdicts in the message matches the condition.
S/MIME Gateway Is the message S/MIME signed, encrypted, or signed and encrypted? For more
Message information, see S/MIME Security Services, on page 553
S/MIME Gateway Is the S/MIME message successfully verified, decrypted, or decrypted and verified?
Verified For more information, see S/MIME Security Services, on page 553
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
289
Content Filters
Content Filter Actions
Condition Description
Message Language Is the message (subject and body) in one of the selected languages? This condition
will not check for the language in attachments and headers.
How does language detection work?
The email gateway uses the built-in language detection engine to detect the language
in a message. The email gateway extracts the subject and the message body and
passes it to the language detection engine.
The language detection engine determines the probability of each language in the
extracted text and passes it back to the email gateway. The email gateway considers
the language with the highest probability as the language of the message. The
email gateway considers the language of the message as ‘undetermined’ in one of
the following scenarios:
• If the detected language is not supported by email gateway
• If the email gateway is unable to detect the language of the message
• If the total size of the extracted text sent to the language detection engine is
less than 50 bytes.
Duplicate Boundaries Does the message contain duplicate MIME boundaries?
Verification
If you want to take actions on messages that contain duplicate MIME boundaries,
use this condition.
Note Attachment-based conditions (for example, Attachment Content) or
actions (for example, Strip Attachment by Content) will not work on
malformed messages (with duplicate MIME boundaries).
Geolocation Does the message originate from the selected countries?
You can use the Geolocation condition to handle incoming messages from particular
countries that you select.
Note Enable the Anti-Spam engine on your email gateway before you use
the Geolocation content filter.
Domain Reputation Does the sender domain match the specified criteria?
• Sender Domain Reputation
• External Threat Feeds
For more information, see Configuring Email Gateway to Consume External Threat
Feeds, on page 305 or Sender Domain Reputation Filtering, on page 323
Content Filter Actions
The action is what the email gatewaydoes with a message that matches the content filter’s condition. Many
different types of actions are available, including modifying the message, quarantining it, or dropping it. A
“final action” performed on a message, delivering or dropping it, forces the Email Security appliance to
perform the action immediately and forgo all further processing, such as Outbreak Filter or DLP scanning.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
290
Content Filters
Content Filter Actions
At least one action must be defined for each content filter.
Actions are performed in order on messages, so consider the order of actions when defining multiple actions
for a content filter.
When you configure a quarantine action for messages that match Attachment Content conditions, Message
Body or Attachment conditions, Message body conditions, or the Attachment content conditions, you can
view the matched content in the quarantined message. When you display the message body, the matched
content is highlighted in yellow. You can also use the $MatchedContent action variable to include the matched
content in the message subject. For more information, see the Text Resources chapter.
Only one final action may be defined per filter, and the final action must be last action listed. Bounce, deliver,
and drop are final actions. When entering actions for content filters, the GUI and CLI will force final actions
to be placed last.
See also Action Variables, on page 297.
Table 33: Content Filter Actions
Action Description
Quarantine Quarantine. Flags the message to be held in one of the policy quarantine
areas.
Duplicate message: Sends a copy of the message to the specified quarantine
and continues processing the original message. Any additional actions apply
to the original message.
Encrypt on Delivery The message continues to the next stage of processing. When all processing
is complete, the message is encrypted and delivered.
Encryption rule: Always encrypts the message or only encrypts it if an attempt
to send it over a TLS connection first fails. See Using a TLS Connection as
an Alternative to Encryption, on page 546 for more information.
Encryption Profile. Once processing is complete, encrypts the message using
the specified encryption profile, then delivers the message. This action is for
use with a Cisco Encryption Appliance or a hosted key service.
Subject. Subject for the encrypted message. By default, the value is
$Subject .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
291
Content Filters
Content Filter Actions
Action Description
Strip Attachment by Content Attachment contains. Drops all attachments on messages that contain the
regular expression. Archive files (zip, tar) will be dropped if any of the files
they contain match the regular expression pattern.
Contains smart identifier. Drops all attachments on a message that contains
the specified smart identifier.
Attachment contains terms in the content dictionary. Does the attachment
contain any of the regular expressions or terms in the content dictionary named
<dictionary name> ?
Number of matches required. Specify the number of matches required for
the rule to evaluate to true. You can specify this threshold for text, smart
identifier, or content dictionary matches.
Replacement message. The optional comment serves as the means to modify
the text used to replace the attachment that was dropped. Attachment footers
simply append to the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
292
Content Filters
Content Filter Actions
Action Description
Strip Attachment by File Info File name. Drops all attachments on messages that have a filename that match
the given regular expression. Archive file attachments (zip, tar) will be dropped
if they contain a file that matches.
File size. Drops all attachments on the message that, in raw encoded form,
are equal to or greater than the size (in bytes) given. Note that for archive or
compressed files, this action does not examine the uncompressed size, but
rather the size of the actual attachment itself.
File type. Drops all attachments on messages that match the given “fingerprint”
of the file. Archive file attachments (zip, tar) will be dropped if they contain
a file that matches.
MIME type. Drops all attachments on messages that have a given MIME
type.
File Hash List. Drops all attachments on messages that match the file SHA-256
value in the selected file hash list. Select the required file hash list from the
drop-down list.
Note You can only select a file hash list that contains the SHA-256 file
hash type.
Image Analysis Verdict. Drops attachments for image attachments that match
the image verdict specified. Valid image analysis verdicts include: Suspect,
Inappropriate, Suspect or Inappropriate, Unscannable , or Clean .
External Threat Feeds. Drops all message attachments on messages whose
files are categorized as malicious by the ETF engine.
Select a File Hash Exception List. (Optional) Select the list of allow listed
file hashes that you do not want the Cisco Email Security Gateway to detect
for threats.
For more information, see Configuring Email Gateway to Consume External
Threat Feeds, on page 305.
Replacement message. The optional comment serves as the means to modify
the text used to replace the attachment that was dropped. Attachment footers
simply append to the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
293
Content Filters
Content Filter Actions
Action Description
Strip Attachment with Macro Drops all macro-enabled attachments of the specified file type.
Note If an archive or embedded file contains macros, the parent file is
dropped from the message.
Custom Replacement Message (Optional): By default, a system generated
message is added to the bottom of the message body when an attachment is
dropped.
The following is a sample system generated message when a macro-enabled
attachment is dropped from the message:
A MIME attachment of type <application/vnd.ms-excel>
was removed here by a drop-macro-enabled-attachments
filter rule on the host <mail.example.com>.
The custom message that you enter in the Custom Replacement Message
field replaces the system-generated message.
URL Reputation See Modifying URLs in Messages: Using URL Reputation and URL Category
Actions in Filters , on page 458 and Creating Allowed Lists for URL Filtering
, on page 453.
Use “No Score” to specify an action for URLs for which a reputation cannot
be determined.
Note The email gateway considers a message signed if it is encrypted
using S/MIME or it contains an S/MIME signature.
URL Category See Modifying URLs in Messages: Using URL Reputation and URL Category
Actions in Filters , on page 458 and About URL Categories, on page 467.
Note The email gateway considers a message signed if it is encrypted
using S/MIME or it contains an S/MIME signature.
Add Disclaimer Text Above. Add disclaimer above message (heading).
Below. Add disclaimer below message (footer).
Note: You must have already created disclaimer text in order to use this content
filter action.
See Disclaimer Template, on page 655 for more information.
Bypass Outbreak Filter Bypass Outbreak Filter scanning for this message.
Scanning
Bypass DKIM Signing Bypass DKIM signing for this message.
Send Copy (Bcc:) Email addresses. Copies the message anonymously to the specified recipients.
Subject. Add a subject for the copied message.
Return path (optional). Specify a return path.
Alternate mail host (optional). Specify an alternate mail host.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
294
Content Filters
Content Filter Actions
Action Description
Notify Notify. Reports this message to the specified recipients. You can optionally
notify the sender and recipients.
Subject. Add a subject for the copied message.
Return path (optional). Specify a return path.
Use template. Select a template from the templates you created.
Include original message as an attachment. Adds the original message as
an attachment.
Change Recipient to Email address. Changes the recipient of the message to the specified email
address.
Send to Alternate Destination Mail host. Changes the destination mail host for the message to the specified
Host mail host.
Note This action prevents a message classified as spam by an anti-spam
scanning engine from being quarantined. This action overrides the
quarantine and sends it to the specified mail host.
Deliver from IP Interface Send from IP interface. Send from the specified IP Interface. The Deliver
from IP Interface action changes the source host for the message to the source
specified. The source host consists of the IP interface that the messages should
be delivered from.
Strip Header Header name. Remove the specified header from the message before
delivering.
Add/Edit Header Inserts a new header into the message or modifies an existing header.
Header name. Name of new or existing header.
Specify value of new header. Inserts a value for the new header into the
message before delivering.
Prepend to the Value of Existing Header. Prepends the value to the existing
header before delivering.
Append to the Value of Existing Header. Appends the value to the existing
header before delivering.
Search & Replace from the Value of Existing Header. Enter a search term
to find the value you want to replace in the existing header in the Search for
field. Enter the value you want to insert into the header in the Replace with
field. You can use a regular expression to search for the value. Leave the
Replace with field empty if you want to delete the value from the header.
Forged Email Detection Strips the From: header from the forged message and replaces it with the
Envelope Sender.
See Forged Email Detection, on page 640.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
295
Content Filters
Content Filter Actions
Action Description
Add Message Tag Inserts a custom term into the message to use with DLP policy filtering. You
can configure a DLP policy to limit scanning to messages with the message
tag. The message tag is not visible to recipients. For information on using
messages tags in a DLP policy, see Policies for Data Loss Prevention, on
page 512.
Add Log Entry Inserts customized text into the IronPort Text Mail logs at the INFO level.
The text can include action variables. The log entry also appears in message
tracking.
S/MIME Sign/Encrypt on Performs an S/MIME signing or encryption of the message during the delivery.
Delivery This means that the message continues to the next stage of processing, and
when all processing is complete, the message is signed or encrypted and
delivered.
S/MIME Sending Profile: Performs an S/MIME signing or encryption using
the specified S/MIME sending profile. See Managing S/MIME Sending
Profiles, on page 563.
Encrypt and Deliver Now Encrypts and delivers the message, skipping any further processing.
(Final Action)
Encryption rule: Always encrypts the message or only encrypts it if an attempt
to send it over a TLS connection first fails. See Using a TLS Connection as
an Alternative to Encryption, on page 546 for more information.
Encryption Profile. Encrypts the message using the specified encryption
profile, then delivers the message. This action is for use with a Cisco
Encryption Appliance or a hosted key service.
Subject. Subject for the encrypted message. By default, the value is
$Subject .
S/MIME Sign/Encrypt (Final Performs an S/MIME signing or encryption and delivers the message, skipping
Action) any further processing.
S/MIME Sending Profile: Performs an S/MIME signing or encryption using
the specified S/MIME sending profile. See Managing S/MIME Sending
Profiles, on page 563.
Bounce (Final Action) Sends the message back to the sender.
Skip Remaining Content Delivers the message to the next stage of processing, skipping any further
Filters (Final Action) content filters. Depending on configuration, this may mean deliver the message
to recipient(s), quarantine, or begin Outbreak Filters scanning.
Drop (Final Action) Drops and discards the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
296
Content Filters
Action Variables
Action Description
Safe Print Use the 'Safe Print' content filter action to safe print a message attachment.
You can use the Safe Print content filter action in any one of the following
ways:
• Safe print matching attachments: Use this option to safe print all
message attachments that match a configured content filter condition.
• Safe print all attachments: Use this option to safe print all message
attachments when the configured content filter condition is true
Select Yes to strip a message attachment that is marked as unscannable.
Note By default, a system generated message is added as an attachment
text file when an attachment is unscannable. You can enter a custom
message in the Custom Replacement Message field.
For more information, see How to Configure Email Gateway to Safe Print
Message Attachments, on page 348.
Related Topics
• Action Variables, on page 297
Action Variables
Headers added to messages processed by content filters can contain variables that will be automatically
replaced with information from the original message when the action is executed. These special variables are
called action variables. Your email gateway supports the following set of action variables:
Table 34: Action Variables
Variable Syntax Description
All Headers Replaced by the message headers.
$AllHeaders
Body Size Replaced by the size, in bytes, of the message.
$BodySize
Date Replaced by the current date, using the format
$Date
MM/DD/YYYY.
Dropped File Name Returns only the most recently dropped filename.
$dropped_filename
Dropped File Names Same as $filenames , but displays list of dropped files.
$dropped_filenames
Dropped File Types Same as $filetypes , but displays list of dropped file types.
$dropped_filetypes
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
297
Content Filters
Action Variables
Variable Syntax Description
Envelope Sender Replaced by the Envelope Sender (Envelope From, <MAIL
$envelopefrom
FROM>) of the message.
or
$envelopesender
Envelope Recipients Replaced by all Envelope Recipients (Envelope To, <RCPT
$EnvelopeRecipients
TO>) of the message.
File Names Replaced with a comma-separated list of the message’s
$filenames
attachments’ filenames.
File Sizes Replaced with a comma-separated list of the message’s
$filesizes
attachment’s file sizes.
File Types Replaced with a comma-separated list of the message's
$filetypes
attachments' file types.
Filter Name Replaced by the name of the filter being processed.
$FilterName
GMTimeStamp Replaced by the current time and date, as would be found
$GMTimeStamp
in the Received: line of an email message, using GMT.
HAT Group Name Replaced by the name of the sender group the sender
$Group
matched on when injecting the message. If the sender group
had no name, the string “ >Unknown< ” is inserted.
Mail Flow Policy Replaced by the name of the HAT policy applied to the
$Policy
sender when injecting the message. If no predefined policy
name was used, the string “ >Unknown< ” is inserted.
Matched Content Replaced by the value (or values) that triggered a
$MatchedContent
content-scanning filter. Matched content can be a content
dictionary match, a smart identifier, or a match to a regular
expression.
Header Replaced by the value of the quoted header, if the original
$Header['string
message contains a matching header. Note that double
']
quotes may also be used.
Hostname Replaced by the hostname of the email gateway.
$Hostname
Internal Message ID Replaced by the Message ID, or “MID” used internally to
$MID
identify the message. Not to be confused with the RFC822
“Message-Id” value (use $Header to retrieve that).
Receiving Listener Replaced by the nickname of the listener that received the
$RecvListener
message.
Receiving Interface Replaced by the nickname of the interface that received
$RecvInt
the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
298
Content Filters
How to Filter Messages Based on Content
Variable Syntax Description
Remote IP Address Replaced by the IP address of the system that sent the
$RemoteIP
message to the email gateway.
Remote Host Address Replaced by the hostname of the system that sent the
$remotehost
message to the email gateway.
SenderBase Reputation Replaced by the SenderBase Reputation score of the sender.
$Reputation
Score If there is no reputation score, it is replaced with “ None ”.
Subject Replaced by the subject of the message.
$Subject
Time Replaced by the current time, in the local time zone.
$Time
Timestamp Replaced by the current time and date, as would be found
$Timestamp
in the Received: line of an email message, in the local time
zone.
How to Filter Messages Based on Content
Related Topics
• Creating a Content Filter, on page 299
• Enabling Content Filters for All Recipients by Default, on page 300
• Applying the Content Filter to Messages for a Certain User Group, on page 301
• Notes on Configuring Content Filters in the GUI, on page 301
Creating a Content Filter
Before You Begin
• If you want to encrypt a message that matches the content filter, create an encryption profile.
• If you want to add a disclaimer to a matching message, create a disclaimer template to use for generating
disclaimers.
• If you want to send a notification message to a user due to a matching message, create a notification
template for generating notifications.
• If you want to quarantine a message, you create a new policy quarantine for these messages or use an
existing one.
Procedure
Step 1 Click Mail Policies > Incoming Mail Policies
or
Mail Policies > Outgoing Mail Policies.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
299
Content Filters
Enabling Content Filters for All Recipients by Default
Step 2 Click Add Filter.
Step 3 Enter a name and description for the filter.
Step 4 (X-REF) Click the Editable By (Roles) link, select the Policy Administrator and click OK.
Delegated administrators who belong to the Policy Administrator user role will be able to edit this content
filter and use it in their mail policies.
Step 5 (Optional) Add a condition for triggering the filter.
a) Click Add Condition.
b) Select the condition type.
c) Define the condition’s rules.
d) Click OK.
e) Repeat these steps for any additional conditions you want to add to the filter. When you define more than
one condition for a content filter, you can define whether all of the defined actions (that is, a logical AND)
or any of the defined actions (logical OR) need to apply in order for the content filter to be considered a
match.
Note If you do not add a condition, the email gateway will perform the content filter’s action to any
message that matches one of the mail policies associated with the filter.
Step 6 Add an action for the email gateway to take on a message that matches the filter’s condition.
a) Click Add Action.
b) Select the action type.
c) Define the action.
d) Click OK.
e) Repeat the previous steps for any additional actions you want the email gateway to take.
f) For multiple actions, arrange the actions in the order that you want the email gateway to apply them to
the message. There can only be one “final” action per filter, and AsyncOS automatically moves the final
action to the end of the order.
Step 7 Submit and commit your changes.
What to do next
• You can enable the content filter in a default incoming or outgoing mail policy.
• You can enable the content filter in a mail policy for a specific group of users.
Enabling Content Filters for All Recipients by Default
Procedure
Step 1 Click Mail Policies > Incoming Mail Policies
or
Mail Policies > Outgoing Mail Policies.
Step 2 Click the link for the Content Filters security service in the default policy row.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
300
Content Filters
Applying the Content Filter to Messages for a Certain User Group
Step 3 On the Content Filtering security service page, change the value Content Filtering for Default Policy from
“Disable Content Filters” to “Enable Content Filters (Customize settings).”
The content filters defined in the primary list (which were created in Overview of Content Filters , on page
281) are displayed on this page. When you change the value to “Enable Content Filters (Customize settings),”
the checkboxes for each filter become enabled.
Step 4 Check the Enable checkbox for each content filter you want to enable.
Step 5 Submit and commit your changes.
Applying the Content Filter to Messages for a Certain User Group
Before You Begin
• Create an incoming or outgoing mail policy for the group of users whose messages for which you want
to use the content filter. See Creating a Mail Policy for a Group of Senders and Recipients, on page 274
for more information.
Procedure
Step 1 Click Mail Policies > Incoming Mail Policies
or
Mail Policies > Outgoing Mail Policies.
Step 2 Click the link for the Content Filters security service (the Content Filters column) for the mail policy to which
you want to apply the content filter.
Step 3 On the Content Filtering security service page, change the value for Content Filtering for Policy: Engineering
from “Enable Content Filtering (Inherit default policy settings)” to “Enable Content Filtering (Customize
settings).”
Step 4 Select the checkboxes for the content filters you want to use.
Step 5 Submit and commit your changes.
Notes on Configuring Content Filters in the GUI
• It is not necessary to specify a condition when creating a content filter. When no action is defined, any
actions defined will always apply in the rule. (Specifying no condition is equivalent to using the true()
message filter rule — all messages will be matched if the content filter is applied to a policy.)
• If you do not assign a custom user role to a content filter, the content filter is public and can be used by
any delegated administrator for their mail policies. See the “Common Administrative Tasks” chapter for
more information on delegated administrators and content filters.
• Administrators and operators can view and edit all content filters on the email gateway, even when the
content filters are assigned to custom user roles.
• When entering text for filter rules and actions, the following meta characters have special meaning in
regular expression matching: . ^ $ * + ? { [ ] \ | ( )
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
301
Content Filters
Notes on Configuring Content Filters in the GUI
If you do not wish to use regular expression you should use a '\' (backslash) to escape any of these
characters. For example: "\*Warning\*"
• You can test message splintering and content filters by creating “benign” content filters. For example,
it is possible to create a content filter whose only action is “deliver.” This content filter will not affect
mail processing; however, you can use this filter to test how Email Security Manager policy processing
affects other elements in the system (for example, the mail logs).
• Conversely, using the “primary list” concept of the Incoming or Outgoing Content Filters, it is possible
to create very powerful, wide-sweeping content filters that will immediately affect message processing
for all mail handled by the email gateway. The process for this is to:
• Use the Incoming or Outgoing Content Filters page to create a new content filter whose order is 1.
• Use the Incoming or Outgoing Mail Policies page to enable the new content filter for the default
policy.
• Enable the content filter for all remaining policies.
• The Bcc: and Quarantine actions available in Content Filters can help you determine the retention settings
of quarantines you create. (See Policy, Virus, and Outbreak Quarantines, on page 927) You can create
filters that would simulate mail flow into and out of your policy quarantines so that messages are not
released too quickly from the system (that is, the quarantine areas do not fill their allotted disk space too
quickly).
• Because it uses the same settings as the Scan Behavior page or the scanconfig command, the “Entire
Message” condition does not scan a message’s headers; choosing the “Entire Message” will scan only
the message body and attachments. Use the “Subject” or “Header” conditions to search for specific header
information.
• Configuring users by LDAP query will only appear in the GUI if you have LDAP servers configured on
the email gateway (that is, you have configured the appliance to query specific LDAP servers with specific
strings using the ldapconfig command).
• Some sections of the content filter rule builder will not appear in the GUI if the resource has not been
preconfigured. For example, notification templates and message disclaimers will not appear as options
if they have not been configured previously using the Text Resources page or the textconfig command
in the CLI.
• Content filters features will recognize, can contain, and/or scan for text in the following character
encodings:
• Unicode (UTF-8)
• Unicode (UTF-16)
• Western European/Latin-1 (ISO 8859-1)
• Western European/Latin-1 (Windows CP1252)
• Traditional Chinese (Big 5)
• Simplified Chinese (GB 2312)
• Simplified Chinese (HZ GB 2312)
• Korean (ISO 2022-KR)
• Korean (KS-C-5601/EUC-KR)
• Japanese (Shift-JIS (X0123))
• Japanese (ISO-2022-JP)
• Japanese (EUC)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
302
Content Filters
Notes on Configuring Content Filters in the GUI
You can mix and match multiple character sets within a single content filter. Refer to your web browser’s
documentation for help displaying and entering text in multiple character encodings. Most browsers can
render multiple character sets simultaneously.
• On the Incoming or Outgoing Content Filters summary pages, use the links for “Description,” “Rules,”
and “Policies” to change the view presented for the content filters:
• The Description view shows the text you entered in the description field for each content filter.
(This is the default view.)
• The Rules view shows the rules and regular expressions build by the rule builder page.
• The Policies shows the policies for which each content filter is enabled.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
303
Content Filters
Notes on Configuring Content Filters in the GUI
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
304
CHAPTER 12
Configuring Email Gateway to Consume External
Threat Feeds
This chapter contains the following sections:
• Overview of External Threat Feeds, on page 305
• How to Configure Email Gateway to Consume External Threat Feeds , on page 306
• Obtaining External Threat Feeds Feature Key , on page 306
• Enabling External Threat Feeds Engine on Email Gateway, on page 308
• Configuring an External Threat Feed Source, on page 308
• Handling Messages Containing Threats, on page 311
• Configuring a Sender Group for Handling Messages containing Threats , on page 312
• Configuring Content or Message Filters for Handling Messages Containing Threats, on page 312
• Attaching Content Filter to Incoming Mail Policy, on page 319
• External Threat Feeds and Clusters, on page 319
• Monitoring External Threat Feeds Engine Updates, on page 319
• Viewing Alerts, on page 320
• Displaying Threat Details in Message Tracking, on page 320
Overview of External Threat Feeds
The External Threat Feeds (ETF) framework allows the email gateway to consume external threat information
in STIX format communicated over TAXII protocol.
The ability to consume external threat information in the email gateway, helps an organization to:
• Proactively respond to cyber threats such as, malware, ransomware, phishing attacks, and targeted attacks.
• Subscribe to local and third-party threat intelligence sources.
• Improve the efficacy of the email gateway.
You need a valid feature key to use the ETF feature on your email gateway. For information on how to obtain
a feature key, contact your Cisco sales representative.
STIX (Structured Threat Information eXpression) is the industry standard, structured language to represent
cyber threat information. A STIX source consists of an indicator that contains a pattern used to detect malicious
or suspicious cyber activity.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
305
Configuring Email Gateway to Consume External Threat Feeds
How to Configure Email Gateway to Consume External Threat Feeds
The following is a list of STIX Indicators of Compromise (IOCs) supported for this release:
• File Hash Watchlist (describes a set of hashes for suspected malicious files)
• IP Watchlist (describes a set of suspected malicious IP addresses)
• Domain Watchlist (describes a set of suspected malicious domains)
• URL Watchlist (describes a set of suspected malicious URLs)
TAXII (Trusted Automated eXchange of Indicator Information) defines a set of specifications to exchange
cyber threat information via services (TAXII servers) across different organizations or product lines.
The following versions of STIX/TAXII are supported for this release - STIX 1.1.1 and 1.2 with TAXII 1.1.
How to Configure Email Gateway to Consume External Threat
Feeds
Perform these steps in order:
Steps Do This More Information
Step 1 Obtain an External Threat Feeds Obtaining External Threat Feeds
feature key. Feature Key , on page 306
Step 2 Enable the ETF engine on your Enabling External Threat Feeds
email gateway. Engine on Email Gateway, on page
308
Step 3 Configure an ETF source to allow Configuring an External Threat
your email gateway to fetch threat Feed Source, on page 308
feeds in STIX format from a TAXII
server.
Step 4 Handle messages that contain Handling Messages Containing
threats using: Threats, on page 311
• HAT
• Content or Message filters
Step 5 Attach the content filters that you Attaching Content Filter to
configured to detect malicious Incoming Mail Policy, on page 319
domains, URLs, or file hashes in
messages to an incoming mail
policy.
Obtaining External Threat Feeds Feature Key
Managing Email Gateways using the Classic Licensing Mode
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
306
Configuring Email Gateway to Consume External Threat Feeds
Obtaining External Threat Feeds Feature Key
If you are an existing user using the Classic Licensing mode and you do not have an External Threat Feeds
feature key, follow the given steps to contact the Cisco Global Licensing Operations (GLO) team to obtain
the feature key:
Procedure
Step 1 Send an email to the GLO team ([email protected]) with the message subject as "Request for External
Threat Feeds Feature Key."
Step 2 Provide your Product Authorization Key (PAK) file and Purchase order (PO) details in the email.
The GLO team provisions the feature key manually and sends you an email with the license key to install on
your email gateway.
What to do next
Note • If you are an existing user using the hardware or virtual email gateway models and you can obtain feature
keys or software licenses directly from the Cisco server, you are automatically provided with an External
Threat Feeds feature key.
• If you are an existing user using the virtual email gateway models and are not able to obtain feature keys
or licenses directly from the Cisco server, perform the following steps to obtain an External Threat Feeds
feature key:
1. Log in to the License Registration Portal (LRP) using your LRP user account credentials.
2. Select Get License.
3. Select Migration.
4. Select Security Products
5. Select Email Security (ESA)
6. Enter the VLN Number and generate the license file.
The generated license file includes the ETF feature. You need to install the new license file in your
email gateway to use the ETF feature.
Note If you are not able to log in to your LRP account, contact the GLO team
([email protected]) to generate the license file.
Managing Email Gateways using the Smart Software Licensing Mode
If you are an existing or new user using the Smart Licensing mode on your email gateways, you are
automatically provided with an External Threat Feeds feature key.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
307
Configuring Email Gateway to Consume External Threat Feeds
Enabling External Threat Feeds Engine on Email Gateway
Enabling External Threat Feeds Engine on Email Gateway
Before you begin
Make sure that you have a valid feature key to you use the ETF feature on your email gateway.
Procedure
Step 1 Click Security Services > External Threat Feeds.
Step 2 Click Enable.
Step 3 Scroll to the bottom of the license agreement page and click Accept to accept the agreement.
Note If you do not accept the license agreement, ETF is not enabled on your Cisco Email Security Gateway.
Step 4 Check Enable External Threat Feeds.
Step 5 (Optional) Select Yes to add a custom header to all messages that are not scanned for threats by the ETF
engine because of an ETF engine lookup failure.
Step 6 Submit and commit your changes.
What to do next
Configure an ETF source. See Configuring an External Threat Feed Source, on page 308.
Configuring an External Threat Feed Source
An ETF source is used to download information about a collection of threats that is available on a TAXII
server. You need to configure an ETF source to allow your email gateway to fetch threat feeds in STIX format
from a TAXII server.
Note You can configure a maximum of eight ETF sources in your email gateway.
You can configure an ETF source using the Poll service that consists of a ‘polling path’ and a ‘collection
name.’
Before you begin
• Make sure that you have enabled the ETF engine on your email gateway.
• Make sure that you open ports - 80 HTTP and 443 HTTPS on your firewall to allow your gateway to
consume external threat feeds. For more information, see Firewall Information, on page 1325.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
308
Configuring Email Gateway to Consume External Threat Feeds
Configuring an External Threat Feed Source
Procedure
Step 1 Click Mail Policies > External Threat Feeds Manager.
Step 2 Click Add Source.
Step 3 Enter the required parameters described in the following table to configure an ETF source.
Parameter Source Details Description
Source Name Enter a name for the ETF source.
Description Enter a description for the ETF source.
TAXII Details
Hostname Enter the hostname of a fully qualified domain name
or an IP address of a TAXII server.
Polling Path Enter the polling path that identifies the polling service
in a TAXII server, for example, /taxii-data.
Collection Name Enter the name of a collection of threat feeds that is
hosted on a TAXII server, for example,
guest.Abuse_ch.
Polling Interval Enter a polling interval to define the frequency of
fetching threat feeds from a TAXII server. The
minimum value is 15 minutes and the default value
is 60 minutes.
Age of Threat Feeds Enter the maximum age of a threat feed that can be
fetched from a TAXII server. The value for the age
must be between one through 365 days.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
309
Configuring Email Gateway to Consume External Threat Feeds
Configuring an External Threat Feed Source
Parameter Source Details Description
Time Span for Poll Segment Enter the time span for each poll segment.
The minimum time span for a poll segment is 1 day.
The maximum time span for a poll segment is the
value entered in the ‘Age of Threat Feeds’ field.
You can use the ‘Time Span for Poll Segment’ option
in the following scenarios:
• If there is no known limitation on the age of
threat feeds for a TAXII server, use the value
entered in the ‘Age of Threat Feeds’ option.
• If there is a known limitation on the age of threat
feeds for a TAXII server, use the known limit
value.
• If you do not know the known limitation on the
age of threat feeds for a TAXII server, use the
default value of 30 days.
• If the value you enter in the ‘Age of Threat
Feeds’ option is not supported by the TAXII
server, you can spilt the age of threat feeds into
different poll segments based on the time span
entered.
For example, if the age of the threat feeds is 100 days
and the TAXII server has a fixed limit on the age of
threat feeds (for example, ’40 days’), enter 40 as the
time span for poll segment
Note If the time span for the poll segment is a
small value (for example, ‘5 days’,) the
polling of the threat feed source can take
a long time to complete, and this may
impact the performance of your gateway.
Use HTTPS Select Yes if you want to connect to a TAXII server
using HTTPS.
Configure Credentials Select Yes, if you want to access a TAXII server using
the user credentials that you created in the TAXII
server.
Enter the username and password.
Proxy Details
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
310
Configuring Email Gateway to Consume External Threat Feeds
Handling Messages Containing Threats
Parameter Source Details Description
Use Global Proxy Select Yes, if you want the email gateway to connect
to a TAXII server through a proxy server.
You can configure a proxy server in any one of the
following ways:
• Security Services > Service Updates page in the
web interface
• updateconfig command in the CLI
If you select No, the email gateway directly connects
to a TAXII server.
Step 4 Submit and commit your changes.
After you configure an ETF source, your email gateway begins to fetch threat feeds from a TAXII source.
What to do next
• You can also configure an ETF source using the threatfeedsconfig > sourceconfig subcommand in
the CLI.
• (Optional) Click Suspend Polling ( ) icon in the Mail Policies > External Threat Feeds Manager page
to suspend the polling service for a configured ETF source.
• (Optional) Click Resume Polling ( ) icon in the Mail Policies > External Threat Feeds Manager page
to resume the polling service for a configured ETF source.
• (Optional) Click Poll Now in the Mail Policies > External Threat Feeds Manager page to fetch the threat
feeds from the last successful polling interval immediately.
• See Handling Messages Containing Threats, on page 311.
Handling Messages Containing Threats
You can handle messages that contain threats in your email gateway using:
• HAT
• Content or Message filters
Related Topics
• Configuring a Sender Group for Handling Messages containing Threats , on page 312.
• Configuring Content or Message Filters for Handling Messages Containing Threats, on page 312.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
311
Configuring Email Gateway to Consume External Threat Feeds
Configuring a Sender Group for Handling Messages containing Threats
Configuring a Sender Group for Handling Messages containing
Threats
You can configure an existing sender group to handle messages that originate from malicious IPs using the
verdict obtained from the ETF engine.
Procedure
Step 1 Go to Mail Policies > HAT Overview page.
Step 2 Click an existing sender group that you want to configure to handle messages that contain threats.
Step 3 Click Edit Settings.
Step 4 Select the required ETF source to filter malicious IP addresses.
Step 5 (Optional) Click Add Row to add another ETF source.
Step 6 Submit and commit your changes.
Configuring Content or Message Filters for Handling Messages
Containing Threats
You can configure one or more of the following content or message filters, to take appropriate actions on
messages that contain threats based on the verdicts obtained from the ETF engine:
• URL Reputation - to detect URLs categorized as malicious by the ETF engine.
• Domain Reputation - to detect domains categorized as malicious by the ETF engine.
• Attachment by File Info - to detect files categorised as malicious by the ETF engine based on the file
hash.
Related Topics
• Detecting Malicious Domains in Messages Using Content Filter, on page 313.
• Detecting Malicious Domains in Messages Using Message Filter, on page 314
• Detecting Malicious URLs in Messages Using Content Filter, on page 314
• Detecting Malicious URLs in Messages Using Message Filter, on page 316
• Detecting Malicious Files in Message Attachments Using Content Filter, on page 317.
• Detecting Malicious Files in Messages Attachments Using Message Filter , on page 235.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
312
Configuring Email Gateway to Consume External Threat Feeds
Detecting Malicious Domains in Messages Using Content Filter
Detecting Malicious Domains in Messages Using Content Filter
Use the ‘Domain Reputation’ content filter to detect domains categorized as malicious in messages by the
ETF engine and take appropriate actions on such messages.
Before you begin
• Optional) Create an address list that contains only domains. To create one, go to Mail Policies > Address
Lists page in the web interface or use the addresslistconfig command in the CLI. For more information,
see Mail Policies, on page 267.
• (Optional) Create a Domain Exception List. For more information, see Creating Domain Exception List.
Procedure
Step 1 Go to Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 Enter a name and description for the content filter.
Step 4 Click Add Condition.
Step 5 Click Domain Reputation.
Step 6 Select External Threat Feeds.
Step 7 Select the ETF source(s) to detect malicious domain(s) in the header(s) of a message.
Step 8 Select the required headers to check for the reputation of the domain.
Step 9 (Optional) Select the list of allow listed domains that you do not want the email gateway to detect for threats
for this content filter.
Step 10 Click OK.
Step 11 Click Add Action to configure an appropriate action to take on messages that contain malicious domains.
Step 12 Submit and commit your changes.
Creating Domain Exception List
A Domain Exception List consists of a list of addresses that contain only domains. You can use a Domain
Exception List if you want the email gateway to skip the domain check for all configured Domain Reputation
content or message filters.
Procedure
Step 1 Go to Security Services > Domain Reputation.
Step 2 Click Edit Settings under Domain Exception List.
Step 3 Select the required address list that contains domains only.
Step 4 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
313
Configuring Email Gateway to Consume External Threat Feeds
Detecting Malicious Domains in Messages Using Message Filter
What to do next
You can also create a Domain Exception List using the domainrepconfig command in the CLI. For more
information, see the CLI Reference Guide for AsyncOS 12.0 for Cisco Email Security Appliances.
Detecting Malicious Domains in Messages Using Message Filter
As an example, use the following message filter rule syntax to detect malicious domains in messages using
the ETF engine, and take appropriate actions on such messages.
Syntax:
quarantine_msg_based_on_ETF: if (domain-external-threat-feeds (['etf_source1'],
['mail-from', 'from'], <'domain_exception_list'>)) { quarantine("Policy"); }
Where
• ‘domain-external-threat-feeds' is the Domain reputation message filter rule.
• ‘etf_source1' is the ETF source(s) used to detect malicious domain(s) in the header(s) of a message.
• ‘mail-from','from' are the required header(s) used to check for the reputation of the domain.
• 'domain_exception_list' is the name of a domain exception list. If a domain exception list is not
present it is displayed as "".
Example
In the following example, if the domain in the ‘Errors To:’ custom header is detected as malicious
by the ETF engine, the message is quarantined.
Quaranting_Messages_with_Malicious_Domains: if domain-external-threat-feeds
(['threat_feed_source'], ['Errors-To'], "")) {quarantine("Policy");}
Detecting Malicious URLs in Messages Using Content Filter
Use the ‘URL Reputation’ content filter to detect URLs in messages categorized as malicious by the ETF
engine and take appropriate actions on such messages.
You can configure the 'URL Reputation' content filter for ETF in any one of the following ways:
• Use the 'URL Reputation' condition with any appropriate action.
• Use the 'URL Reputation' action with any or no condition.
• Use the 'URL Reputation' condition and action.
The following procedure is used to detect malciicous URLs using the 'URL Reputation' condition and action:
Note • If you only want to use the 'URL Reputation' condition with any appropriate action, do not follow steps
11-20 of the procedure.
• If you only want to use the 'URL Reputation' action with any or no condition., do not follow steps 4-10
of the procedure.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
314
Configuring Email Gateway to Consume External Threat Feeds
Detecting Malicious URLs in Messages Using Content Filter
Before you begin
• Make sure that you enable URL filtering on your email gateway. To enable URL filtering, go to Security
Services > URL Filtering page in the web interface. For more information, see Protecting Against
Malicious or Undesirable URLs, on page 449.
• Make sure that you enable Outbreak Filters on your email gateway. To enable Outbreak Filters, go to
Security Services > Outbreak Filters page in the web interface. For more information, see Outbreak
Filters, on page 425.
• Make sure that you enable Anti-Spam engine on your email gateway. To enable the Anti-Spam engine,
go to Security Services > Anti-Spam page in the web interface. For more information, see Managing
Spam and Graymail, on page 383.
• (Optional) Create a URL list. To create one, go to Mail Polices > URL Lists page in the web interface.
For more information, see Protecting Against Malicious or Undesirable URLs, on page 449.
Procedure
Step 1 Go to Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 Enter a name and description for the content filter.
Step 4 Click Add Condition.
Step 5 Click URL Reputation.
Step 6 Select External Threat Feeds.
Step 7 Select the ETF source(s) to detect malicious URLs.
Step 8 (Optional) Select the list of allow listed URLs that you do not want the email gateway to detect for threats.
Step 9 Select the required Check URLs within option to detect malicious URLs in the message body and subject
and/or message attachments.
Step 10 Click OK.
Step 11 Click Add Action.
Step 12 Click URL Reputation.
Step 13 Select External Threat Feeds.
Step 14 Make sure that you select the same ETF source(s) that you selected in the condition (Step 7).
Step 15 (Optional) Select the same list of allow listed URLs that you selected in Step 8.
Step 16 Select the required Check URLs within option to detect malicious URLs in the 'message body and subject'
and/or 'message attachments'
Step 17 Select the required action that you want to perform on the URLs within the message body and subject and/or
message attachments.
Note In Step 16, if you choose the 'Check URLs within' option as 'Attachments', you can only strip the
attachment from the message.
Step 18 Select whether you want to take actions on all messages or unsigned messages.
Step 19 Click OK.
Step 20 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
315
Configuring Email Gateway to Consume External Threat Feeds
Detecting Malicious URLs in Messages Using Message Filter
Note If you have configured URL Reputation content filters for Web Based Reputation Score (WBRS)
and ETF on your email gateway, it is recommended to set the order of the WBRS URL Reputation
content filter higher than the order of the ETF URL Reputation filter, to improve the performance
of your emal gateway.
Detecting Malicious URLs in Messages Using Message Filter
As an example, use the ‘URL Reputation’ message filter rule syntax to detect malicious URLs in messages
using the ETF engine, and to defang the URL.
Syntax:
defang_url_in_message: if (url-external-threat-feeds (['etf_source1'],
<'URL_allowedlist'>,
<’message_attachments'> , <’message_body_subject’> ,))
{ url-etf-defang(['etf-source1'], "", 0); } <’URL_allowedlist’> ,
<’Preserve_signed’>)}
Where
• ‘url-external-threat-feeds’ is the URL Reputation rule.
• ‘etf_source1’ is the ETF source(s) used to detect malicious URLs in the messages or message
attachments.
• ‘URL_allowedlist’ is the name of a URL allowed list. If a URL allowed list is not present, it is displayed
as “”.
• ‘message_attachments’ is used to check for malicious URLs in the message attachments. A value of
'1' is used to detect malicious URLs in the message attachments.
• ‘message_body_subject’ is used to check for malicious URLs in the message body and subject. A value
of '1' is used to detect malicious URLs in the message body and subject.
Note A value of “1,1” is used to detect malciocus URLs in the message body, subject,
and message attachments.
• ‘url-etf-defang’ is one of the actions that you can take on messages that contain malicious URLs.
The following examples are the ETF-based actions that you can apply on messages that contain malicious
URLs:
• url-etf-strip(['etf_source1'], "None", 1)
• url-etf-defang-strip(['etf_source1'], "None", 1, "Attachment removed")
• url-etf-defang-strip(['etf_source1'], "None", 1)
• url-etf-proxy-redirect(['etf_source1'], "None", 1)
• url-etf-proxy-redirect-strip(['etf_source1'], "None", 1)
• url-etf-proxy-redirect-strip(['etf_source1'], "None", 1, " Attachment removed")
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
316
Configuring Email Gateway to Consume External Threat Feeds
Detecting Malicious Files in Message Attachments Using Content Filter
• url-etf-replace(['etf_source1'], "", "None", 1)
• url-etf-replace(['etf_source1'], "URL removed", "None", 1)
• url-etf-replace-strip(['etf_source1'], "URL removed ", "None", 1)
• url-etf-replace-strip(['etf_source1'], "URL removed*", "None", 1, "Attachment removed")
• ‘Preserve_signed’ is represented by ‘1’ or ‘0’. ‘1’ indicates that this action applies to unsigned messages
only and ‘0’ indicates that this action applies to all messages.
In the following example, if a URL in the message attachment is detected as malicious by the ETF
engine, the attachment is stripped.
Strip_Malicious_URLs: if (true) {url-etf-strip(['threat_feed_source'], "", 0);}
Detecting Malicious Files in Message Attachments Using Content Filter
Use the ‘Attachment File Info’ content filter to detect files in message attachments categorized as malicious
by the ETF engine, and take appropriate actions on such messages.
Note The ETF engine performs a lookup based on the file hash of a file.
You can configure the 'Attachment File Info' content filter for ETF in any one of the following ways:
• Use the 'Attachment File Info' condition with any appropriate action.
• Use the 'Strip Attachment by File Info' action with any or no condition.
• Use the 'Attachment File Info' condition and 'Strip Attachment by File Info' action.
The following procedure is used to detect malicious files in message attachments using the 'Attachment by
File Info' condition and 'Strip Attachment by File Info' action:
Note • If you only want to use the 'Attachment File Info' condition with any appropriate action, do not follow
steps 10-15 of the procedure.
• If you only want to use the 'Strip Attachment by File Info' action with any or no condition., do not follow
steps 4-9 of the procedure.
Before you begin
(Optional) Create a File Hash Exception List. To create one, go to Mail Policies > File Hash Lists page in the
web interface. For more information, see Creating File Hash List, on page 318.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
317
Configuring Email Gateway to Consume External Threat Feeds
Creating File Hash List
Procedure
Step 1 Go to Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 Enter a name and description for the content filter.
Step 4 Click Add Condition.
Step 5 Click Attachment File Info.
Step 6 Select External Threat Feeds.
Step 7 Select the ETF source(s) to detect malicious files using file hashes.
Step 8 (Optional) Select the list of file hashes that you do not want the email gateway to detect for threats.
Step 9 Click OK.
Step 10 Click Add Action.
Step 11 Click Strip Attachment by File Info.
Step 12 Select External Threat Feeds.
Step 13 Make sure that you select the same ETF source(s) that you selected in the condition (Step 7).
Step 14 (Optional) Select the same list of file hashes that you selected in Step 8.
Step 15 Submit and commit your changes.
Creating File Hash List
Procedure
Step 1 Go to Mail Policies > File Hash Lists.
Step 2 Click Add File Hash List.
Step 3 Check the required file hash type - ‘SHA256’ or ‘MD5' or all of the above.
Step 4 Enter the file hashes (that you selected in Step 3) separated by commas or in new lines.
Step 5 Submit and commit your changes.
Detecting Malicious Files in Messages Attachments Using Message Filter
As an example, use the following message filter rule syntax to detect files in message attachments categorized
as malicious by the ETF engine, and take appropriate actions on such messages.
Syntax:
Strip_malicious_files: if (file-hash-etf-rule (['etf_source1'], <'file_hash_exception_list'>))
{ file-hash-etf-strip-attachment-action (['etf_source1'], <'file_hash_exception_list>,
"file stripped from message attachment"); }
Where:
• ‘file-hash-etf-rule' is the Attachment File Info message filter rule
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
318
Configuring Email Gateway to Consume External Threat Feeds
Attaching Content Filter to Incoming Mail Policy
• ‘etf_source1' is the ETF source(s) used to detect malicious files in the messages based on the file hash.
• 'file_hash_exception_list' is the name of a file hash exception list. If a file hash exception list is
not present, it is displayed as “”.
• 'file-hash-etf-strip-attachment-action' is the name of the action that you want to apply on
messages that contain malicious files.
In the following example, if a message contains a message attachment detected as malicious by the
ETF engine, the attachment is stripped.
Strip_Malicious_Attachment: if (true) {file-hash-etf-strip-attachment-action
(['threat_feed_source'], "", “Malicious message attachment has been stripped from
the message.");}
Attaching Content Filter to Incoming Mail Policy
You can attach one or more of the content filters that you configured to detect malicious domains, URLs, or
file hashes in messages to an incoming mail policy.
Procedure
Step 1 Go to Mail Policies > Incoming Mail Policies.
Step 2 Click the link below Content Filtersof a particular mail policy.
Step 3 Select Enable Content Filters (Customize Settings).
Step 4 Select the Content Filters that you created for detecting malicious domains, URLs or file hashes.
Step 5 Submit and commit your changes.
What to do next
After you attach the content filter to an incoming mail policy, your email gateway begins to take actions on
messages based on the verdicts received from the ETF engine.
External Threat Feeds and Clusters
If you use centralized management, you can enable the ETF engine and mail policies at the cluster, group,
and machine level.
Monitoring External Threat Feeds Engine Updates
If you have enabled service updates, the ETF engine updates are retrieved from the Cisco update servers.
However, in some scenarios (for example, you have disabled automatic service updates or automatic service
update is not working), you might want to manually check for ETF engine updates.
You can manually update the ETF engine in any one of the following ways:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
319
Configuring Email Gateway to Consume External Threat Feeds
Viewing Alerts
• Go to Security Services > External Threat Feeds page in the web interface, and click Update Now.
• Use the threatfeedupdate command in the CLI.
To know the details of the existing ETF engine, see the ‘External Threat Feeds Engine Updates’ section in
the Security Services > External Threat Feeds page in the web interface or use the threatfeedstatus command
in CLI.
Viewing Alerts
The following table lists the alerts generated by the ETF engine, including a description of the alert and the
alert severity.
Component/Alert Name Message and Description Parameters
ETF ENGINE ALERT Unable to fetch the observables ‘source’ - The name of the TAXII
from the source: $source_name source.
after 3 failed attempts.
‘reason’ - The reason why the
Reason for failure: $reason polling failed.
Information. Sent when polling
feeds from a TAXII source fails.
ETF ENGINE ALERT The storage limit of $count $count - The allowed number of
observables exceeded for the observables per type.
observable type: $type.
$ type - The type of the observable.
Information. Sent when the number
of permitted observables exceeded.
Displaying Threat Details in Message Tracking
You can view the message details that contain threats corresponding to the selected IOCs from the selected
ETF source(s).
Before you begin
• Make sure that you enable the Message Tracking feature on the email gateway. To enable Message
Tracking, go to Security Services > Centralized Services > Message Tracking page in the web interface.
• Content or Message filters for detecting threats in messages are operational.
Procedure
Step 1 Go to Monitor > Message Tracking.
Step 2 Click Advanced.
Step 3 Check External Threat Feeds under Message Event.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
320
Configuring Email Gateway to Consume External Threat Feeds
Displaying Threat Details in Message Tracking
Step 4 Select the required IOC(s) to track messages containing threats corresponding to the selected IOCs.
Step 5 (Optional) Select All External Threat Feed Sources to view the messages that contain threats based on the
available and deleted ETF source(s) configured in the email gateway.
Step 6 (Optional) Select Current External Threat Feed Sources and choose the required ETF source(s) to view
the messages that contain threats based on the available ETF source(s) configured in the email gateway.
Step 7 (Optional) Enter the name of a particular ETF source in the 'External Threat Feed Sources' field to view
messages that contain threats based on this ETF source.
Step 8 Click Search.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
321
Configuring Email Gateway to Consume External Threat Feeds
Displaying Threat Details in Message Tracking
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
322
CHAPTER 13
Sender Domain Reputation Filtering
This chapter contains the following sections:
• Overview of Sender Domain Reputation Filtering, on page 323
• How to Filter Messages based on Sender Domain Reputation, on page 325
• Enabling Sender Domain Reputation Filtering on Email Gateway, on page 326
• Configuring Message or Content Filter for Handling Messages based on Sender Domain Reputation, on
page 327
• Attaching Content Filter to Incoming Mail Policy, on page 330
• Sender Domain Reputation Filtering and Clusters, on page 331
• Displaying Sender Domain Reputation Details in Message Tracking, on page 331
• Viewing Alerts, on page 332
• Viewing Logs, on page 332
Overview of Sender Domain Reputation Filtering
Cisco Talos Sender Domain Reputation (SDR) is a cloud service that provides a reputation verdict for email
messages based on a sender’s domain and other attributes.
The domain-based reputation analysis enables a higher spam catch rate by looking beyond the reputation of
shared IP addresses, hosting or infrastructure providers, and derives verdicts based on features that are
associated with fully qualified domain names (FQDNs) and other sender information in the Simple Mail
Transfer Protocol (SMTP) conversation and message headers.
For more information, see the Cisco Talos Sender Domain Reputation (SDR) white paper in the Security
Track of the Cisco Customer Connection program at http://www.cisco.com/go/ccp.
Note • You must create a Cisco Customer Connection account to access the SDR white paper.
• Like Cisco IPAS disputes, submit SDR disputes by opening a support request with the Cisco Technical
Assistance Center (TAC).
SDR Verdicts
The following table lists the SDR verdict names, descriptions, and recommended actions:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
323
Sender Domain Reputation Filtering
SDR Verdicts
Table 35: SDR Verdicts
Verdict Name Description Recommended Action
Awful The worst reputation verdict. Block the message.
Expect to see false-negatives (FN)
if the blocking threshold is set to
only this verdict, which prioritizes
delivery over security.
Poor The recommended blocking Scan the message with the other
threshold. engines configured on your email
gateway.
This balances the trade-offs
between false-negatives (FN) and
false-positives (FP). Talos tunes
SDR so that messages that are
blocked by SDR have either a poor
or awful verdict.
Not blocking on this verdict
prioritizes delivery over security,
but it results in false-negatives that
the customer accepts when not
blocking based on this verdict.
Tainted The sender reputation is suspect. Scan the message with the other
engines configured on your email
Blocking based on these verdicts is
gateway.
aggressive and not recommended
by Talos. It promotes security over
delivery, but it results in
false-positives that you can accept
when blocking based on this
verdict.
Weak A common verdict for many Scan the message with the other
domains (including legitimate and engines configured on your emal
mixed-use) associated with weak gateway.
indicators that preclude a neutral
verdict. Talos does not recommend
blocking on this verdict.
While this prioritizes security over
Delivery, it results in an
unacceptable number of
False-Positives (as per Talos) when
you block messages based on this
verdict.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
324
Sender Domain Reputation Filtering
How to Filter Messages based on Sender Domain Reputation
Verdict Name Description Recommended Action
Unknown The sender is using a newly Scan the message with the other
registered domain or one that SDR engines configured on your emal
does not otherwise recognize. For gateway.
domains in this undetermined state,
Talos performs further analysis to
establish a verdict quickly. Talos
does not recommend blocking on
this verdict. Blocking on this
verdict results in many False
Positives that you accept when
adjusting their threshold to this
verdict. Talos recommends
quarantining messages with a
verdict of “unknown.”
The message delivery is slightly
delayed to allow time for Talos to
investigate the domain before
scanning the message with
subsequent engines.
Neutral The normal expected verdict when Scan the message with the other
the sender is using a domain that is engines configured on your emal
not new and adheres to the sender gateway.
best practices. The following are
the sender best practices - using
SPF, DKIM-signing, not sending
spam, etc.
Good A rare verdict that indicates the Scan the message with the other
sender is using a certified domain engines configured on your emal
where messages are DKIM signed gateway.
(aligned on the “From:” header
domain).
How to Filter Messages based on Sender Domain Reputation
Steps Do This More Information
Step 1 Enable SDR filtering on Cisco Enabling Sender Domain
Email Security Gateway. Reputation Filtering on Email
Gateway, on page 326
Note After you upgrade to
AsyncOS 12.0, SDR
queries are enabled by
default.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
325
Sender Domain Reputation Filtering
Enabling Sender Domain Reputation Filtering on Email Gateway
Steps Do This More Information
Step 2 Configure a message or content Configuring Message or Content
filter to handle messages based on Filter for Handling Messages based
SDR. on Sender Domain Reputation, on
page 327
Step 3 Attach the content filter that you Attaching Content Filter to
configured to filter messages based Incoming Mail Policy, on page 330
on SDR to an incoming mail policy.
Enabling Sender Domain Reputation Filtering on Email Gateway
Note After you upgrade to AsyncOS 12.0, SDR queries are enabled by default.
Procedure
Step 1 Go to Security Services > Domain Reputation.
Step 2 Click Enable.
Step 3 Check Enable Sender Domain Reputation Filtering.
Step 4 (Optional) Check Include Additional Attributes if you want the SDR service to check for SDR based on
additional attributes of the message.
If you enable this option, the following additional attributes of the message are included in the SDR check to
improve the efficacy:
• Username part of the email address present in the 'Envelope From:,' 'From:,' and 'Reply-To:'
headers.
• Display name in the 'From:' and 'Reply-To:' headers.
Step 5 (Optional) Enter the number of elapsed seconds before the SDR query times out.
Note Modifying the SDR query timeout value may impact the performance of mail processing.
Step 6 (Optional) Check Match Domain Exception List based on Domain in Envelope From: if you want the
email gateway to skip the SDR check based on the domain in the Envelope From: header only.
Step 7 Move the Range Slider to choose the required SDR verdict range to accept or reject messages at the SMTP
conversation level.
Note After you upgrade to AsyncOS 14.x and later, the range slider by default points to the Awful verdict.
All messages with an Awful verdict are dropped at the SMTP conversation level.
Note You cannot select the 'Good' verdict to reject messages because the verdict indicates that the sender
uses a certified domain.
Step 8 Click Submit .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
326
Sender Domain Reputation Filtering
Configuring Message or Content Filter for Handling Messages based on Sender Domain Reputation
Step 9 (Optional) Click I Agree if you want to accept the SDR Include Additional Attributes Agreement message.
Note The SDR Include Additional Attributes Agreement message appears only when you select the
Include Additional Attributes option.
Step 10 Click Commit to commit your changes.
What to do next
Configure a content or message filter to handle messages based on SDR. See Configuring Message or Content
Filter for Handling Messages based on Sender Domain Reputation, on page 327.
Configuring Message or Content Filter for Handling Messages
based on Sender Domain Reputation
You can use the ‘Domain Reputation’ message or content filter in any one of the following ways to filter
messages based on SDR, and take appropriate actions on such messages:
• Sender Domain Verdict
• Sender Domain Age
• Sender Domain Unscannable
Related Topics
• Filtering Messages based on Sender Domain Reputation using Message Filter, on page 327
• Filtering Messages based on Sender Domain Reputation using Content Filter, on page 329
Filtering Messages based on Sender Domain Reputation using Message Filter
Filtering Messages based on Sender Domain Verdict
Note The recommended blocking threshold is "Awful." For more information about SDR verdicts, see SDR Verdicts,
on page 323.
Syntax:
drop_msg_based_on_sdr_verdict:
if sdr-reputation (['awful', 'poor'], "<domain_exception_list>")
{drop();}
Where:
• 'drop_msg_based_on_sdr_verdict'is the name of the message filter.
• 'sdr-reputation' is the Domain Reputation message filter rule.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
327
Sender Domain Reputation Filtering
Filtering Messages based on Sender Domain Reputation using Message Filter
• 'awful','poor' is the range of the sender domain verdict used to filter messages based on SDR.
• 'domain_exception_list' is the name of a domain exception list. If a domain exception list is not
present it is displayed as "".
• 'drop' is the action applied on the message.
Example
In the following message, if the SDR verdict is 'Unknown', the message is quarantined.
quarantine_unknown_sdr_verdicts:
if sdr-reputation (['unknown'], "")
{quarantine("Policy")}
Filtering Messages based on Sender Domain Age
Note The Sender Domain Age option will be removed in the next AsyncOS release.
Syntax:
<msg_filter_name>
if sdr-age (<‘unit'>, <‘operator'> <‘actual value’>)
{<action>}
Where:
• ‘sdr-reputation' is the Domain Reputation message filter rule.
• ‘sdr_age’ is the age of the sender domain used to filter messages based on SDR.
• ‘unit' is the number of ‘days,’ ‘years,’ ‘months,’ or 'weeks' option used to filter messages based on the
sender domain age.
• ‘operator' are the following comparison operators used to filter messages based on the sender domain
age:
• – > (Greater than)
• – >= (Greater than or equal to)
• – < (Lesser than)
• – <= (Lesser than or equal to)
• – == (Equal to)
• – != (Not equal to)
• – Unknown
• ‘actual value' is the number used to filter messages based on the sender domain age.
Examples
In the following message, if the age of the sender domain is unknown, the message is dropped.
Drop_Messages_Based_On_SDR_Age: if (sdr-age ("unknown", "")) {drop();}
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
328
Sender Domain Reputation Filtering
Filtering Messages based on Sender Domain Reputation using Content Filter
In the following message, if the age of the sender domain is less than one month, the message is dropped.
Drop_Messages_Based_On_SDR_Age: if (sdr-age ("months", <, 1, "")) { drop(); }
Filtering Messages based on Sender Domain Unscannable
Syntax:
<msg_filter_name>
if sdr-unscannable (<'domain_exception_list'>)
{<action>}
Where:
• 'sdr-unscannable' is the Domain Reputation message filter rule.
'domain_exception_list' is the name of a domain exception list. If a domain exception list is not
present it is displayed as "".
Example
In the following message, if the message failed the SDR check, the message is quarantined.
Quarantine_Messages_Based_On_Sender_Domain_Unscannable: if (sdr-unscannable (""))
{quarantine("Policy");}
Filtering Messages based on Sender Domain Reputation using Content Filter
Before you begin
• (Optional) Create an address list that contains only domains. To create one, go to Mail Policies > Address
Lists page in the web interface or use the addresslistconfig command in the CLI. For more information,
see Mail Policies, on page 267.
• (Optional) Create a Domain Exception List. For more information, see Creating Domain Exception List,
on page 330.
Procedure
Step 1 Go to Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 Enter a name and description for the content filter.
Step 4 Click Add Condition.
Step 5 Click Domain Reputation.
Step 6 Choose any one of the following conditions to filter messages based on SDR:
• Select Sender Domain Reputation Verdict to choose a verdict range to filter messages based on the
verdict received from the SDR service.
Note The recommended blocking threshold is "Awful." For more information about SDR Verdicts,
see SDR Verdicts, on page 323.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
329
Sender Domain Reputation Filtering
Creating Domain Exception List
• Select Sender Domain Age, choose the comparison operator, enter a number, and choose the time period
to filter messages based on the age of the sender domain.
Note The Sender Domain Age option will be removed in the next AsyncOS release.
• Select Sender Domain Reputation Unscannable to filter messages that failed the SDR check.
Step 7 (Optional) Select the list of allow listed domains that you do not want the email gateway to filter messages
based on SDR.
Step 8 Click Add Action to configure an appropriate action to take on messages based on SDR.
Step 9 Submit and commit your changes.
Creating Domain Exception List
A domain exception list consists of a list of addresses that contain only domains. You can use a domain
exception list to skip the SDR check for all incoming messages, irrespective of the mail policies configured
on your Cisco Email Security Gateway.
Note If you want to skip SDR content filter actions on incoming messages for specific mail policies, you need to
select the domain exception list in the Domain Reputation content filter.
Criteria for using Domain Exception List
By default, to skip the SDR check, the domains in the Envelope From:, From:, and Reply-To: headers of the
message must be the same and match the domain configured in the domain exception list. If you want to skip
the SDR check based on the domain in the Envelope From: header only, select the ‘Match Domain Exception
List based on Domain in Envelope From:’ option in the Domain Reputation settings page.
Procedure
Step 1 Go to Security Services > Domain Reputation.
Step 2 Click Edit Settings under Domain Exception List.
Step 3 Select the required address list that contains domains only.
Step 4 Submit and commit your changes.
What to do next
You can also create a Domain Exception List using the domainrepconfig command in the CLI. For more
information, see the CLI Reference Guide for AsyncOS for Cisco Email Security Appliances.
Attaching Content Filter to Incoming Mail Policy
You can attach the content filter that you configured to filter messages based on SDR to an incoming mail
policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
330
Sender Domain Reputation Filtering
Sender Domain Reputation Filtering and Clusters
Procedure
Step 1 Go to Mail Policies > Incoming Mail Policies.
Step 2 Click the link below Content Filters.
Step 3 Make sure to select 'Enable Content Filters (Customize Settings).'
Step 4 Select the content filter that you created for filtering messages based on SDR.
Step 5 Submit and commit your changes.
Sender Domain Reputation Filtering and Clusters
If you use centralized management, you can enable SDR filtering and mail policies at the cluster, group, and
machine level.
Displaying Sender Domain Reputation Details in Message
Tracking
You can use Message Tracking to view the message details based on SDR.
Before you begin
• Make sure that you enable the Message Tracking feature on the email gateway. To enable Message
Tracking, go to Security Services > Message Tracking page in the web interface.
• Content or message filters for filtering messages based on SDR are operational.
Procedure
Step 1 Go to Monitor > Message Tracking.
Step 2 Click Advanced.
Step 3 Check Sender Domain Reputation under Message Event.
Step 4 Select the required SDR verdict(s) to view messages based on the verdict received from the SDR service.
Step 5 (Optional) Check Unscannable to view messages when the SDR check failed.
Step 6 (Optional) Select the required SDR threat categories to view messages based on the threat category.
Step 7 Click Search.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
331
Sender Domain Reputation Filtering
Viewing Alerts
Viewing Alerts
The following table lists the system alert generated for SDR, including a description of the alert and the alert
severity.
Component/Alert Name Message and Description Parameters
MAIL.IMH.SENDER_DOMAIN_ The SDR lookup failed. Reason - ‘reason’ - The reason why the SDR
LOOKUP_FAILURE_ALERTS <$reason> query failed.
Warning. Sent when a SDR query
fails.
Viewing Logs
The SDR filtering information is posted to the Mail Logs. Most information is at the Info or Debug level.
Examples of SDR Filtering Log Entries
The SDR filtering information is posted to the Mail Logs. Most information is at the Info or Debug level.
• Sender Domain Reputation Authentication Failure, on page 332
• Sender Domain Reputation Request Timeout, on page 333
• Sender Domain Reputation Invalid Host, on page 333
• Sender Domain Reputation General Errors, on page 333
Sender Domain Reputation Authentication Failure
In this example, the log shows a message that was not filtered based on SDR because of an authentication
failure when connecting to the SDR service.
Mon Jul 2 08:57:18 2018 Info: New SMTP ICID 3 interface Management (192.0.2.10) address
224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 08:57:18 2018 Info: ICID 3 ACCEPT SG UNKNOWNLIST match ipr[none] ipr not enabled
country not enabled
Mon Jul 2 08:57:18 2018 Info: Start MID 3 ICID 3
Mon Jul 2 08:57:18 2018 Info: MID 3 ICID 3 From: <[email protected]>
Mon Jul 2 08:57:18 2018 Info: MID 3 ICID 3 RID 0 To: <[email protected]>
Mon Jul 2 08:57:18 2018 Info: MID 3 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>' Mon
Jul 2 08:57:18 2018 Info: MID 3 Subject 'Message 001'
Mon Jul 2 08:57:19 2018 Info: MID 3 SDR: Message was not scanned for Sender Domain Reputation.
Reason: Authentication failure.
Solution
Use the sdradvancedconfig command in the CLI to configure the required parameters when connecting your
email gateway to the SDR service.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
332
Sender Domain Reputation Filtering
Sender Domain Reputation Request Timeout
Sender Domain Reputation Request Timeout
In this example, the log shows a message that was not filtered based on SDR because of a request timeout
error when communicating with the SDR service.
Mon Jul 2 09:00:13 2018 Info: New SMTP ICID 4 interface Management (192.0.2.10) address
224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 09:00:13 2018 Info: ICID 4 ACCEPT SG UNKNOWNLIST match ipr[none] ipr not enabled
country not enabled
Mon Jul 2 09:00:13 2018 Info: Start MID 4 ICID 4
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 From: <[email protected]>
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 RID 0 To: <[email protected] >
Mon Jul 2 09:00:13 2018 Info: MID 4 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>'
Mon Jul 2 09:00:13 2018 Info: MID 4 Subject 'Message 001'
Mon Jul 2 09:00:13 2018 Info: MID 4 SDR: Message was not scanned for Sender Domain Reputation.
Reason: Request timed out.
Solution
When an SDR request times out, the message is marked as unscannable, and the configured actions are applied
to the message.
Sender Domain Reputation Invalid Host
In this example, the log shows a message that was not filtered based on SDR because an invalid SDR service
host was configured on your email gateway.
Mon Jul 2 09:04:08 2018 Info: ICID 7 ACCEPT SG UNKNOWNLIST match ipr[none] ipr not enabled
country not enabled
Mon Jul 2 09:04:08 2018 Info: Start MID 7 ICID 7
Mon Jul 2 09:04:08 2018 Info: MID 7 ICID 7 From: <[email protected] >
Mon Jul 2 09:04:08 2018 Info: MID 7 ICID 7 RID 0 To: <[email protected] >
Mon Jul 2 09:04:08 2018 Info: MID 7 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>' Mon
Jul 2 09:04:08 2018 Info: MID 7 Subject 'Message 001'
Mon Jul 2 09:04:08 2018 Info: MID 7 SDR: Message was not scanned for Sender Domain Reputation.
Reason: Invalid host configured.
Solution
Use the sdradvancedconfig command in the CLI to configure the required parameters when connecting your
email gateway to the SDR service.
Sender Domain Reputation General Errors
In this example, the log shows a message that was not filtered based on SDR because of an unknown error.
Mon Jul 2 09:00:13 2018 Info: New SMTP ICID 4 interface Management (192.0.2.10) address
224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 09:00:13 2018 Info: ICID 4 ACCEPT SG UNKNOWNLIST match ipr[none] ipr not enabled
country not enabled
Mon Jul 2 09:00:13 2018 Info: Start MID 4 ICID 4
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 From: <[email protected] >
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 RID 0 To: <[email protected] >
Mon Jul 2 09:00:13 2018 Info: MID 4 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>'
Mon Jul 2 09:00:13 2018 Info: MID 4 Subject 'Test mail'
Mon Jul 2 09:00:13 2018 Info: MID 4 SDR: Message was not scanned for Sender Domain Reputation.
Reason: Unknown error.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
333
Sender Domain Reputation Filtering
Sender Domain Reputation General Errors
Solution
When an unknown error occurs, the message is marked as unscannable, and the configured actions are applied
to the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
334
CHAPTER 14
Integrating with Cisco SecureX Threat Response
This chapter contains the following sections:
• Integrating your Email Gateway with Cisco SecureX Threat Response, on page 335
• How to Integrate your Email Gateway with Cisco SecureX Threat Response, on page 336
• Performing Threat Analysis using Cisco SecureX Ribbon, on page 340
• Performing Remedial Actions on Messages in Cisco SecureX Threat Response, on page 344
• Improving User Experience of Email Gateway using Cisco Success Network, on page 345
Integrating your Email Gateway with Cisco SecureX Threat
Response
Cisco SecureX is a security platform embedded with every Cisco security product. It is cloud-native with no
new technology to deploy. Cisco SecureX simplifies the demands of threat protection by providing a platform
that unifies visibility, enables automation, and strengthens your security across network, endpoints, cloud,
and applications. By connecting technology in an integrated platform, Cisco SecureX delivers measurable
insights, desirable outcomes, and unparalleled cross-team collaboration. Cisco SecureX enables you to expand
your capabilities by connecting your security infrastructure.
Integrating the Email Gateway with Cisco SecureX Threat Response contains the following sections:
• How to Integrate your Email Gateway with Cisco SecureX Threat Response, on page 336
• Performing Threat Analysis using Cisco SecureX Ribbon, on page 340
You can integrate your email gateway with Cisco SecureX Threat Response, and perform the following actions
in Cisco SecureX Threat Response:
• View and send the email data from multiple email gateways in your organization.
• Identify, investigate and remediate threats observed in the email reports, sender and target relationships,
search for multiple email addresses and subject lines and message tracking.
• Block compromised users or users violating outgoing email policies.
• Resolve the identified threats rapidly and provide recommended actions to take against the identified
threats.
• Document the threats to save the investigation and enable collaboration of information among other
devices.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
335
Integrating with Cisco SecureX Threat Response
How to Integrate your Email Gateway with Cisco SecureX Threat Response
• Block malicious domains, track suspicious observances, initiate an approval workflow or to create an IT
ticket to update email policy.
You can access Cisco SecureX Threat Response using the following URL:
https://securex.us.security.cisco.com/login
Cisco Secure Email Gateway provides advanced threat protection capabilities to detect, block, and remediate
threats faster, prevent data loss, and secure important information in transit with end-to-end encryption. For
more information on observables that can be enriched by the ESA module, go to
https://securex.us.security.cisco.com/settings/modules/available, navigate to the module to integrate with
Cisco SecureX and click Learn More.
HowtoIntegrateyourEmailGatewaywithCiscoSecureXThreat
Response
Table 36: How to Integrate your Email Gateway with Cisco SecureX Threat Response
Do This More Info
Step 1 Review the prerequisites. Prerequisites, on page 337
Step 2 [Applicable only for users using the Enabling Cisco Cloud Services Portal on Email
Classic Licensing mode]. Gateway, on page 338
Note If you are using the
Smart Licensing mode,
you can skip this step
because Cisco Cloud
Services Portal is
automatically enabled
on your email gateway.
Enable the Cisco Cloud Services
portal on your email gateway.
Step 3 On Cisco SecureX, add your email For more information, go to
gateway as a device, register it, and https://securex.us.security.cisco.com/help/
generate a registration token. settings-devices
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
336
Integrating with Cisco SecureX Threat Response
Prerequisites
Do This More Info
Step 4 [Applicable only for users using the Registering Email Gateway with Cisco Cloud Services
Classic Licensing mode]. Portal, on page 339
Note If you are using the
Smart Licensing mode,
you can skip this step
because your email
gateway is
automatically registered
with Cisco Cloud
Services Portal.
Register your email gateway with
the Cisco Cloud Services portal.
Step 5 Confirm whether the registration Confirm Whether the Registration was Successful,
was successful. on page 339
Step 6 Enable Cisco SecureX Threat Enabling Cisco SecureX Threat Response on Email
Response on your email gateway Gateway, on page 339
Step 7 On Cisco SecureX, add Cisco For more information, go to
Secure Email Gateway Module. https://securex.us.security.cisco.com/settings/modules/
available, navigate to the required Cisco Secure Email
Gateway module to integrate with Cisco SecureX,
click Add New Module, and see the instructions on
the page.
Prerequisites
Note If you already have a Cisco Threat Response user account, you do not need to create a Cisco SecureX user
account. You can log in to Cisco SecureX using your Cisco Threat Response user account credentials.
• Make sure that you create a user account in Cisco SecureX with admin access rights. To create a new
user account, go to Cisco SecureX login page using the URL https://securex.us.security.cisco.com/login
and click Create a SecureX Sign-on Account in the login page. If you are unable to create a new user
account, contact Cisco TAC for assistance.
• [Only if you are not using a proxy server .] Make sure that you open HTTPS (In and Out) 443 port on
the firewall for the following FQDNs to register your email gateway with Cisco SecureX Threat Response:
• api-sse.cisco.com (applicable for NAM users only)
• api.eu.sse.itd.cisco.com (applicable for European Union (EU) users only)
• api.apj.sse.itd.cisco.com (applicable for APJC users only)
• est.sco.cisco.com (applicable for APJC, EU, and NAM users)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
337
Integrating with Cisco SecureX Threat Response
Enabling Cisco Cloud Services Portal on Email Gateway
For more information, see Firewall Information, on page 1325.
• [For users with smart licensing registered on the email gateway] Make sure you have already linked your
smart account (created in Cisco Smart Software Manager portal) to Cisco Security Services Exchange.
For more information, see the following documentation at:
• [Applicable for NAM users] https://admin.sse.itd.cisco.com/assets/static/online-help/index.html#!t_
link_accounts.html
• [Applicable for European Union (EU) users] https://admin.eu.sse.itd.cisco.com/assets/static/
online-help/index.html#!t_link_accounts.html
• [Applicable for APJC users] https://admin.apj.sse.itd.cisco.com/assets/static/online-help/
index.html#!t_link_accounts.html
Enabling Cisco Cloud Services Portal on Email Gateway
Procedure
Step 1 Log in to your email gateway.
Step 2 Select Networks > Cloud Service Settings.
Step 3 Click Enable.
Step 4 Check the Enable Cisco Cloud Services check box.
Step 5 Choose the required Cisco Secure server to connect your email gateway to the Cisco Cloud Services portal.
Step 6 Submit and commit your changes.
Step 7 Wait for few minutes, and check whether the Register button appears on the Cloud Services Settings page.
In a clustered configuration, you can only register your logged-in email gateway with the Cisco Cloud Services
portal in the machine mode. If you have already registered your email gateway with the Cisco Cloud Services
portal in the standalone mode, make sure to deregister the email gateway manually before you join it to a
cluster.
Note To enable Cisco Cloud Services portal using the CLI, use the cloudserviceconfig command.
What to do next
Register your email gateway with the Cisco Cloud Services portal. For more information, go to
https://securex.us.security.cisco.com/settings/modules/available, navigate to the module to integrate with
Cisco SecureX, click Add New Module, and see the instructions on the page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
338
Integrating with Cisco SecureX Threat Response
Registering Email Gateway with Cisco Cloud Services Portal
Registering Email Gateway with Cisco Cloud Services Portal
Procedure
Step 1 Go to Networks > Cloud Service Settings.
Step 2 Enter the registration token under Cloud Services Settings and click Register.
Note To register your email gateway with or the Cisco Cloud Services portal using the CLI, use the
cloudserviceconfig command.
What to do next
Confirm Whether the Registration was Successful, on page 339
Confirm Whether the Registration was Successful
• On Security Services Exchange, confirm successful registration by reviewing the status in Security
Services Exchange.
• On Cisco SecureX, navigate to the Devices page and view the ESA that has been registered with Security
Services Exchange.
Note If you want to switch to another Cisco SecureX Threat Response server (for example, 'Europe -
api.eu.sse.itd.cisco.com'), you must first deregister your emal gateway from Cisco SecureX Threat Response
and follow steps mentioned in How to Integrate your Email Gateway with Cisco SecureX Threat Response,
on page 336.
After you have integrated your email gateway with Cisco SecureX Threat Response, you do not need to
integrate your Cisco Secure Manager Email and Web Gateway with Cisco SecureX Threat Response.
After successful registration of your email gateway on Security Services Excange, add the ESA Email module
on Cisco SecureX. For more information, go tohttps://securex.us.security.cisco.com/settings/modules/available,
navigate to the module to integrate with Cisco SecureX, click Add New Module, and see the instructions on
the page.
Enabling Cisco SecureX Threat Response on Email Gateway
Procedure
Step 1 Log in to your email gateway.
Step 2 Select Networks > Cloud Service Settings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
339
Integrating with Cisco SecureX Threat Response
Performing Threat Analysis using Cisco SecureX Ribbon
Step 3 Check the Enable check box under SecureX.
Step 4 Submit and commit your changes.
Performing Threat Analysis using Cisco SecureX Ribbon
Note When you upgrade from Cisco Secure Email Gateway 13.5.1 or earlier versions, Casebook will be part of
the Cisco SecureX Ribbon.
Cisco SecureX supports a distributed set of capabilities that unify visibility, enable automation, accelerate
incident response workflows, and improve threat hunting. These distributed capabilities are presented in the
form of applications (apps) and tools in the Cisco SecureX Ribbon.
This topic contains the following sections:
• Accessing the Cisco SecureX Ribbon, on page 340
• Adding Observable to Casebook for Threat Analysis using Cisco SecureX Ribbon and Pivot Menu, on
page 342
You will find the Cisco SecureX Ribbon at the bottom pane of the page, and it persists as you move between
the dashboard and other security products in your environment. Cisco SecureX Ribbon consists of the following
icons and elements:
• Expand/Collapse Ribbon
• Home
• Casebook App
• Incidents App
• Orbital App
• Enrichment Search Box
• Find Observables
• Settings
For more information on Cisco SecureX Ribbon, see https://securex.us.security.cisco.com/help/ribbon.
Accessing the Cisco SecureX Ribbon
Before you begin
Make sure that you meet all the prerequisites that are mentioned in Prerequisites, on page 337.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
340
Integrating with Cisco SecureX Threat Response
Accessing the Cisco SecureX Ribbon
Note Suppose you have already configured Casebook for Cisco Secure Email Gateway 13.5.1 or earlier versions.
You need to create a new Client ID and Client Secret in Cisco SecureX API client with additional scopes,
as mentioned in the following procedure.
You can drag the Cisco SecureX Ribbon, positioned at the bottom pane of the page, from right using
button.
Procedure
Step 1 Log in to the new web interface of your email gateway. For more information, see Accessing the Web-Based
Graphical User Interface (GUI), on page 38.
Step 2 Click the Cisco SecureX Ribbon.
Step 3 Create a Client ID and Client Secret in SecureX API Clients. For more information to generate API Client
credentials, see Creating an API Client.
While creating a client ID and client password, make sure that you choose the following scopes:
• casebook
• enrich:read
• global-intel:read
• inspect:read
• integration:read
• profile
• private-intel
• response
• registry/user/ribbon
• telemetry:write
• users:read
• orbital (if you have access)
Step 4 Enter the client ID and client password obtained in step 3 in the Login to use SecureX Ribbon dialog box
in your email gateway.
Step 5 Select the required Cisco SecureX server in the Login to use SecureX Ribbon dialog box.
Step 6 Click Authenticate.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
341
Integrating with Cisco SecureX Threat Response
Adding Observable to Casebook for Threat Analysis using Cisco SecureX Ribbon and Pivot Menu
Note If you want to edit the client ID, client password, and Cisco SecureX server, right-click on the Cisco
SecureX Ribbon, and add the details.
What to do next
Adding Observable to Casebook for Threat Analysis using Cisco SecureX Ribbon and Pivot Menu, on page
342
Adding Observable to Casebook for Threat Analysis using Cisco SecureX
Ribbon and Pivot Menu
Before you begin
Make sure that you obtain the client ID and client password to access the Cisco SecureX Ribbon and pivot
menu widgets on your email gateway. For more information, see Accessing the Cisco SecureX Ribbon, on
page 340.
Procedure
Step 1 Log in to the new web interface of your email gateway. For more information, see Accessing the Web-Based
Graphical User Interface (GUI), on page 38.
Step 2 Navigate to the Email Reporting page, click the pivot menu button next to the required observable (for
example, bit.ly).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
342
Integrating with Cisco SecureX Threat Response
Adding Observable to Casebook for Threat Analysis using Cisco SecureX Ribbon and Pivot Menu
Perform the following:
• Click button to add an observable to active case.
• Click button to add the observable to new case.
Note
Use the pivot menu button to pivot an observable to other devices registered on the portal (for
example, AMP for Endpoints) to investigate for threat analysis.
Step 3 Hover over icon and click button to open the Casebook. Check whether the observable is added to
a new or an existing case.
Step 4 (Optional) Click button to add a title, description, or notes to the Casebook.
Note You can search for observables for threat analysis in two different ways:
• Click the Enrichment search box from the Cisco SecureX Ribbon and
search for the observables.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
343
Integrating with Cisco SecureX Threat Response
Performing Remedial Actions on Messages in Cisco SecureX Threat Response
• Click the Casebook icon inside the Cisco SecureX Ribbon and search for the observables in the search
field.
For more information on Cisco SecureX Ribbon, see https://securex.us.security.cisco.com/help/ribbon.
Performing Remedial Actions on Messages in Cisco SecureX
Threat Response
In Cisco SecureX Threat Response, you can now investigate and apply the following remedial actions on
messages processed by your email gateway:
• Delete
• Forward
• Forward and Delete
Before you begin
Make sure you have met the following prerequisites before you perform remedial actions on messages in
Cisco SecureX Threat Response:
• Enabled and registered your email gateway with the Cisco SecureX server. For more information, see
How to Integrate your Email Gateway with Cisco SecureX Threat Response, on page 336.
• Added your email gateway module to Cisco SecureX and specified the Remediation Forwarding Address
in Cisco SecureX. For more information, go to https://securex.us.security.cisco.com/settings/modules/
available, navigate to the required Cisco Secure Email Gateway module to integrate with Cisco SecureX,
click Add New Module, and see the instructions on the page.
• Enabled and configured the remediation profiles in the System Administration > Account Settings page
in your email gateway. For more information, see Remediating Messages in Mailboxes, on page 577.
Procedure
Step 1 Log in to Cisco SecureX with your user credentials.
Step 2 Perform an investigation for threat analysis by entering required IOCs (for example, URLs, Email MessageID,
and so on) in the Investigate panel and click Investigate. For more information, see the Investigate topic in
the Help section at https://visibility.amp.cisco.com/help/investigate.
Step 3 Select the required message based on the investigation results using the corresponding Cisco Message ID or
Email MessageID . For more information, see the Investigate topic in the Help section at
https://visibility.amp.cisco.com/help/investigate.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
344
Integrating with Cisco SecureX Threat Response
Improving User Experience of Email Gateway using Cisco Success Network
Step 4 Click the pivot menu button next to the Cisco Message ID or Email MessageID and select the required
remedial action (for example, ‘Forward’). For more information, see the Investigate topic in the Help section
at https://visibility.amp.cisco.com/help/investigate
Improving User Experience of Email Gateway using Cisco
Success Network
Overview
You can use the Cisco Success Network (CSN) feature to send your email gateway and feature usage details
to Cisco. These details are used by Cisco to identify the email gateway version and the features activated but
not enabled on your email gateway.
The ability to send your email gateway and feature usage details to Cisco helps an organization to:
• Improve the effectiveness of the product in user networks by performing analytics on collected telemetry
data and suggesting users with recommendations using a digital campaign.
• Improve user experience with email gateway.
The following table shows a sample data of email gateway and feature usage details sent to Cisco:
Statistics Sample Data
Email Gateway Details
UID 4215XXXXXXXXXXXXXXXX-XXXXXXXXXXXX
Model C100V
sIVAN Email Gateway (for a smart license) or null (for a
classic license
Deployment Cluster/Standalone.
userAccountID Enter SLPIID (in smart license) or VLNID (in classic
license).
Version 1X.X.X-XXX
Install Date 1582535814000 (milli-seconds since epoch)
Feature Information
Name Email Gateway Feature
Enabled Yes
Status In Compliance
Expiry Date 1831591683 (seconds since epoch)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
345
Integrating with Cisco SecureX Threat Response
Enabling CSN on Email Gateway
Statistics Sample Data
Feature ID a4deXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Related Topics
• Enabling CSN on Email Gateway, on page 346
• Disabling CSN on Email Gateway, on page 346
Enabling CSN on Email Gateway
Before you begin
Make sure that you enable and register your email gateway with the Cisco Cloud Service Portal. For more
information, see How to Integrate your Email Gateway with Cisco SecureX Threat Response, on page 336.
Procedure
Step 1 Go to Security Services > Cloud Service Settings.
Step 2 Click Edit Global Settings.
Step 3 Check the Enable checkbox under Cisco Success Network.
Step 4 Submit and commit your changes.
Disabling CSN on Email Gateway
Procedure
Step 1 Go to Security Services > Cloud Service Settings.
Step 2 Click Edit Global Settings.
Step 3 Uncheck the the Enable checkbox under Cisco Success Network.
Step 4 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
346
CHAPTER 15
Configuring Email Gateway to Safe Print
Message Attachments
This chapter contains the following sections:
• Overview , on page 347
• How to Configure Email Gateway to Safe Print Message Attachments, on page 348
• Configuring Safe Print Settings on Email Gateway, on page 348
• Configuring Content Filter to Safe Print Message Attachments, on page 349
• Attaching Content Filter to Incoming Mail Policy, on page 351
• Safe Print Settings and Clusters, on page 352
• Monitoring Messages with Safe-Printed Attachments, on page 352
• Viewing Logs, on page 352
• Displaying Safe Print Details in Message Tracking, on page 353
Overview
You can configure your email gateway to provide a safe view (safe-printed PDF version) of a message
attachment detected as malicious or suspicious. The safe view of the message attachment is delivered to the
end user and the original attachment is stripped from the message. You can use the 'Safe Print' content filter
action to safe print all message attachments that match a configured content filter condition.
The ability to safe print message attachments in the email gateway helps an organization to:.
• Prevent message attachments with malicious or suspicious content from entering an organization network.
• View malicious or suspicious message attachments without being affected by the malware.
• Deliver the original message attachment based on the end-user request.
The following languages are supported for the Safe-Print feature - English, Italian, Portuguese, Spanish,
German, French, Japanese, Chinese (PRC and Taiwan), Russian, and Korean.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
347
Configuring Email Gateway to Safe Print Message Attachments
How to Configure Email Gateway to Safe Print Message Attachments
How to Configure Email Gateway to Safe Print Message
Attachments
Steps Do This More Information
Step 1 Configure safe print settings on the Configuring Safe Print Settings on
email gateway. Email Gateway, on page 348
Step 2 Configure a content filter to safe Configuring Content Filter to Safe
print message attachments. Print Message Attachments, on
page 349
Step 3 Attach the content filter that you Attaching Content Filter to
configured to safe print message Incoming Mail Policy, on page 351
attachments to an incoming mail
policy.
Configuring Safe Print Settings on Email Gateway
Procedure
Step 1 Click Security Services > Scan Behavior.
Step 2 Click Edit Global Settings.
Step 3 Enter the required parameters described in the following table to configure safe print settings on the email
gateway.
Parameter Source Details Description
Safe Print Settings
Maximum File Size Enter the maximum attachment size for a safe-printed attachment.
Note Make sure that the 'Maximum File Size' value does
not exceed the 'Maximum attachment size to scan'
value configured in the Scan Behavior > Global
Settings page.
Note If the ‘Maximum File Size’ value exceeds the
'Maximum Message Size to Scan' value configured
for Outbreak Filters on your email gateway, then the
message and the message attachment is not scanned
by Outbreak Filters in the email pipeline.
Maximum Page Count Enter the maximum number of pages that you want to safe print
in a message attachment.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
348
Configuring Email Gateway to Safe Print Message Attachments
Configuring Content Filter to Safe Print Message Attachments
Parameter Source Details Description
Document Quality Select the Use Default Value (70) option to use the
recommended image quality value for a safe-printed attachment.
Note You can also select the Enter Custom Value option
and enter a custom image quantity value for a
safe-printed attachment.
File Type Selection Select the required file types from the appropriate file groups
(for example, “Microsoft Documents”) that you can use to safe
print a message attachment.
Watermark Select Enabled option to add a watermark to a safe-printed
attachment.
Note You can enter a custom text for the watermark in the
Enter Custom Text: field.
Cover Page Select Enabled option to add a cover page to a safe-printed
attachment.
Note You can enter a custom text for the cover page in the
Enter Custom Text field.
Step 4 Submit and commit your changes.
What to do next
Configure a content filter to safe print a message attachment. For more information, see Configuring Content
Filter to Safe Print Message Attachments, on page 349.
Configuring Content Filter to Safe Print Message Attachments
Use the 'Safe Print' content filter action to safe print a message attachment
You can use the Safe Print content filter action in any one of the following ways::
• Safe print matching attachments option
• Safe print all attachments option
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
349
Configuring Email Gateway to Safe Print Message Attachments
Configuring Content Filter to Safe Print Message Attachments
Table 37:
Safe Print Action Option Usage Example Supported Content Filter
Conditions
Safe print matching Use the ‘Safe print Configure the ‘Macro The following are the
attachments matching attachments’ Detection’ content filter content filter conditions
option to safe print all condition and select the that you can only use with
message attachments that 'Safe Print Matching the ‘Safe print matching
match a configured Attachments' option. attachments’ option:
content filter condition.
If an incoming message • URL Reputation
contains three message
attachments - 'docx1,' • URL Category
'docx2,' and 'docx3' and • Macro Detection
the email gateway detects
a macro in 'docx1,' then • Attachment Content
only 'docx1' is
• Attachment File Info
safe-printed.
Safe print all attachments Use the ‘Safe print all Configure the ‘Envelope You can use any one of
attachments’ option to Sender’ content filter the content filter
safe print all message condition and select the conditions available in
attachments when the 'Safe Print all attachments' your email gateway with
configured content filter option. the ‘Safe print all
condition is true. attachments’ option.
If an incoming message
from a sender
'[email protected]'
contains three message
attachments - 'docx1,'
'docx2,' and 'ppt1' then all
the message attachments
-'docx1,' 'docx2,' and
'ppt1' are safe-printed
based on the following:
• File types selected in
theScan Behavior >
Safe Print Settings
page.
• The
[email protected]
sender matches the
LDAP group
directory configured
in the ‘Envelope
Sender’ content filter
condition.
As an example, use the following procedure to safe print message attachments that contain macros using the
'Macro Detection' condition and 'Safe Print' action.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
350
Configuring Email Gateway to Safe Print Message Attachments
Attaching Content Filter to Incoming Mail Policy
Before you begin
Make sure that you have configured safe print settings on the email gateway. See Configuring Safe Print
Settings on Email Gateway, on page 348
Procedure
Step 1 Go to Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 Enter a name and description for the content filter.
Step 4 Click Add Condition.
Step 5 Click Macro Detection.
Step 6 Select the file types that you want the email gateway to detect for macros and click Add.
Step 7 Click OK.
Step 8 Click Add Action.
Step 9 Click Safe Print.
Step 10 Select any one of the following actions to take on message attachments:
• Select Safe print matching attachments option to safe print all message attachments that match the
configured Macro Detection content filter condition.
• Select Safe print all attachments option to safe print all message attachments when the configured
Macro Detection content filter condition is true
Step 11 Select Yes to strip a message attachment that is marked as unscannable.
A message attachment is marked as unscannable due to any one of the following reasons:
• Message contains an attachment that is encrypted.
• Message contains an attachment that is corrupt.
• I/O error occurs when performing a safe print action on the message attachment.
• Timeout error occurs when performing a safe print action on the message attachment.
Note By default, a system generated message is added as an attachment text file when an attachment is
unscannable. You can enter a custom message in the Custom Replacement Message field.
Step 12 Click OK.
Step 13 Submit and commit your changes.
Attaching Content Filter to Incoming Mail Policy
You can attach the content filter that you configured to safe print a message attachment to an incoming mail
policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
351
Configuring Email Gateway to Safe Print Message Attachments
Safe Print Settings and Clusters
Procedure
Step 1 Go to Mail Policies > Incoming Mail Policies.
Step 2 Click the link below Content Filters.
Step 3 Make sure to select 'Enable Content Filters (Customize Settings).'
Step 4 Select the content filter that you created to safe print a message attachment.
Step 5 Submit and commit your changes.
Safe Print Settings and Clusters
If you use centralized management, you can configure safe print settings on the email gateway and mail
policies at the cluster, group, and machine level.
Monitoring Messages with Safe-Printed Attachments
You can use the Safe Print report page to view:
• Number of safe-printed attachments based on the file type in graphical format.
• Summary of safe-printed attachments based on the file type in tabular format.
In the ‘Summary of Safe Print File Types’ section, click the total number of safe-printed attachments to view
the message details in Message Tracking.
Viewing Logs
The log information about safe print is posted to the Mail Logs. Most information is at the Info or Debug
level.
Examples of Safe Print Log Entries
The safe print information is posted to the Mail Logs. Most information is at the Info or Debug level.
• I/O Errors
• Unable to Create Temporary Directory, on page 353
• Unable to Create Safe-printed PDF Attachment, on page 353
• Corrupt File, on page 353
• Encrypted File, on page 353
• Timeout Error, on page 353
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
352
Configuring Email Gateway to Safe Print Message Attachments
Unable to Create Temporary Directory
Unable to Create Temporary Directory
In this example, the log shows that a message attachment was not safe-printed because your email gateway
was unable to create a temporary directory to save the file.
Sat Jul 20 05:53:48 2019 Info: MID 5 Unable to safe print the attachment,
Filename:test_file.docx, Reason: IO error occurred during safeprinting of the attachment
Sat Jul 20 05:53:48 2019 Trace: MID 5 Unable to safe print the attachment,
Filename:test_file.docx, Exception: Unable to create tmp directory for safeprinting document:
[Errno 2] No such file or directory: '/tmp/test_file.docx'
Unable to Create Safe-printed PDF Attachment
In this example, the log shows that a message attachment was not safe-printed because your email gateway
was unable to create a safe-printed PDF attachment.
Thu Jul 11 07:19:01 2019 Info: MID 132 Unable to safe print the attachment,
Filename:test_file.docx, Reason: IO error occurred during safeprinting of the attachment
Thu Jul 11 07:19:01 2019 Trace: MID 132 Unable to safe print the attachment,
Filename:test_file.docx, Exception: Error while creating safeprinted PDF document:
[Errno 2] No such file or directory: '/tmp/test_file.docx/safe_print_test_file.pdf'
Corrupt File
In this example, the log shows that a message attachment was not safe-printed because the file was corrupt
Thu Jul 11 08:34:31 2019 Info: MID 142 Unable to safe print the attachment,
Filename:corrupt_file=20(1).docx, Reason: The attachment is corrupted
Encrypted File
In this example, the log shows that a message attachment was not safe-printed because the file was encrypted.
Thu Jul 11 08:34:31 2019 Info: MID 142 Unable to safe print the attachment,
Filename:sept_subscription.pdf, Reason: The attachment is encrypted.
Timeout Error
In this example, the log shows that a message attachment was not safe-printed because of a timeout error.
Thu Jul 11 10:32:29 2019 Info: MID 165 Unable to safe print the attachment,
Filename:20_page.docx, Reason: A timeout error occurred when trying to safe print the
attachment
Displaying Safe Print Details in Message Tracking
Use Message Tracking to view the details of messages that contain safe-printed attachments.
Before you begin
• Make sure that you enable the Message Tracking feature on the email gateway. To enable Message
Tracking, go to Security Services > Message Tracking page in the legacy web interface of your email
gateway.
• Content filters configured to safe print message attachments are operational.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
353
Configuring Email Gateway to Safe Print Message Attachments
Displaying Safe Print Details in Message Tracking
Procedure
Step 1 [New Web Interface only] Go to Tracking > Message Tracking.
OR
[Legacy Web interface only] Go to Monitor > Message Tracking.
Step 2 [New Web Interface] Click Advanced Search.
OR
[Legacy Web interface only] Click Advanced.
Step 3 Check Safe Print under Message Event to view the details of messages that contain safe-printed attachments.
Step 4 Enter the required search options and click Search.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
354
CHAPTER 16
Integrating Email Gateway with Cisco Secure
Awareness Cloud Service
This chapter contains the following sections:
• Overview, on page 355
• How to Integrate Email Gateway with Cisco Secure Awareness Cloud Service, on page 356
• Creating Cisco Secure Awareness Cloud Service Account, on page 357
• Configuring Firewall Settings to Access Cisco Secure Awareness Cloud Service, on page 357
• Creating Sender Group to Allow Simulated Phishing Messages in Email Gateway, on page 358
• Obtaining Authentication Token from Cisco Secure Awareness Cloud Service, on page 359
• Enabling Cisco Secure Awareness Cloud Service on Email Gateway, on page 360
• Create Custom Incoming Mail Policy for End Users Categorized as Repeat Clickers, on page 360
• Cisco Secure Awareness Cloud Service and Clusters, on page 361
• Viewing Logs, on page 361
• Viewing Alerts, on page 363
Overview
The Cisco Secure Awareness cloud service allows you to effectively deploy phishing simulations, awareness
training, or both to measure and report results. It empowers the security operations team to focus on real-time
threats and not end-user mitigation.
The Cisco Secure Awareness cloud service provides reports of repeat clickers - users who repeatedly click
on any URL or attachment in messages. These users are identified via a phishing simulation campaign defined
by the Cisco Secure Awareness cloud service.
For more information on the Cisco Secure Awareness cloud service, see https://secat.cisco.com.
You can integrate your email gateway with the Cisco Secure Awareness cloud service to:
• Improve end-user awareness towards real-world phishing attacks.
• Allow email administrators to configure stringent policies for users identified as repeat clickers.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
355
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
How to Integrate Email Gateway with Cisco Secure Awareness Cloud Service
How to Integrate Email Gateway with Cisco Secure Awareness
Cloud Service
Perform these steps in order:
Steps Do This More Information
Step 1 [On Cisco Secure Awareness] Creating Cisco Secure Awareness
Create a Cisco Security Awareness Cloud Service Account, on page
cloud service account for your 357
organization based on your region.
Step 2 Configure firewall settings to allow Configuring Firewall Settings to
your email gateway to access the Access Cisco Secure Awareness
Cisco Secure Awareness cloud Cloud Service, on page 357
service.
Step 3 Create a new sender group to allow Creating Sender Group to Allow
simulated phishing messages from Simulated Phishing Messages in
the Cisco Secure Awareness cloud Email Gateway, on page 358
service in your email gateway.
Step 4 [On Cisco Secure Awareness] See the CSA Administrator Guide
Create a new user in the Cisco at:
Secure Awareness cloud service to
• https://secat.cisco.com/portal/Support
identify repeat clickers.
[applicable for Americas
: users]
• https://secat-eu.cisco.com/portal/Support
[applicable for European
Union (EU) users]
Step 5 [On Cisco Secure Awareness] See the CSA Administrator Guide
Create simulated phishing messages at:
in the Cisco Secure Awareness
• https://secat.cisco.com/portal/Support
cloud service and send them to the
[applicable for Americas
end users in your organization. This
users]
process is used to track the end
users who repeatedly click on any • https://secat-eu.cisco.com/portal/Support
attachment or URL in messages. [applicable for European
Union (EU) users]
Step 6 Obtain the authentication token Obtaining Authentication Token
from the Cisco Secure Awareness from Cisco Secure Awareness
cloud service. Cloud Service, on page 359
Step 7 Enable the Cisco Secure Awareness Enabling Cisco Secure Awareness
cloud service on your email Cloud Service on Email Gateway,
gateway. on page 360
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
356
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
Creating Cisco Secure Awareness Cloud Service Account
Steps Do This More Information
Step 8 Create a custom incoming mail Create Custom Incoming Mail
policy to configure aggressive mail Policy for End Users Categorized
policies for end users categorized as Repeat Clickers, on page 360
as repeat clickers.
Creating Cisco Secure Awareness Cloud Service Account
Depending on your region, create a Cisco Secure Awareness cloud service account with admin acess rights
for your organization using one of the following URLs:
• https://secat.cisco.com [applicable for Americas users]
• https://secat-eu.cisco.com [applicable for European Union (EU) users]
What to do Next
Configure firewall settings to connect your email gateway to the Cisco Secure Awareness cloud service. For
more information, see Configuring Firewall Settings to Access Cisco Secure Awareness Cloud Service, on
page 357
Configuring Firewall Settings to Access Cisco Secure
Awareness Cloud Service
You must open HTTPS (Out) 443 port on the firewall for the following hostnames or IP addresses (refer to
the table below) to connect your email gateway to the Cisco Secure Awareness cloud service.
Service Americas European Union
Hostname IP Address Hostname IP Address
Cisco Secure secat.cisco.com 52.242.31.199 secat-eu.cisco.com 40.127.163.97
Awareness
cloud service
Course - 167.89.98.161 -
Notification
(Outbound)
Landing and - 52.242.31.199 - 40.127.163.97
Feedback Pages
(Outbound)
Email - -
Attachment
(Outbound)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
357
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
Creating Sender Group to Allow Simulated Phishing Messages in Email Gateway
Note The IP addresses listed in the above table may change. For the latest list of IP addresses, see the ‘IP Allowlist
Guide’ on the Cisco Secure Awareness cloud service at
https://secat.cisco.com/portal/Support/IpWhitelistingGuide
What to do Next
Create a new sender group to allow simulated phishing messsages from the Cisco Secure Awareness cloud
service in your email gateway. For more information, see Creating Sender Group to Allow Simulated Phishing
Messages in Email Gateway, on page 358
Creating Sender Group to Allow Simulated Phishing Messages
in Email Gateway
You must create a new sender group to allow simulated phishing messages from the Cisco Secure Awareness
cloud service in your email gateway.
Before you begin
Make sure you have configured the firewall settings to allow your email gateway to access the Cisco Secure
Awareness cloud service. For more information, see Configuring Firewall Settings to Access Cisco Secure
Awareness Cloud Service, on page 357
Procedure
Step 1 Click Mail Policies > HAT Overview.
Step 2 Click Add Sender Group.
Step 3 Enter a name for the sender group.
Step 4 Select the priority order as 1.
Step 5 Select the policy as CYBERSEC_AWARENESS_ALLOWED.
Step 6 Check the SBRS to Not in Use checkbox to disable IP Reputation filtering.
Step 7 Click Submit and Add Senders.
Step 8 Add any one of the following Cisco Secure Awareness cloud service IP addresses to configure as the sender
IP address based on your region:
• Americas - 207.200.3.14 or 173.244.184.143
• European Union (EU) - 77.32.150.153
Note The Cisco Secure Awareness cloud service IP addresses are used to prevent your email gateway
from interpreting simulated phishing messages as actual phish..
Step 9 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
358
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
Obtaining Authentication Token from Cisco Secure Awareness Cloud Service
What to do next
1. Create a new user in the Cisco Secure Awareness cloud service to identify repeat clickers.
2. Create simulated phishing messages in the Cisco Secure Awareness cloud service and send them to the
end users in your organization.
For more information on how to complete the above two tasks, see the CSA Administrator Guide at:
• https://secat.cisco.com/portal/Support [applicable for Americas users]
• https://secat-eu.cisco.com/portal/Support [applicable for European Union (EU) users]
3. Obtain an authentication token from the Cisco Secure Awareness cloud service to download the Repeat
Clickers list from the Cisco Secure Awareness cloud service. For more information, see Obtaining
Authentication Token from Cisco Secure Awareness Cloud Service, on page 359
Obtaining Authentication Token from Cisco Secure Awareness
Cloud Service
You must obtain an authentication token from the Cisco Secure Awareness cloud service and use it to download
the Repeat Clickers list from the Cisco Secure Awareness cloud service.
Before you begin
Make sure that you have an account in the Cisco Secure Awareness cloud service with admin access rights.
For more information, see Creating Cisco Secure Awareness Cloud Service Account, on page 357. If you are
unable to access the Cisco Secure Awareness cloud service, contact Cisco Support for assistance.
Procedure
Step 1 Log in to the Cisco Secure Awareness cloud service.
Step 2 Go to Environment > Setttings
Step 3 Click the Report API tab.
Step 4 Check the Enable Report API check box .
Step 5 Copy the authentication token.
Use this authentication token to download the Repeat Clickers list from the Cisco Secure Awareness cloud
service.
What to do next
Enable the Cisco Secure Awareness cloud service on your email gateway. For more information, see Enabling
Cisco Secure Awareness Cloud Service on Email Gateway, on page 360
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
359
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
Enabling Cisco Secure Awareness Cloud Service on Email Gateway
Enabling Cisco Secure Awareness Cloud Service on Email
Gateway
Before you begin
Make sure you have:
• A valid account in the Cisco Secure Awareness cloud service with admin access rights.
• Obtained a valid authentication token from the Cisco Secure Awareness cloud service. For more
information, see Obtaining Authentication Token from Cisco Secure Awareness Cloud Service, on page
359,
Procedure
Step 1 Go to Security Services > Cisco Secure Awareness.
Step 2 Click Enable.
Step 3 Check the Enable Cisco Secure Awareness check box .
Step 4 Choose the required server to connect your email gateway to the Cisco Secure Awareness cloud service.
Step 5 Enter the authentication token obtained from the Cisco Secure Awareness cloud service.
Step 6 [Optional] Enter the polling interval to download the Repeat Clickers list from the Cisco Secure Awareness
cloud service.
Step 7 Submit and commit your changes.
What to do next
• After you enable the Cisco Secure Awareness cloud service, the email gateway automatically downloads
the Repeat Clickers list from the Cisco Secure Awareness cloud service. You can view the number of
repeat clicker users in the Repeat Clickers list by navigating to Security Services > Cisco Secure
Awareness > Repeat Clickers List Settings section in the web interface of your email gateway. For
more information about the Repeat Clickers list, log in to the Cisco Secure Awareness cloud service and
navigate to Analytics > Standard Reports > Phishing Simulations > Repeat Clickers section.
• Create a custom incoming mail policy to configure aggressive mail policies for end users categorized as
repeat clickers. For more information, see Create Custom Incoming Mail Policy for End Users Categorized
as Repeat Clickers, on page 360
Create Custom Incoming Mail Policy for End Users Categorized
as Repeat Clickers
You must create a custom incoming mail policy to configure aggressive mail policies for end users categorized
as repeat clickers.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
360
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
Cisco Secure Awareness Cloud Service and Clusters
Procedure
Step 1 Go to Mail Policies > Incoming Mail Policies.
Step 2 Click Add Policy.
Step 3 Enter a name for the policy.
Step 4 Check Add User.
Step 5 Select Following Recipients.
Step 6 Check the Include Repeat Clicker List checkbox to include the list of recipients categorized as repeat
clickers by the Cisco Secure Awareness cloud service.
Step 7 Click OK.
Step 8 Click Submit.
Step 9 Configure the required service engines (for example, Anti-Virus, Graymail, and so on) for the mail policy.
Step 10 Commit your changes.
Cisco Secure Awareness Cloud Service and Clusters
If you use centralized management, you can enable the Cisco Secure Awareness cloud service at the cluster,
group, and machine level. If you have enabled your email gateway with the Cisco Secure Awareness cloud
service in standalone mode, you can choose to join a cluster registered with the Cisco Secure Awareness cloud
service.
Note When you disable the Cisco Secure Awareness cloud service at the machine level, it is disabled only for the
logged-in email gateway while the other machines in the cluster are still connected to the Cisco Secure
Awareness cloud service.
Viewing Logs
The Cisco Secure Awareness cloud service information is posted to the Mail Logs. Most information is at the
Info or Debug level.
Examples of Cisco Secure Awareness Log Entries:
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because of an invalid token.
Tue Oct 13 10:12:59 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Secure Awareness cloud service failed because
of an invalid token.
Solution: Make sure you obtain a valid authentication token from the Cisco Secure Awareness cloud
service.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
361
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
Viewing Logs
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because of a connection error.
Wed Oct 14 10:59:36 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Secure Awareness cloud service failed because
of a connection error.
Solution: Verify the firewall configuration settings used to connect your email gateway to the Cisco
Secure Awareness cloud service.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because of an internal server error.
Wed Oct 14 10:59:36 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Secure Awareness cloud service failed because
of an internal server error.
Solution: Contact Cisco Support for technical assistance.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because the SSL certificate verification failed.
Wed Oct 14 11:02:46 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Secure Awareness cloud service failed because
the SSL certificate verification failed.
Solution: Add the required CA certificate of the proxy server in the custom certificate authority list of
your email gateway.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because the proxy authentication failed.
Wed Oct 14 11:09:48 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Secure Awareness cloud service failed
because the proxy authentication failed.
Solution: Check whether the proxy server is configured with the correct authentication credentials in
your email gateway.
• In this example, the log shows that a request to the Cisco Secure Awareness cloud service failed because
the Report API was not enabled on the Cisco Secure Awareness cloud service.
Mon Aug 17 15:35:42 2020 Warning: CSA:
The download of the Repeat Clickers list failed.
A request to the CSA cloud service failed because
the Report API was not enabled on the CSA cloud service
Solution: Check the Enable Report API check box in Environment > Settings > Report API tab of the
Cisco Secure Awareness cloud service.
• In this example, the log shows that the Cisco Secure Awareness feature expires on a particular date.
2020-10-15 08:00:11,968 INFO csa The Cisco Secure
Awareness feature expires on 2029-12-28T23:59:59Z. You need to
contact your Cisco Account Manager to renew the license.
Solution: Contact your Cisco Account Manager to renew the license.
• In this example, the log shows that the Cisco Secure Awareness feature license has expired, and the
feature is disabled on your email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
362
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
Viewing Alerts
2020-10-27 13:33:21,714 CRITICAL csa The Cisco Secure
Awareness feature license has expired, and the feature is
disabled on your email gateway. Contact your Cisco Account Manager
to renew the license.
Solution: Contact your Cisco Account Manager to renew the license.
• In this example, the log shows that the downloaded Repeat Clickers list is empty.
Tue Oct 13 10:10:18 2020 Info: CSA: The downloaded
Repeat Clickers list is empty.
Solution: Create simulated phishing messages in the Cisco Secure Awareness cloud service and send
them to the recipients in your organization.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because you have reached the maximum number of download attempts.
Fri Oct 16 05:22:08 2020 Warning: CSA: The download
of the Repeat Clickers list from the Cisco Secure Awareness
cloud service failed because you have reached the maximum
number of attempts.
Solution: Contact Cisco Support to increase the number of attempts to download the Repeat Clickers
list from the Cisco Secure Awareness cloud service.
Viewing Alerts
The following table lists the system alerts generated for the Cisco Secure Awareness cloud service, including
a description of the alert and the alert severity.
Component/Alert Name Message and Description Parameters
MAIL.CSA.DOWNLOAD Alert text: The download of the Parameters: reason
Repeat Clickers list from the Cisco
_FAILURE reason - Reason for the failure to
Secure Awareness cloud service
download repeat clickers list from
failed. $reason.
Cisco Secure Awareness cloud
Alert level: WARNING. service.
Description: Alert is sent when the For example: ‘invalid token,’
download of the Repeat Clickers ‘reached the maximum number of
list from the Cisco Secure attempts,’ and so on.
Awareness cloud service fails.
MAIL.CSA.EMPTY_ Alert text: The downloaded Repeat N/A.
Clickers list is empty.
EMAIL_LIST
Alert level: INFO.
Description: Alert is sent when the
downloaded Repeat Clickers list is
empty. This alert indicates that
there are no Repeat Clickers listed
in the Cisco Secure Awareness
cloud service.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
363
Integrating Email Gateway with Cisco Secure Awareness Cloud Service
Viewing Alerts
Component/Alert Name Message and Description Parameters
MAIL.CSA.LICENSE_ Alert text: The Cisco Secure Parameters: expiry, region, server
Awareness feature license expires
EXPIRING expiry – The date on which the
on $expiry. You must contact your
Cisco Secure Awareness license is
Cisco Account Manager to renew
expiring.
the license.
region – The region of the Cisco
Region: $region
Secure Awareness license which is
Server: $server expiring. The region can be
AMERICAS, EUROPE, and so on.
Alert level: INFO
server – The name of the server
Description: Alert is sent on 7 days
URL, for
prior to expiry, 3 days prior to
example,https://secat.cisco.com.
expiry and 1 day prior to expiry.
MAIL.CSA.LICENSE_ Alert text: The Cisco Secure Parameters: region, server
Awareness feature license has
EXPIRED region – Region of the Cisco Secure
expired, and the feature is disabled
Awareness license which has
on your email gateway. Contact
expired. The region can be
your Cisco Account Manager to
AMERICAS, EUROPE, and so on.
renew the license.
server – Name of the server URL,
Region: $region
for example,
Server: $server https://secat.cisco.com.
Alert Level: Critical
Description: Alert is sent on expiry
of the Cisco Secure Awareness
license.
MAIL.CSA.LICENSE_ Alert text: The retrieval of the Parameters: reason
license expiry details from the
RETRIVAL_FAILURE reason – Reason for the failure to
Cisco Secure Awareness cloud
retrieve the license expiry details
service failed $reason
from the Cisco Secure Awareness
Alert level: WARNING cloud service.
Description: Alert is sent on failure For example: ‘invalid token’, and
to retrieve license expiry details ‘reached the maximum number of
from Cisco Secure Awareness attempts.’
cloud service for three consecutive
times. Every day one attempt is
made to retrieve the license expiry
details until the license expiry
details are retrieved successfully.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
364
CHAPTER 17
Anti-Virus
This chapter contains the following sections:
• Anti-Virus Scanning Overview, on page 365
• Sophos Anti-Virus Filtering, on page 366
• McAfee Anti-Virus Filtering, on page 369
• How to Configure the Email Gateway to Scan for Viruses , on page 370
• Sending an Email to the Email Gateway to Test Anti-Virus Scanning , on page 379
• Updating Virus Definitions, on page 381
Anti-Virus Scanning Overview
The email gateway includes integrated virus scanning engines from third party companies Sophos and McAfee.
You can obtain license keys for the email gateway to scan messages for viruses using one or both of these
virus scanning engines, and then configure your email gateway to scan for viruses using either anti-virus
scanning engine.
The McAfee and Sophos engines contain the program logic necessary to scan files at particular points, process
and pattern-match virus definitions with data they find in your files, decrypt and run virus code in an emulated
environment, apply heuristic techniques to recognize new viruses, and remove infectious code from legitimate
files.
You can configure the email gateway to scan messages for viruses (based on the matching incoming or
outgoing mail policy), and, if a virus is found, to perform different actions on the message (including “repairing”
the message of viruses, modifying the subject header, adding an additional X-header, sending the message to
an alternate address or mailhost, archiving the message, or deleting the message).
If enabled, virus scanning is performed in the “work queue” on the email gateway, immediately after Anti-Spam
scanning. (See Email Pipeline and Security Services, on page 70.)
By default, virus scanning is enabled for the default incoming and outgoing mail policies.
Related Topics
• Evaluation Key, on page 366
• Scanning Messages with Multiple Anti-Virus Scanning Engines, on page 366
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
365
Anti-Virus
Evaluation Key
Evaluation Key
Your email gateway ships with a 30-day evaluation key for each available anti-virus scanning engine. You
enable the evaluation key by accessing the license agreement in the System Setup Wizard or Security Services
> Sophos/McAfee Anti-Virus pages (in the GUI) or running the antivirusconfig or systemsetup commands
(in the CLI). Once you have accepted the agreement, the Anti-Virus scanning engine will be enabled, by
default, for the default incoming and outgoing mail policies. For information on enabling the feature beyond
the 30-day evaluation period, contact your Cisco sales representative. You can see how much time remains
on the evaluation via the System Administration > Feature Keys page or by issuing the featurekey command.
(For more information, see Feature Keys, on page 1008.)
Scanning Messages with Multiple Anti-Virus Scanning Engines
AsyncOS supports scanning messages with multiple anti-virus scanning engines — multi-layer anti-virus
scanning. You can configure your email gateway to use one or both of the licensed anti-virus scanning engines
on a per mail policy basis. You could create a mail policy for executives, for example, and configure that
policy to scan mail with both Sophos and McAfee engines.
Scanning messages with multiple scanning engines provides “defense in depth” by combining the benefits of
both Sophos and McAfee anti-virus scanning engines. Each engine has leading anti-virus capture rates, but
because each engine relies on a separate base of technology (discussed in McAfee Anti-Virus Filtering, on
page 369 and Sophos Anti-Virus Filtering, on page 366) for detecting viruses, the multi-scan approach can be
even more effective. Using multiple scanning engines can lead to reduced system throughput, please contact
your Cisco support representative for more information.
You cannot configure the order of virus scanning. When you enable multi-layer anti-virus scanning, the
McAfee engine scans for viruses first, and the Sophos engine scans for viruses second. If the McAfee engine
determines that a message is virus-free, the Sophos engine scans the message, adding a second layer of
protection. If the McAfee engine determines that a message contains a virus, the email gateway skips Sophos
scanning and performs actions on the virus message based on settings you configured.
Sophos Anti-Virus Filtering
The email gateway includes integrated virus-scanning technology from Sophos, Plc. Sophos Anti-Virus
provides cross-platform anti-virus protection, detection and disinfection.
Sophos Anti-Virus provides a virus detection engine that scans files for viruses, Trojan horses, and worms.
These programs come under the generic term of malware , meaning “malicious software.” The similarities
between all types of malware allow anti-virus scanners to detect and remove not only viruses, but also all
types of malicious software.
Related Topics
• Virus Detection Engine, on page 367
• Virus Scanning, on page 367
• Detection Methods, on page 367
• Virus Descriptions, on page 368
• Sophos Alerts , on page 368
• When a Virus is Found, on page 368
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
366
Anti-Virus
Virus Detection Engine
Virus Detection Engine
The Sophos virus detection engine lies at the heart of the Sophos Anti-Virus technology. It uses a proprietary
architecture similar to Microsoft’s COM (Component Object Model), consisting of a number of objects with
well-defined interfaces. The modular filing system used by the engine is based on separate, self-contained
dynamic libraries each handling a different “storage class,” for example, file type. This approach allows virus
scanning operations to be applied on generic data sources, irrespective of type.
Specialized technology for loading and searching data enables the engine to achieve very fast scanning speeds.
Incorporated within it are:
• A full code emulator for detecting polymorphic viruses
• An on-line decompressor for scanning inside archive files
• An OLE2 engine for detecting and disinfecting macro viruses
The email gateway integrates with the virus engine using SAV Interface.
Virus Scanning
In broad terms, the engine’s scanning capability is managed by a powerful combination of two important
components: a classifier that knows where to look, and the virus database that knows what to look for. The
engine classifies the file by type rather than by relying on the extension.
The virus engine looks for viruses in the bodies and attachments of messages received by the system; an
attachment’s file type helps determine its scanning. For example, if a message’s attached file is an executable,
the engine examines the header which tells it where the executable code starts and it looks there. If the file is
a Word document, the engine looks in the macro streams. If it is a MIME file, the format used for mail
messaging, it looks in the place where the attachment is stored.
Detection Methods
How viruses are detected depends on their type. During the scanning process, the engine analyzes each file,
identifies the type, and then applies the relevant technique(s). Underlying all methods is the basic concept of
looking for certain types of instructions or certain ordering of instructions.
Related Topics
• Pattern Matching, on page 367
• Heuristics, on page 368
• Emulation, on page 368
Pattern Matching
In the technique of pattern matching, the engine knows the particular sequence of code and is looking for an
exact match that will identify the code as a virus. More often, the engine is looking for sequences of code that
are similar, but not necessarily identical, to the known sequences of virus code. In creating the descriptions
against which files are compared during scanning, Sophos virus researchers endeavor to keep the identifying
code as general as possible so that – using heuristics, as explained below – the engine will find not just the
original virus but also its later derivatives.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
367
Anti-Virus
Heuristics
Heuristics
The virus engine can combine basic pattern matching techniques with heuristics – a technique using general
rather than specific rules – to detect several viruses in the same family, even though Sophos researchers might
have analyzed only one virus in that family. The technique enables a single description to be created that will
catch several variants of one virus. Sophos tempers its heuristics with other methods, minimizing the incidence
of false positives.
Emulation
Emulation is a technique applied by the virus engine to polymorphic viruses. Polymorphic viruses are encrypted
viruses that modify themselves in an effort to hide themselves. There is no visible constant virus code and
the virus encrypts itself differently each time it spreads. When it runs, it decrypts itself. The emulator in the
virus detection engine is used on DOS and Windows executables, while polymorphic macro viruses are found
by detection code written in Sophos’s Virus Description Language.
The output of this decryption is the real virus code and it is this output that is detected by the Sophos virus
detection engine after running in the emulator.
Executables that are sent to the engine for scanning are run inside the emulator, which tracks the decryption
of the virus body as it is written to memory. Normally the virus entry point sits at the front end of a file and
is the first thing to run. In most cases, only a small amount of the virus body has to be decrypted in order for
the virus to be recognized. Most clean executables stop emulating after only a few instructions, which reduces
overhead.
Because the emulator runs in a restricted area, if the code does turn out to be a virus, the virus does not infect
the email gateway.
Virus Descriptions
Sophos exchanges viruses with other trusted anti-virus companies every month. In addition, every month
customers send thousands of suspect files directly to Sophos, about 30% of which turn out to be viruses. Each
sample undergoes rigorous analysis in the highly secure virus labs to determine whether or not it is a virus.
For each newly discovered virus, or group of viruses, Sophos creates a description.
Sophos Alerts
Cisco encourages customers who enable Sophos Anti-Virus scanning to subscribe to Sophos alerts on the
Sophos site at http://www.sophos.com/virusinfo/notifications/. Subscribing to receive alerts directly from
Sophos will ensure you are apprised of the latest virus outbreaks and their available solutions.
When a Virus is Found
When a virus has been detected, Sophos Anti-Virus can repair (disinfect) the file. Sophos Anti-Virus can
usually repair any file in which a virus has been found, after which the file can be used without risk. The
precise action taken depends on the virus.
There can be limitations when it comes to disinfecting, because it is not always possible to return a file to its
original state. Some viruses overwrite part of the executable program which cannot be reinstated. In this
instance, you define how to handle messages with attachments that could not be repaired. You configure these
settings on a per-recipient basis using the Email Security Feature: the Mail Policies > Incoming or Outgoing
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
368
Anti-Virus
McAfee Anti-Virus Filtering
Mail Policies pages (GUI) or the policyconfig -> antivirus command (CLI). For more information on
configuring these settings, see Configuring Virus Scanning Actions for Users, on page 371.
McAfee Anti-Virus Filtering
The McAfee® scanning engine:
• Scans files by pattern-matching virus signatures with data from your files.
• Decrypts and runs virus code in an emulated environment.
• Applies heuristic techniques to recognize new viruses.
• Removes infectious code from files.
Related Topics
• Pattern-Matching Virus Signatures, on page 369
• Encrypted Polymorphic Virus Detection, on page 369
• Heuristics Analysis, on page 369
• When a Virus is Found, on page 368
Pattern-Matching Virus Signatures
McAfee uses anti-virus definition (DAT) files with the scanning engine to detect particular viruses, types of
viruses, or other potentially unwanted software. Together, they can detect a simple virus by starting from a
known place in a file, then searching for a virus signature. Often, they must search only a small part of a file
to determine that the file is free from viruses.
Encrypted Polymorphic Virus Detection
Complex viruses avoid detection with signature scanning by using two popular techniques:
• Encryption. The data inside the virus is encrypted so that anti-virus scanners cannot see the messages
or computer code of the virus. When the virus is activated, it converts itself into a working version, then
executes.
• Polymorphism. This process is similar to encryption, except that when the virus replicates itself, it
changes its appearance.
To counteract such viruses, the engine uses a technique called emulation. If the engine suspects that a file
contains such a virus, the engine creates an artificial environment in which the virus can run harmlessly until
it has decoded itself and its true form becomes visible. The engine can then identify the virus by scanning for
a virus signature, as usual.
Heuristics Analysis
Using only virus signatures, the engine cannot detect a new virus because its signature is not yet known.
Therefore the engine can use an additional technique — heuristic analysis.
Programs, documents or email messages that carry a virus often have distinctive features. They might attempt
unprompted modification of files, invoke mail clients, or use other means to replicate themselves. The engine
analyzes the program code to detect these kinds of computer instructions. The engine also searches for legitimate
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
369
Anti-Virus
When a Virus is Found
non-virus-like behavior, such as prompting the user before taking action, and thereby avoids raising false
alarms.
By using these techniques, the engine can detect many new viruses.
When a Virus is Found
When a virus has been detected, Sophos Anti-Virus can repair (disinfect) the file. Sophos Anti-Virus can
usually repair any file in which a virus has been found, after which the file can be used without risk. The
precise action taken depends on the virus.
There can be limitations when it comes to disinfecting, because it is not always possible to return a file to its
original state. Some viruses overwrite part of the executable program which cannot be reinstated. In this
instance, you define how to handle messages with attachments that could not be repaired. You configure these
settings on a per-recipient basis using the Email Security Feature: the Mail Policies > Incoming or Outgoing
Mail Policies pages (GUI) or the policyconfig -> antivirus command (CLI). For more information on
configuring these settings, see Configuring Virus Scanning Actions for Users, on page 371.
How to Configure the Email Gateway to Scan for Viruses
How to Scan Messages for Viruses
Do This More Info
Step 1 Enable anti-virus scanning on the email Enabling Virus Scanning and Configuring
gateway. Global Settings , on page 371
Step 2 Define the groups of users whose messages Creating a Mail Policy for a Group of
you want to scan for viruses. Senders and Recipients, on page 274
Step 3 (Optional) Configure how you want the virus Configuring Policy, Virus, and Outbreak
quarantine to handle messages. Quarantines , on page 931
Step 4 Determine how you want the email gateway Configuring Virus Scanning Actions for
to handle messages with viruses. Users, on page 371
Step 5 Configure the anti-virus scanning rules for the Configuring the Anti-Virus Policies for
user groups you defined. Different Groups of Senders and Recipients,
on page 376
Step 6 (Optional) Send an email message to test the Sending an Email to the Email Gateway to
configuration. Test Anti-Virus Scanning , on page 379
Related Topics
• Enabling Virus Scanning and Configuring Global Settings , on page 371
• Configuring Virus Scanning Actions for Users, on page 371
• Configuring the Anti-Virus Policies for Different Groups of Senders and Recipients, on page 376
• Notes on Anti-Virus Configurations, on page 377
• Flow Diagram for Anti-Virus Actions, on page 378
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
370
Anti-Virus
Enabling Virus Scanning and Configuring Global Settings
Enabling Virus Scanning and Configuring Global Settings
You may have enabled a virus scanning engine when you ran the System Setup Wizard. Regardless, configure
settings using this procedure.
Note Depending on your feature keys, you can enable Sophos, McAfee, or both.
Procedure
Step 1 Navigate to the Security Services > McAfee page.
Or
Navigate to the Security Services > Sophos page.
Step 2 Click Enable.
Note Clicking Enable enables the feature globally for the email gateway. However, you must later enable
per-recipient settings in Mail Policies.
Step 3 After reading the license agreement, scroll to the bottom of the page and click Accept to accept the agreement.
Step 4 Click Edit Global Settings.
Step 5 Choose a maximum virus scanning timeout value.
Configure a timeout value for the system to stop performing anti-virus scanning on a message. The default
value is 60 seconds.
Step 6 (Optional) Click Enable Automatic Updates to enable automatic update of the engine.
The email gateway fetches the required updates for the particular engine from the update server.
Step 7 Submit and commit your changes.
What to do next
Configure anti-virus settings on a per-recipient basis. See Configuring Virus Scanning Actions for Users, on
page 371.
Configuring Virus Scanning Actions for Users
The virus scanning engine integrated into the email gateway processes messages for viruses for incoming and
outgoing mail based on policies (configuration options) you configure using the Email Security Manager
feature. You enable Anti-Virus actions on a per-recipient basis using the Mail Policies > Incoming or Outgoing
Mail Policies pages (GUI) or the policyconfig > antivirus command (CLI).
Related Topics
• Message Scanning Settings, on page 372
• Message Handling Settings, on page 372
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
371
Anti-Virus
Message Scanning Settings
• Configuring Settings for Message Handling Actions, on page 373
Message Scanning Settings
• Scan for Viruses Only:
Messages processed by the system are scanned for viruses. Repairs are not attempted for infected
attachments. You can choose whether to drop attachments and deliver mail for messages that contain
viruses or could not be repaired.
• Scan and Repair Viruses:
Messages processed by the system are scanned for viruses. If a virus is found in an attachment, the system
will attempt to “repair” the attachment.
• Dropping Attachments
You can choose to drop infected attachments.
When infected attachments to messages have been scanned and dropped by the anti-virus scanning
engine, the attachment is replaced with a new attachment called “Removed Attachment.” The attachment
type is text/plain and contains the following:
This attachment contained a virus and was stripped.
Filename: filename
Content-Type: application/filetype
Users will always be notified if their messages were modified in any way because they were infected with a
bad attachment. You can configure a secondary notification action, as well (see Sending Notifications, on
page 375). The notify action is not needed to inform users that a message was modified if you choose to drop
infected attachments.
• X-IronPort-AV Header
All messages that are processed by the Anti-Virus scanning engine on the email gateway have the header
X-IronPort-AV: added to messages. This header provides additional information to you when debugging
issues with your anti-virus configuration, particularly with messages that are considered “unscannable.”
You can toggle whether the X-IronPort-AV header is included in messages that are scanned. Including
this header is recommended.
Message Handling Settings
You configure the virus scanning engine to handle four distinct classes of messages that are received by a
listener, with separate actions for each. Figure - Options for Handling Messages Scanned for Viruses
summarizes the actions the system performs when the virus scanning engine is enabled.
For each of the following message types, you can choose which actions are performed. The actions are
described below (see Configuring Settings for Message Handling Actions, on page 373). For example, you
can configure your anti- virus settings for virus-infected messages so that the infected attachment is dropped,
the subject of the email is modified, and a custom alert is sent to the message recipient.
Repaired Message Handling
Messages are considered repaired if the message was completely scanned and all viruses have been repaired
or removed. These messages will be delivered as is.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
372
Anti-Virus
Encrypted Message Handling
Encrypted Message Handling
Messages are considered encrypted if the engine is unable to finish the scan due to an encrypted or protected
field in the message. Messages that are marked encrypted may also be repaired.
Note the differences between the encryption detection message filter rule (see Encryption Detection Rule, on
page 173) and the virus scanning actions for “encrypted” messages. The encrypted message filter rule evaluates
to “true” for any messages that are PGP or S/MIME encrypted. The encrypted rule can only detect PGP and
S/MIME encrypted data. It does not detect password protected ZIP files, or Microsoft Word and Excel
documents that include encrypted content. The virus scanning engine considers any message or attachment
that is password protected to be “encrypted.”
Note If you upgrade from a 3.8 or earlier version of AsyncOS and you configured Sophos Anti-Virus scanning,
you must configure the Encrypted Message Handling section after you upgrade.
Unscannable Message Handling
Messages are considered unscannable if a scanning timeout value has been reached, or the engine becomes
unavailable due to an internal error. Messages that are marked unscannable may also be repaired.
Virus Infected Message Handling
The system may be unable to drop the attachment or completely repair a message. In these cases, you can
configure how the system handles messages that could still contain viruses.
The configuration options are the same for encrypted messages, unscannable messages, and virus messages.
Configuring Settings for Message Handling Actions
• Action to Apply, on page 373
• Quarantines and Anti-Virus Scanning, on page 374
• Modify the Message Subject Header, on page 374
• Archive Original Message, on page 374
• Sending Notifications, on page 375
• Add Custom Header to Message, on page 375
• Modify Message Recipient, on page 375
• Send Message to Alternate Destination Host, on page 375
• Send Custom Alert Notification, on page 376
Action to Apply
Choose which overall action to take on each message type for encrypted, unscannable, or virus positive
messages: drop the message, deliver the message as an attachment to a new message, deliver the message as
is, or send the message to the anti-virus quarantine area (Quarantines and Anti-Virus Scanning, on page 374).
Configuring the email gateway to deliver the infected messages as an attachment to a new message allows
the recipient to choose how to deal with the original, infected attachment.
If you choose to deliver the message or deliver the message as an attachment to a new message, you can
additionally:
• Modify message subject
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
373
Anti-Virus
Quarantines and Anti-Virus Scanning
• Archive original message
• Send generic notificationThe following actions are available in the “Advanced” section of the GUI:
• Add custom header to message
• Modify message recipient
• Send message to alternate destination host
• Send custom alert notification
Note These actions are not mutually exclusive; you can combine some or all of them differently within different
incoming or outgoing policies for different processing needs for groups of users. See the following sections
and Notes on Anti-Virus Configurations, on page 377 for more information on defining various scanning
policies using these options.
Repaired messages have only two advanced options: Add custom header and Send custom alert notification.
All other message types have access to all of the advanced options.
Quarantines and Anti-Virus Scanning
When flagged for quarantine, the message continues through the rest of the email pipeline. When the message
reaches the end of the pipeline, if the message has been flagged for one or more quarantines then it enters
those queues. Note that if the message does not reach the end of the pipeline, it is not placed in a quarantine.
For example, a content filter can cause a message to be dropped or bounced, in which case the message will
not be quarantined.
Archive Original Message
You can archive messages the system has identified as containing (or possibly containing) viruses to the
“avarchive” directory. The format is an mbox-format log file. You must configure an “Anti-Virus Archive”
log subscription to archive messages with viruses or messages that could not be completely scanned. For more
information, see Logging, on page 1141
Note In the GUI, you may need to click the “Advanced” link to reveal the “Archive original message” setting.
Modify the Message Subject Header
You can alter the text of identified messages by prepending or appending certain text strings to help users
more easily identify and sort identified messages.
Note White space is not ignored in the “Modify message subject” field. Add spaces after (if prepending) or before
(if appending) the text you enter in this field to separate your added text from the original subject of the
message. For example, add the text [WARNING: VIRUS REMOVED] with a few trailing spaces if you are
prepending.
The default text is:
Default Subject Line Text for Anti-Virus Subject Line Modification
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
374
Anti-Virus
Sending Notifications
Verdict Default Text to Add to Subject
Encrypted [WARNING: MESSAGE ENCRYPTED]
Infected [WARNING: VIRUS DETECTED]
Repaired [WARNING: VIRUS REMOVED]
Unscannable [WARNING: A/V UNSCANNABLE]
Any message with multiple states causes a multi-part notification message informing users what actions the
email gateway performed on the message (for example, the user is notified that the message was repaired of
a virus, but another part of the message was encrypted).
Sending Notifications
When the system has identified a message as containing viruses, you can send the default notification to the
sender, the recipient, and/or additional users. When specifying additional users to notify, separate multiple
addresses with commas (in both the CLI and the GUI). The default notification messages are:
Default Notifications for Anti-Virus Notifications
Verdict Notification
Repaired The following virus(es) was detected in a mail message: <virus name(s)>
Actions taken: Infected attachment dropped (or Infected attachment repaired).
Encrypted The following message could not be fully scanned by the anti-virus engine due to encryption.
Unscannable The following message could not be fully scanned by the anti-virus engine.
Infectious The following unrepairable virus(es) was detected in a mail message: <virus name(s)>.
Add Custom Header to Message
You can define an additional, custom header to be added to all messages that are scanned by the anti-virus
scanning engine. Click Yes and define the header name and text.
You can also create filters that use the skip-viruscheck action so that certain messages bypass virus scanning.
See Bypass Anti-Virus System Action, on page 220.
Modify Message Recipient
You can modify the message recipient, causing the message to be delivered to a different address. Click Yes
and enter the new recipient address.
Send Message to Alternate Destination Host
You can choose to send the notification to a different recipient or destination host for encrypted, unscannable,
or virus infected messages. Click Yes and enter an alternate address or host.
For example, you could route suspected messages to an administrator’s mailbox or a special mail server for
subsequent examination. In the case of a multi-recipient message, only a single copy is sent to the alternative
recipient.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
375
Anti-Virus
Send Custom Alert Notification
Send Custom Alert Notification
You can send a custom notification to the sender, recipient, and/or other users (email addresses). To do so,
you must first create the custom notification prior to configuring the settings. See Understanding Text Resources,
on page 651 for more information.
Figure 18: Options for Handling Messages Scanned for Viruses
Note By default, Anti-Virus scanning is enabled in the $TRUSTED mail flow policy for public listeners, which is
referenced by the ALLOWED_LIST sender group. See Defining Access Rules for Email Senders Using Mail
Flow Policies, on page 107.
Configuring the Anti-Virus Policies for Different Groups of Senders and
Recipients
The process for editing the per-user anti-virus settings for a mail policy is essentially the same for incoming
or outgoing mail.
Individual policies (not the default) have an additional field to “Use Default” settings. Select this setting to
inherit the default mail policy settings.
You enable anti-virus actions on a per-recipient basis using Incoming or Outgoing Mail Policies. You can
configure mail policies in the GUI or in the CLI using the policyconfig > antivirus command. After you enable
anti-virus settings globally, you configure these actions separately for each mail policy you create. You can
configure different actions for different mail policies.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
376
Anti-Virus
Notes on Anti-Virus Configurations
Procedure
Step 1 Navigate to the Mail Policies > Incoming Mail Policies or Mail Policies > Outgoing Mail Policies page.
Step 2 Click the link for the anti-virus security service for the policy you want to configure.
Note Click the link in the default row to edit the settings for the default policy.
Step 3 Click Yes or Use Default to enable Anti-Virus Scanning for the policy.
The first setting on the page defines whether the service is enabled for the policy. You can click Disable to
disable the service altogether.
For mail policies other than the default, choosing “Yes” enables the fields in the Repaired, Encrypted,
Unscannable, and Virus Infected Messages areas to become active.
Step 4 Select an Anti-Virus scanning engine. You can select McAfee or Sophos engines.
Step 5 Configure Message Scanning settings.
See Message Scanning Settings, on page 372 for more information.
Step 6 Configure settings for Repaired, Encrypted, Unscannable, and Virus Infected messages.
See Message Handling Settings, on page 372 and Configuring Settings for Message Handling Actions, on page
373.
Step 7 Click Submit.
Step 8 Commit your changes.
Notes on Anti-Virus Configurations
The drop attachments flag makes a considerable difference in how anti-virus scanning works. When the system
is configured to “Drop infected attachments if a virus is found and it could not be repaired,” any viral or
unscannable MIME parts are removed from messages. The output from Anti-Virus scanning, then, is almost
always a clean message. The action defined for Unscannable Messages , as shown in the GUI pane, rarely
takes place.
In a “Scan for Viruses only” environment, these actions “clean” messages by dropping the bad message parts.
Only if the RFC822 headers themselves are attacked or encounter some other problem would this result in
the unscannable actions taking place. However, when Anti-Virus scanning is configured for “Scan for Viruses
only” and “Drop infected attachments if a virus is found and it could not be repaired,” is not chosen, the
unscannable actions are very likely to take place.
The following table lists some common Anti-Virus configuration options
Common Anti-Virus Configuration Options
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
377
Anti-Virus
Flow Diagram for Anti-Virus Actions
Situation Anti-Virus Configuration
Widespread Virus Outbreak Drop-attachments: NO
Any viral message is simply dropped Scanning: Scan-Only
from the system with little other
Cleaned messages: Deliver
processing taking place.
Unscannable messages: DROP message
Encrypted messages: Send to administrator or quarantine for review.
Viral messages: Drop message
Liberal Policy Drop-attachments: YES
As many documents as possible are Scanning: Scan and Repair
sent.
Cleaned messages: [VIRUS REMOVED] and Deliver
Unscannable messages: Forward as attachment
Encrypted messages: Mark and forward
Viral messages: Quarantine or mark and forward.
More Conservative Policy Drop-attachments: YES
Scanning: Scan and Repair
Cleaned messages: [VIRUS REMOVED] and Deliver
(Archive cleaned messages for a more cautious policy.)
Unscannable messages: Send notification(s), quarantine, OR drop
and archive.
Encrypted messages: Mark and forward OR treat as unscannable
Viral messages: Archive and drop
Conservative with Review Drop-attachments: NO
Possible virus messages are sent to a Scanning: Scan-Only
quarantine mailbox so that an
Cleaned messages: Deliver (this action won't normally be taken)
administrator can review the content.
Unscannable messages: Forward as attachment, alt-src-host , or
alt-rcpt-to actions.
Encrypted messages: Treat as unscannable
Viral messages: Forward to quarantine or administrator.
Flow Diagram for Anti-Virus Actions
The following figure explains how anti-virus actions and options affect messages processed by the email
gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
378
Anti-Virus
Sending an Email to the Email Gateway to Test Anti-Virus Scanning
Figure 19: Flow Diagram for Anti-Virus Actions
Note If you configure multi-layer anti-virus scanning, the Cisco appliance performs virus scanning with the McAfee
engine first and the Sophos engine second. It scans messages using both engines, unless the McAfee engine
detects a virus. If the McAfee engine detects a virus, the email gateway performs the anti-virus actions
(repairing, quarantining, etc.) defined for the mail policy.
Sending an Email to the Email Gateway to Test Anti-Virus
Scanning
Procedure
Step 1 Enable virus scanning for a mail policy.
Use the Security Services > Sophos/McAfee Anti-virus page or the antivirusconfig command to set global
settings, and then use the Email Security Manager pages (GUI) or the antivirus subcommand of policyconfig
to configure the settings for a specific mail policy.
Step 2 Open a standard text editor, then type the following character string as one line, with no spaces or line breaks:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
379
Anti-Virus
Sending an Email to the Email Gateway to Test Anti-Virus Scanning
Note The line shown above should appear as one line in your text editor window, so be sure to maximize
your text editor window and delete any line breaks. Also, be sure to type the letter O, not the number
0, in the “X5O...” that begins the test message.
If you are reading this manual on your computer, you can copy the line directly from the PDF file or HTML
file and paste it into your text editor. If you copy the line, be sure to delete any extra carriage returns or spaces.
Step 3 Save the file with the name EICAR.COM.
The file size will be 68 or 70 bytes.
Note This file is not a virus — it cannot spread or infect other files, or otherwise harm your computer.
However, you should delete the file when you have finished testing your scanner to avoid alarming
other users.
Step 4 Attach the file EICAR.COM to an email message, and send it to the listener that will match the mail policy you
configured in step 1.
Ensure the that the recipient you specify in the test message will be accepted on the listener. (For more
information, see Adding Domains and Users For Which to Accept Messages, on page 135.)
Note that it may be difficult to email the file if you have virus scanning software is installed for outgoing mail
on a gateway other than the Cisco (for example, a Microsoft Exchange server).
Note The test file always scans as unrepairable.
Step 5 Evaluate the actions you configured for virus scanning on the listener and ensure they are enabled and working
as expected.
This is most easily accomplished by performing one of the following actions:
a. Configure the virus scanning settings to Scan and Repair mode or Scan only mode without dropping
attachments.
• Send an email with the Eicar test file as an attachment. Confirm that the actions taken match your
configuration for Virus Infected Message Handling (the settings in Virus Infected Message Handling,
on page 373).
b. Configure the virus scanning settings to Scan and Repair mode or Scan only mode with dropping
attachments.
• Send an email with the Eicar test file as an attachment.
• Confirm that the actions taken match your configuration for Repaired Message Handling (the settings
in Repaired Message Handling, on page 372).
For more information obtaining virus files for testing anti-virus scanning, see:
http://www.eicar.org/anti_virus_test_file.htm
This page provides 4 files for downloading. Note that it may be difficult to download and extract these files
if you have a client-side virus scanning software installed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
380
Anti-Virus
Updating Virus Definitions
Updating Virus Definitions
Related Topics
• About Retrieving Anti-Virus Updates via HTTP , on page 381
• Configuring Update Server Settings , on page 381
• Monitoring and Manually Checking for Anti-Virus Updates, on page 381
• Verifying Anti-Virus Files Have Updated on the Email Gateway, on page 382
About Retrieving Anti-Virus Updates via HTTP
Sophos and McAfee frequently update their virus definitions with newly-identified viruses. These updates
must be passed to your email gateway.
By default, the email gateway is configured to check for updates every 5 minutes. For the Sophos and McAfee
anti-virus engines, the server updates from a dynamic website.
The system does not timeout on updates as long as the update is actively downloading to the email gateway.
If the update download pauses for too long, then the download times out.
The maximum amount of time that the system waits for an update to complete before timing out is a dynamic
value that is defined as 1 minute less than the anti-virus update interval (defined on Security Services > Service
Updates). This configuration value aids appliances on slower connections while downloading large updates
that may take longer than 10 minutes to complete.
Configuring Update Server Settings
You can configure virus update settings via the Security Services > Service Updates page. For example, you
can configure how the system receives anti-virus updates and how often it checks for updates. For more
information about these additional settings, see Service Updates , on page 1026.
Monitoring and Manually Checking for Anti-Virus Updates
You can use the Security Services > Sophos or McAfee page or the antivirusstatus CLI command to
verify the email gateway has the latest anti-virus engine and identity files installed, and to confirm when the
last update was performed.
You can also manually perform updates. See Manually Updating Anti-Virus Engines , on page 381
Manually Updating Anti-Virus Engines
Procedure
Step 1 Navigate to the Security Services > Sophos or McAfee Anti-Virus page.
Step 2 Click Update Now in the Current McAfee/Sophos Anti-Virus Files table.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
381
Anti-Virus
Verifying Anti-Virus Files Have Updated on the Email Gateway
The email gateway checks for and downloads the latest updates.
What to do next
You can also configure this in the command-line interface using the antivirusstatus and antivirusupdate
command
Verifying Anti-Virus Files Have Updated on the Email Gateway
You can view the Updater Logs to verify whether or not the antivirus files have been successfully downloaded,
extracted, or updated. Use the tail command to show the final entries in the Updater log subscription to ensure
that virus updates were obtained.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
382
CHAPTER 18
Managing Spam and Graymail
This chapter contains the following sections:
• Overview of Anti-Spam Scanning , on page 383
• How to Configure the Email Gateway to Scan Messages for Spam, on page 384
• IronPort Anti-Spam Filtering, on page 386
• Configuring Intelligent Multi-Scan and Graymail Detection, on page 388
• Defining Anti-Spam Policies , on page 399
• Protecting Email Gateway-Generated Messages From the Spam Filter, on page 405
• Headers Added During Anti-Spam Scanning , on page 406
• Reporting Incorrectly Classified Messages to Cisco, on page 406
• Determining Sender IP Address In Deployments with Incoming Relays , on page 411
• Monitoring Rules Updates, on page 420
• Testing Anti-Spam, on page 421
Overview of Anti-Spam Scanning
Anti-spam processes scan email for incoming (and outgoing) mail based on the mail policies that you configure.
• One or more scanning engines scan messages through their filtering modules.
• Scanning engines assign a score to each message. The higher the score, the greater the likelihood that
the message is spam.
• Based on the score, each message is categorized as one of the following:
• Not spam
• Suspected spam
• Positively-identified spam
• An action is taken based on the result.
Actions taken on messages positively identified as spam, suspected to be spam, or identified as unwanted
marketing messages are not mutually exclusive; you can combine some or all of them differently within
different incoming or outgoing policies for different processing needs for groups of users. You can also treat
positively identified spam differently from suspected spam in the same policy. For example, you may want
to drop messages positively identified as spam, but quarantine suspected spam messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
383
Managing Spam and Graymail
Anti-Spam Solutions
For each mail policy, you can specify thresholds for some of the categories, and determine the action to take
for each category. You can assign different users to different mail policies and define different scanning
engines, spam-definition thresholds, and spam-handling actions for each policy.
Note For information about how and when anti-spam scanning is applied, see Email Pipeline and Security Services,
on page 70.
Related Topics
• Anti-Spam Solutions , on page 384
Anti-Spam Solutions
Your email gateway offers the following anti-spam solutions:
• IronPort Anti-Spam Filtering, on page 386.
• Configuring Intelligent Multi-Scan and Graymail Detection, on page 388.
You can license and enable both these solutions on your email gateway, but you can only use one in a particular
mail policy. You can specify a different anti-spam solution for different groups of users.
How to Configure the Email Gateway to Scan Messages for
Spam
Procedure
Command or Action Purpose
Step 1 Enable anti-spam scanning on the email Note Remaining steps in this table apply
gateway. to both scanning engine options.
If you have feature keys for both Cisco
IronPort Anti-Spam and Intelligent Multi-Scan,
you can enable both solutions on the email
gateway.
• IronPort Anti-Spam Filtering, on page 386
• Configuring Intelligent Multi-Scan and
Graymail Detection, on page 388
Step 2 Configure whether to quarantine spam on the • Setting Up the Local Spam Quarantine,
local email gateway or use an external on page 948
quarantine on a Cisco Secure Email and Web
Manager. • Working with an External Spam
Quarantine , on page 1286
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
384
Managing Spam and Graymail
How to Configure the Email Gateway to Scan Messages for Spam
Command or Action Purpose
Step 3 Define the groups of users whose messages Creating a Mail Policy for a Group of Senders
you want to scan for spam. and Recipients, on page 274
Step 4 Configure the anti-spam scanning rules for the Defining Anti-Spam Policies , on page 399
user groups you defined.
Step 5 If you want certain messages to skip Cisco Bypass Anti-Spam System Action, on page
Anti-Spam scanning, create message filters 219
that use the skip-spamcheck action.
Step 6 (Recommended) Enable IP Reputation Service For each inbound mail flow policy, ensure that
scoring for each inbound mail flow policy, “Use SenderBase for Flow Control” is On.
even if you are not rejecting connections based
See Defining Rules for Incoming Messages
on IP Reputation Scores.
Using a Mail Flow Policy, on page 115.
Step 7 If your email gateway does not connect Determining Sender IP Address In
directly to external senders to receive incoming Deployments with Incoming Relays , on page
mail, but instead receives messages relayed 411
through a mail exchange, mail transfer agent,
or other machine on your network, ensure that
relayed incoming messages include the original
sender IP address.
Step 8 Prevent alert and other messages generated by Protecting Email Gateway-Generated
your email gateway from being incorrectly Messages From the Spam Filter, on page 405
identified as spam.
Step 9 (Optional) Enable URL filtering to strengthen Enable URL Filtering, on page 451
protection against malicious URLs in
messages.
Step 10 Test your configuration. Testing Anti-Spam, on page 421
Step 11 (Optional) Configure settings for service Scanning rules for both anti-spam solutions
updates (including anti-spam rules.) are retrieved by default from the Cisco update
servers.
• Service Updates , on page 1026
• UpdatesThrough a Proxy Server, on page
1030
• Configuring Server Settings for
Downloading Upgrades and Updates , on
page 1030
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
385
Managing Spam and Graymail
IronPort Anti-Spam Filtering
IronPort Anti-Spam Filtering
Related Topics
• Evaluation Key, on page 386
• Cisco Anti-Spam: an Overview , on page 386
• Configuring IronPort Anti-Spam Scanning, on page 387
Evaluation Key
Your email gateway ships with a 30-day evaluation key for the Cisco Anti-Spam software. This key is not
enabled until you accept the license agreement in the system setup wizard or Security Services > IronPort
Anti-Spam pages (in the GUI) or the systemsetup or antispamconfig commands (in the CLI). Once you have
accepted the agreement, Cisco Anti-Spam will be enabled, by default, for the default incoming Mail Policy.
An alert is also sent to the administrator address you configured (see the System Setup Wizard, Step 2: System,
on page 42) noting that the Cisco Anti-Spam license will expire in 30 days. Alerts are sent 30, 15, 5, and 0
days prior to expiration. For information on enabling the feature beyond the 30-day evaluation period, contact
your Cisco sales representative. You can see how much time remains on the evaluation via the System
Administration > Feature Keys page or by issuing the featurekey command. (For more information, see Feature
Keys, on page 1008.)
Cisco Anti-Spam: an Overview
IronPort Anti-Spam addresses a full range of known threats including spam, phishing and zombie attacks, as
well as hard-to-detect low volume, short-lived email threats such as “419” scams. In addition, IronPort
Anti-Spam identifies new and evolving blended threats such as spam attacks distributing malicious content
through a download URL or an executable.
To identify these threats, IronPort Anti-Spam examines the full context of a message-its content, methods of
message construction, the reputation of the sender, the reputation of web sites advertised in the message, and
more. IronPort Anti-Spam combines the power of email and web reputation data, leveraging the full power
of the world's largest email and web traffic monitoring network — SenderBase — to detect new attacks as
soon as they begin.
IronPort Anti-Spam analyzes over 100,000 message attributes across the following dimensions:
• Email reputation — who is sending you this message?
• Message content — what content is included in this message?
• Message structure — how was this message constructed?
• Web reputation — where does the call to action take you?
Analyzing multi-dimensional relationships allows the system to catch a broad range of threats while maintaining
accuracy. For example, a message that has content claiming to be from a legitimate financial institution but
that is sent from an IP address on a consumer broadband network or that contains a URL hosted on a “zombie”
PC will be viewed as suspicious. In contrast, a message coming from a pharmaceutical company with a positive
reputation will not be tagged as spam even if the message contains words closely correlated with spam.
Related Topics
• URL-Related Protections and Controls , on page 449
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
386
Managing Spam and Graymail
Configuring IronPort Anti-Spam Scanning
Configuring IronPort Anti-Spam Scanning
Procedure
Step 1 Select Security Services > IronPort Anti-Spam.
Step 2 If you have not enabled IronPort Anti-Spam in the system setup wizard:
a) Click Enable.
b) Scroll to the bottom of the license agreement page and click Accept to accept the agreement.
Step 3 Click Edit Global Settings.
Step 4 Select the check box for Enable IronPort Anti-Spam Scanning.
Checking this box enables the feature globally for the email gateway.
Step 5 To optimize the throughput of your email gateway while still being able to scan increasingly larger messages
sent by spammers, configure the thresholds for message scanning by Cisco Anti-Spam.
Option Description
Message Scanning Thresholds a. Enter a value for Always scan messages smaller than —The
recommended value is 1 MB or less. Messages smaller than the always
scan size will be fully scanned, except in cases of “early exit.” Messages
larger than this size are partially scanned if they are smaller than the
never scan size.
Cisco advises not to exceed 3 MB for the always scan message size.
A larger value may result in decreased performance.
b. Enter a value for Never scan messages larger than —The
recommended value is 2 MB or less. Messages larger than this size
will not be scanned by Cisco Anti-Spam and the
X-IronPort-Anti-Spam-Filtered: true header will not be added to the
message.
Cisco advises not to exceed 10 MB for the never scan message size.
A larger value may result in decreased performance.
For messages larger than the always scan size or smaller than the never
scan size, a limited and faster scan is performed.
Note If the Outbreak Filters maximum message size is greater
than Cisco Anti-Spam’s always scan message, messages
smaller than the Outbreak Filters maximum size are fully
scanned.
Timeout for Scanning Single Enter the number of seconds to wait for timeout when scanning a message.
Message
Enter an integer from 1 to 120. The default value is 60 seconds.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
387
Managing Spam and Graymail
Configuring Intelligent Multi-Scan and Graymail Detection
Option Description
Scanning Profile Choose from any of the following scanning profiles to catch spam messages:
• Normal - Enable this option for a balanced approach to block spam.
• Aggressive - Enable this option to provide stronger emphasis to block
spam. When enabled, tuning the Anti-Spam policy thresholds have
more impact on spam detection than the Normal profile with a larger
potential for false positives.
Note When using the new aggressive scanning profile mail policy
adjustments to Anti-Spam thresholds have a larger impact
than before. Therefore when enabling the aggressive profile,
any Anti-Spam policy thresholds previously adjusted should
be reset to default settings and then reevaluated for the best
balance of spam catch rate vs. false positive potential.
Step 6 Submit and commit your changes.
Configuring Intelligent Multi-Scan and Graymail Detection
This section describes how to configure Cisco Intelligent Multi-Scan and Graymail Detection and Safe
Unscubscribing:
• Configuring Cisco Intelligent Multi-Scan, on page 388
• Configuring Global Settings for Intelligent Multi-Scan and Graymail Detection, on page 398
• Managing Graymail, on page 389
Configuring Cisco Intelligent Multi-Scan
Cisco Intelligent Multi-Scan incorporates multiple anti-spam scanning engines, including Cisco Anti-Spam,
to provide a multi-layer anti-spam solution.
When processed by Cisco Intelligent Multi-Scan:
• A message is first scanned by third-party anti-spam engines.
• Cisco Intelligent Multi-Scan then passes the message and the verdicts of the third-party engines to Cisco
Anti-Spam, which assumes responsibility for the final verdict.
• After Cisco Anti-Spam performs its scan, it returns a combined multi-scan score to AsyncOS.
• Combining the benefits of the third-party scanning engines and Cisco Anti-Spam results in more caught
spam while maintaining Cisco Anti-Spam’s low false positive rate.
You cannot configure the order of the scanning engines used in Cisco Intelligent Multi-Scan; Cisco Anti-Spam
will always be the last to scan a message and Cisco Intelligent Multi-Scan will not skip it if a third-party
engine determines that a message is spam.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
388
Managing Spam and Graymail
Managing Graymail
Using Cisco Intelligent Multi-Scan can lead to reduced system throughput. Please contact your Cisco support
representative for more information.
Note The Cisco Intelligent Multi-Scan feature key also enables Cisco Anti-Spam on the email gateway, giving you
the option of enabling either Cisco Intelligent MultiScan or Cisco Anti-Spam for a mail policy.
Important When Cisco Intelligent Multi-Scan is enabled during system setup, it is enabled for the default incoming mail
policy with the default values for the global settings.
Before you begin
Activate the feature key for this feature. See Feature Keys, on page 1008. You will see the IronPort Intelligent
Multi-Scan option only if you have done so.
Procedure
Step 1 Select Security Services > IMS and Graymail.
Step 2 If you have not enabled Cisco Intelligent Multi-Scan in the system setup wizard:
a) Click Enable.
b) Scroll to the bottom of the license agreement page and click Accept to accept the agreement.
Step 3 Click Edit IMS Settings.
Step 4 Select the check box for Enable Intelligent Multi-Scan enable the feature globally for the email gateway.
However, you must still enable per-recipient settings in Mail Policies.
Step 5 (Optional) Click Edit Global Settings to configure the threshold for message scanning. For more information
about global settings, see Configuring Global Settings for Intelligent Multi-Scan and Graymail Detection, on
page 398.
Step 6 Submit and commit your changes.
Managing Graymail
• Overview of Graymail, on page 390
• Graymail Management Solution in Email Gateway, on page 390
• How Graymail Management Solution Works, on page 391
• Configuring Graymail Detection and Safe Unsubscribing, on page 393
• Troubleshooting Graymail Detection and Safe Unsubscribing, on page 398
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
389
Managing Spam and Graymail
Overview of Graymail
Overview of Graymail
Graymail messages are messages that do not fit the definition of spam, for example, newsletters, mailing list
subscriptions, social media notifications, and so on. These messages were of use at some point in time, but
have subsequently diminished in value to the point where the end user no longer wants to receive them.
The difference between graymail and spam is that the end user intentionally provided an email address at
some point (for example, the end user subscribed to a newsletter on an e-commerce website or provided
contact details to an organization during a conference) as opposed to spam, messages that the end user did
not sign up for.
Graymail Management Solution in Email Gateway
The graymail management solution in the email gateway comprises of two components: an integrated graymail
scanning engine and a cloud-based Unsubscribe Service.
The graymail management solution allows organizations to:
• Identify graymail using the integrated graymail engine and apply appropriate policy controls.
• Provide an easy mechanism for end users to unsubscribe from unwanted messages using Unsubscribe
Service.
In addition to these, the graymail management solution also help organizations to provide:
• Secure unsubscribe option for end users. Mimicking an unsubscribe option is a popular phishing
technique. For this reason, the end users are generally wary of clicking unknown unsubscribe links. For
such scenarios, the cloud-based Unsubscribe Service extracts the original unsubscribe URI, checks the
reputation of the URI, and then performs the unsubscribe process on behalf of the end user. This protects
end users from malicious threats masquerading as unsubscribe links.
• Uniform subscription management interface for end users. Different graymail senders use different
layouts for displaying unsubscribe links to the users. The users must search for the unsubscribe link in
the message body and perform the unsubscribing. Irrespective of the graymail senders, the graymail
management solution provides a common layout for displaying unsubscribe links to the users.
• Better visibility for administrators into various graymail categories. The graymail engine classifies
each graymail into three categories (see Graymail Classification, on page 390) and the administrators can
set policy controls based on these categories.
• Improved spam efficacy
Related Topics
• Graymail Classification, on page 390
Graymail Classification
The graymail engine classifies each graymail into one of the following categories:
• Marketing Email. Advertising messages sent by professional marketing groups, for example, bulletins
from Amazon.com with details about their newly launched products.
• Social Network Email. Notification messages from social networks, dating websites, forums, and so
on. Examples include alerts from:
• LinkedIn, for jobs that you may be interested in
• CNET forums, when a user responds to your post.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
390
Managing Spam and Graymail
How Graymail Management Solution Works
• Bulk Email. Advertising messages sent by unrecognized marketing groups, for example, newsletters
from TechTarget, a technology media company.
How Graymail Management Solution Works
The following steps illustrates the workflow of graymail management solution:
Figure 20: Graymail Management Solution Workflow
Workflow
Procedure
Step 1 The email gateway receives an incoming message.
Step 2 The email gateway checks if graymail detection is enabled. If graymail detection is enabled, go to Step 3.
Else, go to Step 8
Step 3 The email gateway checks if the message is spam, virus, or malware positive. If positive, go to Step 8. Else,
go to Step 4
Step 4 The email gateway checks if the message is graymail. If the message is graymail, go to Step 5. Else, go to
Step 8
Step 5 The email gateway applies the configured policy actions such as, drop, deliver, bounce, or quarantine to the
spam quarantine.
Step 6 The email gateway checks if safe unsubscribing enabled. If safe unsubscribing is enabled, go to Step 7. Else,
go to Step 8.
Step 7 The email gateway adds a banner with unsubscribe button to the message. Also, the email gateway rewrites
the existing unsubscribe links in the message body.
Step 8 The email gateway processes the message through the next stages of its email work queue.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
391
Managing Spam and Graymail
How Safe Unsubscribing Works
What to do next
For an overview of how email is processed through the system, from reception to routing to delivery, see
Understanding the Email Pipeline, on page 65
Related Topics
• How Safe Unsubscribing Works, on page 392
• Understanding the Email Pipeline, on page 65
How Safe Unsubscribing Works
The following flow diagram shows how safe unsubscribing works.
Figure 21: Safe Unsubscribing Workflow
Workflow
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
392
Managing Spam and Graymail
Configuring Graymail Detection and Safe Unsubscribing
Procedure
Step 1 End user receives a message with the graymail banner.
Step 2 End user clicks on the Unsubscribe link.
Step 3 Unsubscribe Service extracts the original unsubscribe URI.
Step 4 Unsubscribe Service checks the reputation of the URI.
Step 5 Depending on the reputation of the URI, the Unsubscribe Service performs one of the following actions:
• If the URI is malicious, the Unsubscribe Service will not perform the unsubscribe process and displays
a block page to the end user.
• If the URI is not malicious, depending on the URI type ( http or mailto ), the Unsubscribe Service sends
an unsubscribe request to the graymail sender.
• If the request is successful, the Unsubscribe Service displays the “Successfully unsubscribed” status
to the end user.
• If the first unsubscribe request fails, the Unsubscribe Service displays the “Unsubscribe process in
progress” status and provides a URL that can be used to track the status of the unsubscribing.
End users can use this URL to track the status at a later point. After the first failed attempt, the
Unsubscribe Service sends periodic unsubscribe requests for a duration of four hours.
If an end user checks the status of the unsubscribe process at a later point,
• If one of the requests within the four hour duration (from the first failed attempt) is successful, the
Unsubscribe Service displays the “Successfully unsubscribed” status to the end user.
• If none of the requests within the four hour duration (from the first failed attempt) are successful,
the Unsubscribe Service displays the “Unable to subscribe” status to the end user and provides a
URL that can be used to unsubscribe from the graymail manually.
Configuring Graymail Detection and Safe Unsubscribing
• Requirements for Graymail Detection and Safe Unsubscribing, on page 393
• Graymail Detection and Safe Unsubscribing in Cluster Configurations, on page 394
• Enable Graymail Detection and Safe Unsubscribing, on page 394
• Configuring the Incoming Mail Policy for Graymail Detection and Safe Unsubscribing, on page 394
• IronPort-PHdr Header Added During Graymail Scanning, on page 395
• Bypassing Graymail Actions using Message Filters, on page 396
• Monitoring Graymail, on page 396
• Updating Graymail Rules, on page 397
• Customizing the Appearance of Unsubscribe Page for End Users, on page 397
• End-User Safelist, on page 397
• Viewing Logs, on page 397
Requirements for Graymail Detection and Safe Unsubscribing
• For graymail detection, anti-spam scanning must be enabled globally. This can be either the IronPort
Anti-Spam, the Intelligent Multi-Scan feature, or Outbreak Filters. See Managing Spam and Graymail,
on page 383.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
393
Managing Spam and Graymail
Graymail Detection and Safe Unsubscribing in Cluster Configurations
• For safe unsubscribing,
• Add the safe unsubscribing feature key.
• The end user machines must be able to connect to the cloud-based Unsubscribe Service directly
over the Internet.
Graymail Detection and Safe Unsubscribing in Cluster Configurations
You can enable Graymail Detection and Safe Unsubscribing at the machine, group or cluster level.
Enable Graymail Detection and Safe Unsubscribing
Procedure
Step 1 Select Security Services > IMS and Graymail.
Step 2 Click Edit Graymail Settings.
Step 3 Check Enable Graymail Detection.
Step 4 Check Enable Safe Unsubscribe.
Step 5 (Optional) Check Enable Automatic Updates to enable automatic update of the engine.
The email gateway fetches the required updates for the particular engine from the update server.
Step 6 Click Submit.
Step 7 (Optional) Click Edit Global Settings to configure the threshold for scanning the message. For more
information, see Configuring Global Settings for Intelligent Multi-Scan and Graymail Detection, on page 398.
Step 8 Submit and commit your changes.
What to do next
To configure Graymail Detection and Safe Unsubscribing global settings in CLI, use the imsandgraymailconfig
CLI command. For more information, see CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway.
Configuring the Incoming Mail Policy for Graymail Detection and Safe Unsubscribing
Before You Begin
Enable Graymail Detection and Safe Unsubscribing, on page 394
Procedure
Step 1 Click Mail Policies > Incoming Mail Policies.
Step 2 Click the link in the Graymail column of the mail policy to modify.
Step 3 Depending on your requirements, choose the following options:
• Enable graymail detection
• Enable safe unsubscribing
• Choose whether to apply the above actions on all messages or only on unsigned messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
394
Managing Spam and Graymail
IronPort-PHdr Header Added During Graymail Scanning
Note The email gateway considers a message signed if it is encrypted using S/MIME or it contains
an S/MIME signature.
• Actions to be taken on various graymail categories (Marketing Email, Social Network Email, and Bulk
Email):
• Drop, deliver, bounce, or quarantine (to the spam quarantine) the message
Note If you plan to use safe unsubscribing option, you must set the action to deliver or
quarantine.
• Send the message to an alternate host
• Modify subject of the message
• Add custom headers
• Send the message to an alternate envelope recipient
Note If you are sending a graymail positive message to an alternate envelope recipient, banner
will not be added.
• Archive the message
Note If you are planning only to monitor the detected graymail, you can enable graymail
detection per policy without having to configure actions for various graymail categories.
In this scenario, the email gateway takes no action on the detected graymail.
Step 4 Submit and commit your changes.
What to do next
Note You can also configure outgoing mail policies for graymail detection. Keep in mind that, in this scenario, you
cannot configure safe unsubscribing.
To configure policy settings for Graymail Detection and Safe Unsubscribing in CLI, use the policyconfig
command. For more information, see CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway .
IronPort-PHdr Header Added During Graymail Scanning
The IronPort-PHdr header is added to all messages that are processed by the Graymail engine when:
• Graymail engine is enabled globally on the email gateway.
• Graymail scanning is enabled for a specific mail policy.
Note If Graymail scanning is not enabled for a specific mail policy, the IronPort-PHdr
header is still added to all messages, if the Graymail engine is enabled globally
on the email gateway.
The IronPort-PHdr header contains encoded proprietary information and is not customer-decodable. This
header provides additional information about debugging issues with your Graymail configuration.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
395
Managing Spam and Graymail
Bypassing Graymail Actions using Message Filters
Note If Anti-Spam engine or Outbreak Filter is enabled for a specific mail policy, the IronPort-PHdr header is
added to all messages that pass through the specific mail policy.
Bypassing Graymail Actions using Message Filters
If you do not want to apply graymail actions on certain messages, you can use the following message filters
to bypass graymail actions:
Message Filter Action Description
skip-marketingcheck Bypass actions on marketing emails
skip-socialcheck Bypass actions on social network emails
skip-bulkcheck Bypass actions on bulk emails
The following example specifies that messages received on the listener “private_listener” must bypass graymail
actions on social network emails.
internal_mail_is_safe:
if (recv-listener == 'private_listener')
{
skip-socialcheck
();
}
Monitoring Graymail
You can view data about detected graymail using the following reports.
Report Contains the Following Graymail Data More Info
Overview page > Incoming Mail The number of incoming graymail messages under each Overview
Summary graymail category (Marketing, Social, and Bulk) and the Page, on
total number of graymail messages. page 838
Incoming Mail page > Top Senders The top graymail senders. Incoming
by Graymail Messages Mail Page,
on page 841
Incoming Mail page > Incoming The number of incoming graymail messages under each
Mail Details graymail category (Marketing, Social, and Bulk) and the
total number of graymail messages for all the IP
addresses, domain names, or network owners.
Incoming Mail page > Incoming The number of incoming graymail messages under each
Mail Details > Sender Profile (drill graymail category (Marketing, Social, and Bulk) and the
down view) total number of graymail messages for a given IP address,
domain name, or network owner.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
396
Managing Spam and Graymail
Updating Graymail Rules
Report Contains the Following Graymail Data More Info
Internal Users page > Top Users by The top end users who receive graymail. Internal
Graymail Users Page,
on page 849
Internal Users page > User Mail The number of incoming graymail messages under each
Flow Details graymail category (Marketing, Social, and Bulk) and the
total number of graymail messages for all the users.
Internal Users page > User Mail The number of incoming graymail messages under each
Flow Details > Internal User (drill graymail category (Marketing, Social, and Bulk) and the
down view) total number of graymail messages for a given user.
If you had enabled Marketing Email Scanning under anti-spam settings for a mail policy, after upgrading to
AsyncOS 9.5 or later, keep in mind that:
• The number of marketing messages is a sum of marketing messages detected before and after the upgrade.
• The total number of graymail messages does not include the number of marketing messages detected
before the upgrade.
• The total number of attempted messages also includes the number of marketing messages detected before
the upgrade.
Updating Graymail Rules
If you have enabled service updates, scanning rules for the graymail management solution is retrieved from
the Cisco update servers. But in some scenarios (for example, you have disabled automatic service updates
or automatic service update is not working), you may want to manually update graymail rules.
To manually update the graymail rules, do one of the following:
• In web interface, go to Security Service > IMS and Graymail page, and click Update Now.
• In CLI, run the graymailupdate command.
To know the details of existing graymail rules, see the Rule Updates section of the IMS and Graymail page
in web interface or use the graymailstatus command in CLI.
Customizing the Appearance of Unsubscribe Page for End Users
When an end user clicks on unsubscribe link, the Unsubscribe Service displays a Cisco branded Unsubscribe
page indicating the status of the unsubscribe process (see How Safe Unsubscribing Works, on page 392). You
can customize the appearance of the Unsubscribe page and display your organization’s branding (such as
company logo, contact information, and so on) using Security Services > Block Page Customization. For
instructions, see Customizing the Notification That End Users See If a Site Is Malicious , on page 455.
End-User Safelist
If the end users in your organization have configured Safelist for their own email accounts, graymail messages
from a sender in the safelist will not be scanned by the graymail scanning engine. For more information about
Safelists, see Using Safelists and Blocklists to Control Email Delivery Based on Sender , on page 953.
Viewing Logs
The graymail detection and safe unsubscribing information is posted to the following logs:
• Graymail Engine Logs. Contains information about the graymail engine, status, configuration, and so
on. Most information is at Info or Debug level.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
397
Managing Spam and Graymail
Troubleshooting Graymail Detection and Safe Unsubscribing
• Graymail Archive. Contains archived messages (the messages that are scanned and associated with the
“archive message” action). The format is an mbox-format log file.
• Mail Logs. Contains information about graymail detection and addition of banner for safe unsubscribing.
Most information is at Info or Debug level.
Troubleshooting Graymail Detection and Safe Unsubscribing
Unable to Perform Safe Unsubscribing, on page 398
Unable to Perform Safe Unsubscribing
Problem
After clicking on the Unsubscribe link, the end user sees the following message: “Unable to unsubscribe
from...”
Solution
This problem can occur if the Unsubscribe Service is unable to perform the safe unsubscribe on behalf of the
end user. The following are some of the common scenarios in which the Unsubscribe Service is unable to
perform the safe unsubscribe:
• Unsubscribe URI or mailto address is wrong.
• Websites that require the end users’ credentials to unsubscribe.
• Websites that require the end users to confirm the request of unsubscribing by logging into their email
accounts.
• Websites that require captcha to be solved and the Unsubscribe Service is unable to solve the captcha.
• Websites that require interactive unsubscribing.
The end users can use the URL provided at the bottom of the unsubscribe page to unsubscribe manually.
Configuring Global Settings for Intelligent Multi-Scan and Graymail Detection
To optimize the throughput of your email gateway, you can configure the threshold and the timeout settings
for scanning messages by Cisco Intelligent Multi-Scan and Graymail. These settings are common for both
Cisco Intelligent Multi-Scan and Graymail configuration.
1. Select Security Services > IMS and Graymail
2. Click Edit Global Settings.
3. Select the thresholds for scanning with Cisco Intelligent Multi-Scan and Graymail Detection.
The default values are:
• Always scan 512K or less.
•
Note This setting is not applicable for Graymail Detection and Safe Unsubscribing.
• Never scan 1M or more.
4. Enter the number of seconds to wait for timeout when scanning a message.
When specifying the number of seconds, enter an integer from 1 to 120. The default value is 60 seconds.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
398
Managing Spam and Graymail
Defining Anti-Spam Policies
Most users do not have to change the maximum message size to be scanned or the timeout value. That
said, you may be able to optimize the throughput of your email gateway by lowering the maximum message
size setting.
5. Submit and comit your changes.
Defining Anti-Spam Policies
For each mail policy, you specify settings that determine which messages are considered spam and what action
to take on those messages. You also specify which engine will scan messages that the policy applies to.
You can configure different settings for the default incoming and outgoing mail policies. If you need different
anti-spam policies for different users, use multiple mail policies with different anti-spam settings. You can
enable only one anti-spam solution per policy; you cannot enable both on the same policy.
Before You Begin
• Complete all steps to this point in the table in How to Configure the Email Gateway to Scan Messages
for Spam, on page 384.
• Familiarize yourself with the following:
• Understanding Positive and Suspect Spam Thresholds, on page 401
• Configuration Examples: Actions for Positively Identified versus Suspected Spam , on page 402
• Unwanted Marketing Messages From Legitimate Sources, on page 402
• If you have enabled more than one anti-spam solution: Enabling Different Anti-Spam Scanning
Engines in Different Mail Policies: Configuration Example , on page 404
• Headers Added During Anti-Spam Scanning , on page 406
• If you will archive spam into the “Anti-Spam Archive” log, see also Logging, on page 1141.
• If you will send messages to an alternate mailhost, see also Alter Delivery Host Action, on page 214.
Procedure
Step 1 Navigate to the Mail Policies > Incoming Mail Policies page.
Or
Step 2 Navigate to the Mail Policies > Outgoing Mail Policies page.
Step 3 Click the link under the Anti-Spam column for any mail policy.
Step 4 In the Enable Anti-Spam Scanning for This Policy section, select the anti-spam solution you want to use
for the policy.
Options you see depend on the anti-spam scanning solution(s) that you have enabled.
For mail policies other than the default: If you use settings from the default policy, all other options on the
page are disabled.
You can also disable anti-spam scanning altogether for this mail policy.
Step 5 Configure settings for positively identified spam, suspected spam, and marketing messages:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
399
Managing Spam and Graymail
Defining Anti-Spam Policies
Option Description
Enable Suspected Choose an option.
Spam Scanning
Positively-identified spam scanning is always enabled if anti-spam scanning is enabled.
Enable Marketing
Email Scanning
Apply This Action Choose which overall action to take on positively identified spam, suspected spam, or
to Message unwanted marketing messages:
• Deliver
• Drop
• Bounce
• Quarantine
(Optional) Send to You can send identified messages to an alternate destination mailhost (an email server
Alternate Host other than the ones listed in SMTP Routes or DNS).
Enter an IP address or hostname. If you enter a hostname, its Mail Exchange (MX)
will be queried first. If none exists, the A record on the DNS server will be used (as
with SMTP Routes).
Use this option if you want to redirect messages, for example to a sandbox mail server
for further examination.
For additional important information, see Alter Delivery Host Action, on page 214.
Add Text to Subject You can alter text in the Subject of identified messages by prepending or appending
certain text strings to help users more easily identify and sort spam and unwanted
marketing messages.
Note White space is not ignored in this field. Add spaces after (if prepending) or
before (if appending) the text you enter in this field to separate your added
text from the original subject of the message. For example, if you are
prepending, add the text [SPAM] with a few trailing spaces.
“Add Text to Subject” field only accepts US-ASCII characters.
Advanced Options (for custom header and message delivery)
(Optional) Add You can add a custom header to identified messages.
Custom Header
Click Advanced and define header and value.
You can use a custom header in conjunction with a content filter to perform actions
such as redirecting URLs in suspected spam messages so that they pass through the
Cisco Web Security proxy service. For information, see Using Custom Headers to
Redirect URLs in Suspected Spam to the Cisco Web Security Proxy: Configuration
Example , on page 403.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
400
Managing Spam and Graymail
Understanding Positive and Suspect Spam Thresholds
Option Description
(Optional) Send to You can have identified messages sent to an alternate envelope recipient address.
an Alternate
Click Advanced and define an alternate address.
Envelope Recipient
For example, you could route messages identified as spam to an administrator’s mailbox
for subsequent examination. In the case of a multi-recipient message, only a single
copy is sent to the alternate recipient.
Archive Message You can archive identified messages into the “Anti-Spam Archive” log. The format
is an mbox-format log file.
Spam Thresholds Use the default thresholds or enter a threshold value for positively identified spam and
a value for suspected spam.
Step 6 Submit and commit your changes.
What to do next
If you enabled anti-spam scanning for outgoing mail, check the anti-spam settings of the relevant host access
table, especially for a private listener. See Defining Access Rules for Email Senders Using Mail Flow Policies,
on page 107.
Related Topics
• How to Configure the Email Gateway to Scan Messages for Spam, on page 384
• Understanding Positive and Suspect Spam Thresholds, on page 401
• Configuration Examples: Actions for Positively Identified versus Suspected Spam , on page 402
• Unwanted Marketing Messages From Legitimate Sources, on page 402
• Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy:
Configuration Example , on page 403
• Enabling Different Anti-Spam Scanning Engines in Different Mail Policies: Configuration Example ,
on page 404
Understanding Positive and Suspect Spam Thresholds
When evaluating messages for spam, both anti-spam scanning solutions apply thousands of rules in order to
arrive at an overall spam score for the message. The score is then compared to the thresholds specified in the
applicable mail policy to determine whether the message is considered spam.
For highest accuracy, the threshold for positive identification as spam is quite high by default: Messages
scoring between 90 and 100 are considered to be positively identified as spam. The default threshold for
suspected spam is 50.
• Messages with scores below the suspected spam threshold will be considered legitimate.
• Messages above the suspected threshold but below the positive-identification threshold will be considered
to be suspected spam.
You can configure your anti-spam solution to reflect the spam tolerance levels of your organization by
customizing the Positive and Suspected spam thresholds in each mail policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
401
Managing Spam and Graymail
Configuration Examples: Actions for Positively Identified versus Suspected Spam
You can change the positively identified spam threshold to a value between 50 and 99. You can change the
threshold for suspected spam to any value between 25 and the value you specified for positively-identified
spam.
When you change the thresholds:
• Specifying a lower number (a more aggressive configuration) identifies more messages as spam and may
produce more false positives. This provides a lower risk that users will see spam but a higher risk of
having legitimate mail marked as spam.
• Specifying a higher number (a more conservative configuration) identifies fewer messages as spam and
may deliver more spam. This provides a higher risk of users seeing spam but less risk that legitimate
mail will be withheld as spam. Ideally, if set up correctly, the message subject will identify the message
as likely spam and message will be delivered.
You can define separate actions to take on positively-identified and suspected spam. For example, you may
want to drop “positively identified” spam but quarantine “suspected” spam.
Related Topics
• Anti-Spam Solutions , on page 384
• Configuration Examples: Actions for Positively Identified versus Suspected Spam , on page 402
Configuration Examples: Actions for Positively Identified versus Suspected
Spam
Spam Sample Actions Sample Actions
(Aggressive) (Conservative)
Positively Drop • Deliver with “ [Positive Spam] ” added to the
Identified subject of messages, or
• Quarantine
Suspected Deliver with “ [Suspected Deliver with “ [Suspected Spam] ” added to the subject
Spam] ” added to the subject of of messages
messages
The aggressive example tags only suspected spam messages, while dropping those messages that are positively
identified. Administrators and end-users can check the subject line of incoming message for false positives,
and an administrator can adjust, if necessary, the suspected spam threshold.
In the conservative example, positively identified and suspected spam is delivered with an altered subject.
Users can delete suspected and positively identified spam. This method is more conservative than the first.
For a further discussion of aggressive and conservative policies in mail policies, see Managed Exceptions,
on page 277.
Unwanted Marketing Messages From Legitimate Sources
If you had configured Marketing Email Settings under anti-spam settings for a mail policy, after upgrading
to AsyncOS 9.5 for Email, Marketing Email Settings under anti-spam settings will be moved under graymail
settings of the same policy. See Managing Spam and Graymail, on page 383.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
402
Managing Spam and Graymail
Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy: Configuration Example
Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web
Security Proxy: Configuration Example
You can rewrite URLs in suspected spam so that when a recipient clicks a link in the message, the request is
routed through the Cisco Web Security proxy service, which evaluates the safety of the site at click time and
blocks access to known malicious sites.
Before You Begin
Enable the URL Filtering feature and its prerequisites. See Setting Up URL Filtering, on page 450.
Procedure
Step 1 Apply a custom header to suspected spam messages:
a) Select Mail Policies > Incoming Mail Policies.
b) Click the link in the Anti-Spam column for a policy such as the Default policy.
c) In the Suspected Spam Settings section, enable suspected spam scanning.
d) Click Advanced to display the Add Custom Header option.
e) Add a custom header such as url_redirect .
f) Submit and commit your changes.
Step 2 Create a content filter to redirect URLs in messages that have the custom header:
a) Select Mail Policies > Incoming Content Filters.
b) Click Add Filter.
c) Name the filter url_redirect .
d) Click Add Condition.
e) Click Other Header.
f) Enter the header name: url_redirect .
Make sure this exactly matches the header you created above.
g) Select Header exists.
h) Click OK.
i) Click Add Action.
j) Click URL Category.
k) Select all categories in Available Categories and add them to Selected Categories.
l) For Action on URL, select Redirect to Cisco Security Proxy.
m) Click OK.
Step 3 Add the content filter to the mail policy.
a) Select Mail Policies > Incoming Mail Policies.
b) Click the link in the Content Filters column for the policy that you selected earlier in this procedure.
a) Select Enable Content Filters if it is not already selected.
b) Select the check box to enable the url_filtering content filter.
c) Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
403
Managing Spam and Graymail
Enabling Different Anti-Spam Scanning Engines in Different Mail Policies: Configuration Example
What to do next
Related Topics
• Redirecting URLs, on page 429
• Content Filters, on page 281
Enabling Different Anti-Spam Scanning Engines in Different Mail Policies:
Configuration Example
When using the System Setup Wizard (or systemsetup command in the CLI), you are presented with option
to enable either Cisco Intelligent Multi-Scan or the Cisco Anti-Spam engine. You cannot enable both during
system setup, but after system setup is complete you can enable the anti-spam solution that you didn’t choose,
by using the Security Services menu.
After the system is set up, you can configure the anti-spam scanning solution for incoming mail policies via
the Mail Policies > Incoming Mail Policies page. (Anti-spam scanning is typically disabled for outgoing
mail policies.) You can even disable anti-spam scanning for a policy.
In this example, the default mail policy and the “Partners” policy are using the Cisco Anti-Spam scanning
engine to quarantine positive and suspected spam.
Figure 22: Mail Policies - Anti -spam Engine Per Recipient
To change the Partners policy to use Cisco Intelligent Multi-Scan and scan for unwanted marketing messages,
click on the entry in the Anti-Spam column corresponding with the Partners row (“use default”).
Select Cisco Intelligent Multi-Scan for the scanning engine, and select Yes to enable unwanted marketing
message detection. Use the default settings for unwanted marketing message detection.
The following figure shows Cisco Intelligent Multi-Scan and unwanted marketing message detection enabled
in a policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
404
Managing Spam and Graymail
Protecting Email Gateway-Generated Messages From the Spam Filter
Figure 23: Mail Policies - Enabling Cisco Intelligent Multi-scan
After submitting and committing the changes, the mail policy looks like this:
Figure 24: Mail Policies - Intelligent Multi-Scan Enabled in Policy
Protecting Email Gateway-Generated Messages From the Spam
Filter
Because automated email messages that are sent from the email gateway (such as email alerts and scheduled
reports) may contain URLs or other information that may cause them to be incorrectly identified as spam,
you should do the following to ensure their delivery:
Include senders of these messages in an incoming mail policy that bypasses anti-spam scanning. See Creating
a Mail Policy for a Group of Senders and Recipients, on page 274and Bypass Anti-Spam System Action, on
page 219.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
405
Managing Spam and Graymail
Headers Added During Anti-Spam Scanning
Headers Added During Anti-Spam Scanning
• If either anti-spam scanning engine is enabled for a mail policy, each message that passes through that
policy will have the following headers added to the message:
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result
The second header contains information that allows Cisco Support to identify the rules and engine version
used to scan the message. Result information is encoded proprietary information and is not
customer-decodable.
• Cisco Intelligent Multi-Scan also adds headers from the third-party anti-spam scanning engines.
• You can define additional custom headers to be added to all messages for a given mail policy that are
positively identified as spam, suspected to be spam, or identified as unwanted marketing mail. See
Defining Anti-Spam Policies , on page 399.
Related Topics
• Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy:
Configuration Example , on page 403
Reporting Incorrectly Classified Messages to Cisco
Messages that appear to be incorrectly classified may be reported to Cisco for analysis. The reported messages
are used to enhance the accuracy and effectiveness of the product.
You can report incorrectly classified messages that belong to the following categories:
• Missed spam
• Message marked as a spam, but is not a spam
• Missed marketing message
• Message marked as a marketing message, but is not a marketing message
• Missed phishing message
Related Topics
• How to Report Incorrectly Classified Messages to Cisco, on page 406
• How to Track Your Submissions, on page 411
How to Report Incorrectly Classified Messages to Cisco
Before You Begin
Before you start reporting incorrectly classified messages to Cisco, you must perform the following steps.
Perform this step only once.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
406
Managing Spam and Graymail
How to Report Incorrectly Classified Messages to Cisco
Procedure
Step 1 Register as an administrator on Cisco Talos Email Status Portal can be done in any one of the following ways:
Note Cisco Talos Email Status Portal is a web-based tool that allows email administrators to view and
track email submissions on the portal.
• Registering when you are the first administrator in your organization to access the portal:
a. Log in to Cisco Talos Email Status Portal (https://talosintelligence.com/email_status_portal) using
your Cisco credentials.
b. Click Manage Account.
c. Click Add Domain.
d. Enter your organization’s domain name in the Domain field to register your domain with the portal.
Note Make sure that you enter a valid domain name, for example, example.com is the domain
name in the following email address: [email protected]. If you have multiple domains
in your organization, make sure that you add all the domains.
e. Check the I own this domain check box if you are the owner of the domain entered in step 'd.'
Note If you do not check the 'I own this domain' check box, then you will only have domain
view access rights. For more information, see the Cisco Talos Email Status Portal Help
page at https://talosintelligence.com/tickets/email_submissions/help
f. Click Submit.
After you click Submit, an email with a 6-digit character verification code is automatically sent to
[email protected] (where domain.com is the domain you entered in step 'd') to confirm the
domain ownership.
If your organization is not using [email protected] or your administrator does not have access
to the postmaster mailbox, create a message filter (on all your email gateways) to redirect messages
from [email protected] sent to [email protected] to a different email address.
The following is a sample message filter:
redirect_postmaster: if (rcpt-to == "[email protected]") AND (mail-from ==
"^[email protected]$") { alt-rcpt-to ("[email protected]"); }
g. Enter the 6-digit character verification code in the Domain Ownership Verification Code dialog
box to confirm the domain ownership.
h. Click Submit Verification Code.
After you click the Submit Verification Code button, you are automatically provided with admin
access rights. A registration ID is auto generated that can be viewed in the Manage Accounts section
of the portal. You can use the registration ID for all the email gateways in your organization.
Note A registration ID is a unique identifier to identify submissions made from the Cisco Email
Security Gateways that belong to a particular organization.
• Registering when an administrator in your organization is already registered on the portal:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
407
Managing Spam and Graymail
How to Report Incorrectly Classified Messages to Cisco
a. Log in to Cisco Talos Email Status Portal (https://talosintelligence.com/email_status_portal) using
your Cisco credentials.
b. Click Manage Account..
c. Click Add Domain.
d. Enter your organization’s domain name in the Domain field to register your domain with the portal.
Note Make sure that you enter a valid domain name, for example, example.com is the domain
name in the following email address: [email protected]. If you have multiple domains
in your organization, make sure that you add all the domains.
e. Click Submit.
After you click Submit, an email notification is sent to the administrator who is already registered on the
portal. This administrator must log in to the portal, and click Approve in the Permission Requests section of
Manage Accounts to approve your registration request.
After your registration request is approved, a registration ID is auto generated that can be viewed in the Manage
Accounts section of the portal. You can use the registration ID for all the email gateways in your organization.
Note A registration ID is a unique identifier to identify submissions made from the Cisco Email Security
Gateways that belong to a particular organization.
Step 2 Add the registration ID generated from Cisco Talos Email Status Portal for all the email gateways in your
organization.
a. Log in to your email gateways using the web interface.
b. Go to System Administration > Cisco Talos Email Status Portal Registration.
c. If your email gateway is part of a cluster, set the mode to cluster level.
d. Click Set Registration ID.
e. Enter the registration ID obtained from the Cisco Talos Email Status Portal in the Registration ID field.
f. Submit and commit your changes.
g. If your email gateway is not part of a cluster, you must repeat steps 1 through 6 on all the email gateways
in your organization.
You can also use the portalregistrationconfig command in CLI to set the registration ID.
How to Report Incorrectly Classified Messages to Cisco
For more information, see:
• How to Submit Email Messages to Cisco document at https://www.cisco.com/c/en/us/support/docs/
security/email-security-appliance/214133-how-to-submit-email-messages-to-cisco.html#anc5.
• Cisco Talos Email Status Portal Help page at https://talosintelligence.com/tickets/email_submissions/
help.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
408
Managing Spam and Graymail
Using Cisco Email Security Plug-In
Procedure
Step 1 Perform the steps mentioned in Before You Begin section of How to Report Incorrectly Classified Messages
to Cisco, on page 406 .
Step 2 Report incorrectly classified messages to Cisco using one of the following methods:
• Using Cisco Email Security Plug-In, on page 409
• Forwarding Incorrectly Classified Message as an Attachment, on page 409
After you report an incorrectly classified message to Cisco, you will receive an email notification based on
the option you select under the Email Notification and Reports button in the Manage Account section of the
portal.
Note The 'My Submission Notifications' and 'My Submission Reports' options under the 'Email Notification
and Reports' button are set to off by default. For more information, see the Cisco Talos Email Status
Portal Help page at https://talosintelligence.com/tickets/email_submissions/help
What to do next
How to Track Your Submissions, on page 411
Using Cisco Email Security Plug-In
Cisco Email Security Plug-In is a tool that allows users (email administrators and end users) to report incorrectly
classified messages to Cisco using Microsoft Outlook. When you deploy this plug-in as part of Microsoft
Outlook, a reporting menu is added to the Microsoft Outlook web interface. You can use the plug-in menu to
report incorrectly classified messages.
Additional Information
• You can download Cisco Email Security Plug-In from the following page: https://software.cisco.com/
portal/pub/download/portal/select.html?&mdfid=284900944&flowid=41782&softwareid=283090986.
• For more information, see the Cisco Email Security Plug-In Administrator Guide http://www.cisco.com/
c/en/us/support/security/email-encryption/products-user-guide-list.html.
Forwarding Incorrectly Classified Message as an Attachment
Depending on the category of the message, you can forward each incorrectly classified message as an RFC
822 attachment to the following addresses as shown in the table below:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
409
Managing Spam and Graymail
Forwarding Incorrectly Classified Message as an Attachment
Email Definition Submission Method User Consideration for
Submission Submitting
Spam / Unsolicited and undesired. Spam/Phish is spam@access. Delivered to the user’s inbox,
Phish never legitimate and may also be malicious but user considers message
ironport.com
(phish, virus, malware, scams, etc.) to be spam or Phish.
phish@access.
Detected as spam, but user
ironport.com considers message legitimate.
virus@access.
ironport.com
Outlook Plugin
‘Spam’, ‘Phish’, or
‘Virus’ button
Legiti Legitimate (good) email, not spam. Also ham@access. Marketing/graymail
known as ‘Ham.’ messages not detected as
mate ironport.com
marketing/graymail.
Outlook Plugin ‘Not
Spam’ button
Market Marketing is legitimate (not Spam) email that ads@access. Detected as spam, but user
is commercial bulk email. Usually considers message legitimate
ing / ironport.com
subscription based, sometimes unwanted.
Graymail
Outlook Plugin
Users may have knowingly or unknowingly
‘Marketing’ button
solicited mail from the sender. For example
swiping a badge at a conference or making an
online purchase, etc. Legitimate subscription
based marketing email will have a working
unsubscribe mechanism.
Graymail is a broader category that Includes
Marketing as well as other legitimate bulk
mail.
Not Legitimate email (not Spam) that is not bulk not_ads@access. Detected as
Market and not subscription based. Usually Marketing/Graymail, but user
ironport.com
person-to-person and/or transactional. considers the message to be
ing /
transactional or otherwise not
Graymail
Marketing/Graymail.
You can achieve best results if you use one of the following email programs to forward the message:
• Apple Mail
• Microsoft Outlook for Mac
• Microsoft Outlook Web App
• Mozilla Thunderbird
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
410
Managing Spam and Graymail
How to Track Your Submissions
Caution If you are using Microsoft Outlook 2010, 2013, or 2016 for Microsoft Windows, you must use the Cisco
Email Security Plug-In or the Microsoft Outlook Web App to report incorrectly classified messages. This is
because Outlook for Windows may not forward the message with the required headers intact. Also, use the
mobile platforms only if you can forward the original message as an attachment.
How to Track Your Submissions
After your receive an email notification with the submission details, you can view and track your submission
on Cisco Talos Email Status Portal.
Procedure
Step 1 Log in to Cisco Talos Email Status Portal (https://talosintelligence.com/email_status_portal) using your Cisco
credentials.
Step 2 Click Submissions on Cisco Talos Email Status Portal.
Step 3 Click Filter Options and select appropriate filter option(s).
Step 4 (Optional) Click the calendar button to choose the specific date.
What to do next
For more information, see the Cisco Talos Email Status Portal Help page at https://talosintelligence.com/
tickets/email_submissions/help.
Determining Sender IP Address In Deployments with Incoming
Relays
If one or more mail exchange/transfer agents (MX or MTA), filtering servers, etc. stand at the edge of your
network, between your email gateway and the external machines that are sending incoming mail, then your
email gateway cannot determine the IP addresses of the sending machines. Instead, mail appears to originate
from the local MX/MTA. However, IronPort Anti-Spam and Cisco Intelligent Multi-Scan (using the IP
Reputation Service) depend on accurate IP addresses for external senders.
The solution is to configure your email gateway to work with incoming relays. You specify the names and
IP addresses of all of the internal MX/MTAs connecting to the email gateway, as well as the header used to
store the originating IP address.
Related Topics
• Example Environments with Incoming Relays , on page 412
• Configuring the Email Gateway to Work with Incoming Relays, on page 413
• How Incoming Relays Affect Functionality , on page 418
• Configuring Logs to Specify Which Headers Are Used , on page 420
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
411
Managing Spam and Graymail
Example Environments with Incoming Relays
Example Environments with Incoming Relays
The following figure shows a very basic example of an incoming relay. Mail from IP address 7.8.9.1 appears
to come from IP address 10.2.3.4 because the local MX/MTA is relaying mail to the email gateway.
Figure 25: Mail Relayed by MX/MTA — Simple
The following figure shows two other, slightly more complicated examples of how mail may be relayed inside
the network and how mail may be processed by several servers within the network before it is passed to the
email gateway. In example A, mail from 7.8.9.1 passes through the firewall and is processed by an MX and
an MTA before being delivered to the email gateway. In example B, mail from 7.8.9.1 is sent to a load balancer
or other type of traffic shaping appliance and is sent to any one of a range of MXs prior to being delivered to
the email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
412
Managing Spam and Graymail
Configuring the Email Gateway to Work with Incoming Relays
Figure 26: Mail Relayed by MX/MTA — Advanced
Configuring the Email Gateway to Work with Incoming Relays
Related Topics
• Enabling the Incoming Relays Feature , on page 413
• Adding an Incoming Relay , on page 414
• Message Headers for Relayed Messages , on page 415
Enabling the Incoming Relays Feature
Note You should only enable the incoming relays feature if a local MX/MTA relays mail to your email gateway.
Procedure
Step 1 Select Network > Incoming Relays.
Step 2 Click Enable.
Step 3 Commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
413
Managing Spam and Graymail
Adding an Incoming Relay
Adding an Incoming Relay
Add incoming relays to identify:
• Each machine on your network that will relay incoming messages to your email gateway, and
• The header that will label the IP address of the original external sender.
Before You Begin
For information needed to complete these prerequisites, see Message Headers for Relayed Messages , on page
415.
• Determine whether you will use custom or received headers to identify the IP address of the original
external sender.
• If you will use custom headers:
• Determine the exact header that will label the originating IP address of relayed messages.
• For each MX, MTA, or other machine that connects to original external senders, set up that machine
to add the header name and the IP address of the original external sender to incoming messages.
Procedure
Step 1 Select Network > Incoming Relays.
Step 2 Click Add Relay.
Step 3 Enter a name for this relay.
Step 4 Enter the IP address of the MTA, MX, or other machine that connects to the email gateway to relay incoming
messages.
You can use IPv4 or IPv6 addresses, standard CIDR format, or an IP address range. For example, if you have
several MTAs at the edge of your network receiving email, you might want to enter a range of IP addresses
to include all of your MTAs, such as 10.2.3.1/8 or 10.2.3.1-10.
For IPv6 addresses, AsyncOS supports the following formats:
• 2620:101:2004:4202::0-2620:101:2004:4202::ff
• 2620:101:2004:4202::
• 2620:101:2004:4202::23
• 2620:101:2004:4202::/64
Step 5 Specify the header that will identify the IP address of the original external sender.
When entering a header, you do not need to enter the trailing colon.
a) Select the header type:
Choose custom headers (recommended) or Received headers.
b) For custom headers:
Enter the header name that you configured the relaying machine to add to relayed messages.
For example:
SenderIP
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
414
Managing Spam and Graymail
Message Headers for Relayed Messages
or
X-CustomHeader
c) For Received headers:
Enter the character or string after which the IP address will appear. Enter the number for the “hop” to
check for the IP address.
Step 6 Submit and commit your changes.
What to do next
Consider doing the following:
• Add the relaying machine to a sender group with a mail flow policy that has unlimited messages for
DHAP. For an explanation, see Incoming Relays and Directory Harvest Attack Prevention, on page 419.
• To facilitate tracking and troubleshooting, configure the email gateway logs to show which header is
used. See Configuring Logs to Specify Which Headers Are Used , on page 420.
Related Topics
• How to Configure the Email Gateway to Scan Messages for Spam, on page 384
Message Headers for Relayed Messages
You will configure your email gateway to use one of the following types of header to identify the original
sender of a relayed message:
• Custom Header , on page 415
• Received Header, on page 416
Custom Header
Using custom headers is the recommended method of identifying original senders. The machine connecting
to the original sender needs to add this custom header. The value of the header is expected to be the IP address
of the external sending machine. For example:
SenderIP: 7.8.9.1
X-CustomHeader: 7.8.9.1
If your local MX/MTA can receive mail from a variable number of hops, inserting a custom header is the
only way to enable the Incoming Relays feature. For example, in the following figure, both path C and D lead
to IP address 10.2.3.5; however, path C has two hops and path D has one. Because the number of hops can
vary in this situation, you must use a custom header in order to have Incoming Relays configured correctly.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
415
Managing Spam and Graymail
Received Header
Figure 27: Mail Relayed by MX/MTA — Variable Number of Hops
Related Topics
• Adding an Incoming Relay , on page 414
Received Header
If configuring the MX/MTAs to include a custom header containing the sending IP address is not an option,
you can configure the incoming relays feature to attempt to determine the sending IP address by examining
the “Received:” headers in the message. Using the “Received:” header will only work if the number of network
“hops” will always be constant for an IP address. In other words, the machine at the first hop (10.2.3.5 in
Figure - Mail Relayed by MX/MTA — Advanced) should always be the same number of hops away from the
edge of your network. If incoming mail can take different paths (resulting in a different number of hops, as
described in Figure - Mail Relayed by MX/MTA — Variable Number of Hops) to the machine connecting to
your email gateway, you must use a custom header (see Custom Header , on page 415).
Specify a parsing character or string and the number of network hops (or Received: headers) back to look. A
hop is basically the message traveling from one machine to another (being received by the email gateway
does not count as a hop. See Configuring Logs to Specify Which Headers Are Used , on page 420for more
information). AsyncOS looks for the first IP address following the first occurrence of the parsing character
or string in the Received: header corresponding to the number of specified hops. For example, if you specify
two hops, the second Received: header, working backward from the email gateway is parsed. If neither the
parsing character nor a valid IP address is found, the email gateway uses the real IP address of the connecting
machine.
For the following example mail headers, if you specify an opening square bracket ( [ ) and two hops, the IP
address of the external machine is 7.8.9.1. However, if you specify an closing parenthesis ( ) ) as the parsing
character, a valid IP address will not be found. In this case, the Incoming Relays feature is treated as disabled,
and the IP of the connecting machine is used (10.2.3.5).
In the example in Figure - Mail Relayed by MX/MTA — Advanced the incoming relays are:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
416
Managing Spam and Graymail
Received Header
• Path A — 10.2.3.5 (with 2 hops when using received headers) and
• Path B — 10.2.6.1 (with 2 hops when using received headers)
The following table shows example email headers for a message as it moves through several hops on its way
to the email gateway as in Figure - Mail Relayed by MX/MTA — Advanced. This example shows extraneous
headers (ignored by your email gateway) which are present once the message has arrived in the recipient’s
inbox. The number of hops to specify would be two.
Table 38: A Series of Received: Headers (Path A Example 1)
1 Microsoft Mail Internet Headers Version 2.0
Received: from smemail.rand.org ([10.2.2.7]) by smmail5.customerdoamin.org with
Microsoft SMTPSVC(5.0.2195.6713);
Received: from ironport.customerdomain.org ([10.2.3.6]) by
smemail.customerdoamin.org with Microsoft SMTPSVC(5.0.2195.6713);
2 Received: from mta.customerdomain.org ([10.2.3.5]) by ironport.customerdomain.org
with ESMTP; 21 Sep 2005 13:46:07 -0700
3 Received: from mx.customerdomain.org (mx.customerdomain.org) [10.2.3.4]) by
mta.customerdomain.org (8.12.11/8.12.11) with ESMTP id j8LKkWu1008155 for
4 Received: from sending-machine.spamham.com (sending-machine.spamham.com [7.8.9.1])
by mx.customerdomain.org (Postfix) with ESMTP id 4F3DA15AC22 for
5 Received: from linux1.thespammer.com (HELO linux1.thespammer.com) ([10.1.1.89])
by sending-machine.spamham.com with ESMTP;
Received: from exchange1.thespammer.com ([10.1.1.111]) by linux1.thespammer.com
with Microsoft SMTPSVC(6.0.3790.1830);
Subject: Would like a bigger paycheck?
Date: Wed, 21 Sep 2005 13:46:07 -0700
From: "A. Sender" <[email protected]>
To: <[email protected]>
Notes for the above table:
• The email gateway ignores these headers.
• The email gateway receives the message (not counted as a hop).
• First hop (and incoming relay).
• Second hop. This is the sending MTA. The IP address is 7.8.9.1.
• The email gateway ignores these Microsoft Exchange headers.
The following table shows the headers for the same email message, without the extraneous headers
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
417
Managing Spam and Graymail
How Incoming Relays Affect Functionality
Table 39: A Series of Received: Headers (Path A Example 2)
1 Received: from mta.customerdomain.org ([10.2.3.5]) by ironport.customerdomain.org
with ESMTP; 21 Sep 2005 13:46:07 -0700
2 Received: from mx.customerdomain.org (mx.customerdomain.org) [10.2.3.4]) by
mta.customerdomain.org (8.12.11/8.12.11) with ESMTP id j8LKkWu1008155 for
3 Received: from sending-machine.spamham.com (sending-machine.spamham.com [7.8.9.1])
by mx.customerdomain.org (Postfix) with ESMTP id 4F3DA15AC22 for
The following figure shows the incoming relay for path A (above) as configured in the Add Relay page in
the GUI:
Figure 28: A Configured Incoming Relay with Received Header
Related Topics
• Adding an Incoming Relay , on page 414
How Incoming Relays Affect Functionality
• Incoming Relays and Filters, on page 418
• Incoming Relays, HAT, IP Reputation Score, and Sender Groups, on page 419
• Incoming Relays and Directory Harvest Attack Prevention, on page 419
• Incoming Relays and Trace, on page 419
• Incoming Relays and Email Security Monitor (Reporting) , on page 419
• Incoming Relays and Message Tracking, on page 419
• Incoming Relays and Logging , on page 419
Incoming Relays and Filters
The Incoming Relays feature provides the various IP Reputation Service related filter rules (reputation,
no-reputation) with the correct IP Reputation score.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
418
Managing Spam and Graymail
Incoming Relays, HAT, IP Reputation Score, and Sender Groups
Incoming Relays, HAT, IP Reputation Score, and Sender Groups
HAT policy groups do not currently use information from Incoming Relays. However, because the Incoming
Relays feature does supply the Reputation score, you can simulate HAT policy group functionality via message
filters and the $reputation variable.
Incoming Relays and Directory Harvest Attack Prevention
If a remote host attempts a directory harvest attack by sending messages to the MX or MTA serving as an
incoming relay on your network, the email gateway drops the connection from the incoming relay if the relay
is assigned to a sender group with a mail flow policy with Directory Harvest Attack Prevention (DHAP)
enabled. This prevents all messages from the relay, including legitimate messages, from reaching the email
gateway. The email gateway does not have the opportunity to recognize the remote host as the attacker and
the MX or MTA that’s acting as the incoming relay continues to receive mail from the attacking host. To
work around this issue and continue receiving messages from the incoming relay, add the relay to a sender
group with a mail flow policy that has unlimited messages for DHAP.
Incoming Relays and Trace
Trace returns the Incoming Relay’s IP Reputation Score in its results instead of the reputation score for the
source IP address.
Incoming Relays and Email Security Monitor (Reporting)
When using Incoming Relays:
• Email Security Monitor reports include data for both the external IP and the MX/MTA. For example, if
an external machine (IP 7.8.9.1) sent 5 emails through the internal MX/MTA (IP 10.2.3.4), Mail Flow
Summary will show 5 messages coming from IP 7.8.9.1 and 5 more coming from the internal relay
MX/MTA (IP 10.2.3.5).
• The IP Reputation score is not reported correctly in the Email Security Monitor reports. Also, sender
groups may not be resolved correctly.
Incoming Relays and Message Tracking
When using Incoming Relays, the Message Tracking Details page displays the relay’s IP address and the
relay’s IP Reputation Score for a message instead of the IP address and reputation score of the original external
sender.
Incoming Relays and Logging
In the following log example, the IP Reputation score for the sender is reported initially on line 1. Later, once
the Incoming Relay is processed, the correct IP Reputation score is reported on line 5.
1 Fri Apr 28 17:07:29 2006 Info: ICID 210158 ACCEPT SG UNKNOWNLIST match
nx.domain IPR rfc1918
2 Fri Apr 28 17:07:29 2006 Info: Start MID 201434 ICID 210158
3 Fri Apr 28 17:07:29 2006 Info: MID 201434 ICID 210158 From: <[email protected]>
4 Fri Apr 28 17:07:29 2006 Info: MID 201434 ICID 210158 RID 0 To:
<[email protected]>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
419
Managing Spam and Graymail
Incoming Relays and Mail Logs
5 Fri Apr 28 17:07:29 2006 Info: MID 201434 IncomingRelay(senderdotcom): Header
Received found, IP 192.192.108.1 being used, IPR 6.8
6 Fri Apr 28 17:07:29 2006 Info: MID 201434 Message-ID
'<[email protected]>'
7 Fri Apr 28 17:07:29 2006 Info: MID 201434 Subject 'That report...'
8 Fri Apr 28 17:07:29 2006 Info: MID 201434 ready 2367 bytes from <[email protected]>
9 Fri Apr 28 17:07:29 2006 Info: MID 201434 matched all recipients for per-recipient
policy DEFAULT in the inbound table
10 Fri Apr 28 17:07:34 2006 Info: ICID 210158 close
11 Fri Apr 28 17:07:35 2006 Info: MID 201434 using engine: CASE spam negative
12 Fri Apr 28 17:07:35 2006 Info: MID 201434 antivirus negative
13 Fri Apr 28 17:07:35 2006 Info: MID 201434 queued for delivery
Incoming Relays and Mail Logs
The following example shows a typical log entry containing Incoming Relay information:
Wed Aug 17 11:20:41 2005 Info: MID 58298 IncomingRelay(myrelay): Header Received found, IP
192.168.230.120 being used
Configuring Logs to Specify Which Headers Are Used
Your email gateway only examines the headers that were present when the message was received. So, additional
headers added locally (such as Microsoft Exchange headers, etc.) or when the message is received by the
email gatewayare not processed. One way to help determine which headers are used is to configure AsyncOS
logging to include the headers you use.
To configure logging settings for headers, see Configuring Global Settings for Logging, on page 1209.
Monitoring Rules Updates
Once you have accepted the license agreement, you can view the most recent Cisco Anti-Spam and Cisco
Intelligent Multi-Scan rules updates.
Procedure
Step 1 Select Security Services > IronPort Anti-Spam.
or
Step 2 Select Security Services > IMS and Graymail.
Step 3 Look at the Rule Updates section and:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
420
Managing Spam and Graymail
Testing Anti-Spam
To More Information
See the most recent update for each component If an update has not occurred, or a server has not been
configured, “Never Updated” is displayed.
See if an update is available —
Update rules if updates are available Click Update Now.
What to do next
Related Topics
• Service Updates , on page 1026
• UpdatesThrough a Proxy Server, on page 1030
• Configuring Server Settings for Downloading Upgrades and Updates , on page 1030
Testing Anti-Spam
To Do This More Information
Test your Test your configuration using the The test message you send with this header is
configuration. X-advertisement: spam header. flagged by Cisco Anti-Spam, and you can confirm
that the actions you configured for the mail policy
For testing purposes, Cisco Anti-Spam
(Defining Anti-Spam Policies , on page 399) are
considers any message with an
performed.
X-header formatted as
X-Advertisement: spam to be spam. Use this header with one of the following:
• Use SMTP commands to send a test message
with this header. See Sending an Email to
the Email Gateway to Test Cisco Anti-Spam,
on page 422.
• Use the trace command and include this
header. See Debugging Mail Flow Using
Test Messages: Trace, on page 1249.
Evaluate Evaluate the product using a live mail For a list of ineffective evaluation approaches that
Anti-Spam engine stream directly from the Internet. you should avoid, see Ways Not to Test
efficacy. Anti-Spam Efficacy, on page 423.
Related Topics
• Sending an Email to the Email Gateway to Test Cisco Anti-Spam, on page 422
• Ways Not to Test Anti-Spam Efficacy, on page 423
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
421
Managing Spam and Graymail
Sending an Email to the Email Gateway to Test Cisco Anti-Spam
Sending an Email to the Email Gateway to Test Cisco Anti-Spam
Before You Begin
Review the example in Testing Anti-Spam Configuration: Example Using SMTP, on page 422.
Procedure
Step 1 Enable Cisco Anti-Spam on a mail policy.
Step 2 Send a test email that includes the following header to a user in that mail policy: X-Advertisement: spam
Use SMTP commands with Telnet to send this message to an address to which you have access.
Step 3 Check the mailbox of the test account and confirm that the test message was correctly delivered based upon
the actions you configured for the mail policy.
For example:
• Was the subject line altered?
• Was your additional custom header added?
• Was the message delivered to an alternate address?
• Was the message dropped?
Related Topics
• Testing Anti-Spam Configuration: Example Using SMTP, on page 422
Testing Anti-Spam Configuration: Example Using SMTP
For this example, the mail policy must be configured to receive messages for the test address and the HAT
must accept the test connection.
# telnet IP_address_of_IronPort_Appliance_with_IronPort_Anti-Spam port
220 hostname ESMTP
helo example.com
250 hostname
mail from: <[email protected]>
250 sender <[email protected]> ok
rcpt to: <test@address>
250 recipient <test@address>
ok
data
354 go ahead
Subject: Spam Message Test
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
422
Managing Spam and Graymail
Ways Not to Test Anti-Spam Efficacy
X-Advertisement: spam
spam test
250 Message MID accepted
221 hostname
quit
Ways Not to Test Anti-Spam Efficacy
Because IronPort AntiSpam and Cisco Intelligent Multi-Scan rules are added quickly to prevent active spam
attacks and quickly expire once attacks have passed, you should not test efficacy using any of the following
methods:
• Evaluating using resent or forwarded mail or cut-and-pasted spam messages.
Mail lacking the proper headers, connecting IP, signatures, etc. will result in inaccurate scores.
• Testing “hard spam” only.
Removing the “easy spam” using IP Reputation Service, blocked lists, message filters, etc. will result in
a lower overall catch rate percentage.
• Resending spam caught by another anti-spam vendor.
• Testing older messages.
The scanning engine adds and removes rules rapidly based on current threats. Testing using old messages
will therefore lead to inaccurate test results.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
423
Managing Spam and Graymail
Ways Not to Test Anti-Spam Efficacy
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
424
CHAPTER 19
Outbreak Filters
This chapter contains the following sections:
• Overview of Outbreak Filters, on page 425
• How Outbreak Filters Work, on page 425
• How the Outbreak Filters Feature Works, on page 432
• Managing Outbreak Filters, on page 435
• Monitoring Outbreak Filters, on page 445
• Troubleshooting The Outbreak Filters Feature, on page 446
Overview of Outbreak Filters
Outbreak Filters protects your network from large-scale virus outbreaks and smaller, non-viral attacks, such
as phishing scams and malware distribution, as they occur. Unlike most anti-malware security software, which
cannot detect new outbreaks until data is collected and a software update is published, Cisco gathers data on
outbreaks as they spread and sends updated information to your email gateway in real-time to prevent these
messages from reaching your users.
Cisco uses global traffic patterns to develop rules that determine if an incoming message is safe or part of an
outbreak. Messages that may be part of an outbreak are quarantined until they’re determined to be safe based
on updated outbreak information from Cisco or new anti-virus definitions are published by Sophos and McAfee.
Messages used in small-scale, non-viral attacks use a legitimate-looking design, the recipient’s information,
and custom URLs that point to phishing and malware websites that have been online only for a short period
of time and are unknown to web security services. Outbreak Filters analyzes a message’s content and searches
for URL links to detect this type of non-viral attack. Outbreak Filters can rewrite URLs to redirect traffic to
potentially harmful websites through a web security proxy, which either warns users that the website they are
attempting to access may be malicious or blocks the website completely.
How Outbreak Filters Work
Related Topics
• Delaying, Redirecting, and Modifying Messages, on page 426
• Threat Categories, on page 426
• Cisco Security Intelligence Operations, on page 427
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
425
Outbreak Filters
Delaying, Redirecting, and Modifying Messages
• Context Adaptive Scanning Engine, on page 428
• Delaying Messages, on page 428
• Redirecting URLs, on page 429
• Modifying Messages, on page 430
• Types of Rules: Adaptive and Outbreak, on page 430
• Outbreaks, on page 431
• Threat Levels, on page 431
Delaying, Redirecting, and Modifying Messages
The Outbreak Filters feature uses three tactics to protect your users from outbreaks:
• Delay. Outbreak Filters quarantines messages that may be part of a virus outbreak or non-viral attack.
While quarantined, the email gateways receives updated outbreak information and rescans the message
to confirm whether it’s part of an attack.
Note If a spam positive message is identified as outbreak positive by Outbreak Filters,
the message is not sent to Outbreak Quarantine.
• Redirect. Outbreak Filters rewrites the URLs in non-viral attack messages to redirect the recipient through
the Cisco web security proxy if they attempt to access any of the linked websites. The proxy displays a
splash screen that warns the user that the website may contain malware, if the website is still operational,
or displays an error message if the website has been taken offline. See Redirecting URLs, on page 429
for more information on redirecting URLs.
• Modify. In addition to rewriting URLs in non-viral threat messages, Outbreak Filters can modify a
message’s subject and add a disclaimer above the message body to warn users about the message’s
content. See Modifying Messages, on page 430 for more information.
Threat Categories
The Outbreak Filters feature provides protection from two categories of message-based outbreaks: virus
outbreaks , which are messages with never-before-seen viruses in their attachments, and non-viral threats ,
which includes phishing attempts, scams, and malware distribution through links to an external website.
By default, the Outbreak Filters feature scans your incoming and outgoing messages for possible viruses
during an outbreak. You can enable scanning for non-viral threats in addition to virus outbreaks if you enable
anti-spam scanning on the email gateway.
Note Your email gateway needs a feature key for Anti-Spam or Intelligent Multi-Scan in order for Outbreak Filters
to scan for non-viral threats.
Related Topics
• Virus Outbreaks, on page 427
• Phishing, Malware Distribution, and Other Non-Viral Threats, on page 427
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
426
Outbreak Filters
Virus Outbreaks
Virus Outbreaks
The Outbreak Filters feature provides you with a head start when battling virus outbreaks. An outbreak occurs
when messages with attachments containing never-before-seen viruses or variants of existing viruses spread
quickly through private networks and the Internet. As these new viruses or variants hit the Internet, the most
critical period is the window of time between when the virus is released and when the anti-virus vendors
release an updated virus definition. Having advanced notice — even a few hours — is vital to curbing the
spread of the malware or virus. During that vulnerability window, the newly-found virus can propagate
globally, bringing email infrastructure to a halt.
Phishing, Malware Distribution, and Other Non-Viral Threats
Messages containing non-viral threats are designed to look like a message from a legitimate sources and often
sent out to a small number of recipients. These messages may have one or more of the following characteristics
in order to appear trustworthy:
• The recipient’s contact information.
• HTML content designed to mimic emails from legitimate sources, such as social networks and online
retailers.
• URLs pointing to websites that have new IP addresses and are online only for a short time, which means
that email and web security services do not have enough information on the website to determine if it is
malicious.
• URLs pointing to URL shortening services.
All of these characteristics make these messages more difficult to detect as spam. The Outbreak Filters feature
provides a multi-layer defense from these non-viral threats to prevent your users from downloading malware
or providing personal information to suspicious new websites.
If CASE discovers URLs in the message, it compares the message to existing Outbreak Rules to determine
if the message is part of a small-scale non-viral outbreak and then assigns a threat level. Depending on the
threat level, the email gateway delays delivery to the recipient until more threat data can be gathered and
rewrites the URLs in the message to redirect the recipient to the Cisco web security proxy if they attempt to
access the website. The proxy displays a splash page warning the user that the website may contain malware.
Cisco Security Intelligence Operations
Cisco Security Intelligence Operations (SIO) is a security ecosystem that connects global threat information,
reputation-based services, and sophisticated analysis to email gateways to provide stronger protection with
faster response times.
SIO consists of three components:
• SenderBase. The world’s largest threat monitoring network and vulnerability database.
• Threat Operations Center (TOC). A global team of security analysts and automated systems that extract
actionable intelligence gathered by SenderBase.
• Dynamic Update. Real-time updates automatically delivered to email gateways as outbreaks occur.
SIO compares real-time data from the global SenderBase network to common traffic patterns to identify
anomalies that are proven predictors of an outbreak. TOC reviews the data and issues a threat level of the
possible outbreak. The email gateways download updated threat levels and Outbreak Rules and use them to
scan incoming and outgoing messages, as well as messages already in the Outbreak quarantine.
Information about current virus outbreaks can be found on SenderBase’s website here:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
427
Outbreak Filters
Context Adaptive Scanning Engine
http://www.senderbase.org/
The SIO website provides a list of current non-viral threats, including spam, phishing, and malware distribution
attempts:
http://tools.cisco.com/security/center/home.x
Context Adaptive Scanning Engine
Outbreak Filters are powered by Cisco’s unique Context Adaptive Scanning Engine (CASE). CASE leverages
over 100,000 adaptive message attributes tuned automatically and on a regular basis, based on real-time
analysis of messaging threats.
For virus outbreaks, CASE analyzes the message content, context and structure to accurately determine likely
Adaptive Rule triggers. CASE combines Adaptive Rules and the real-time Outbreak Rules published by SIO
to evaluate every message and assign a unique threat level.
To detect non-viral threats, CASE scans messages for URLs and uses Outbreak Rules from SIO to evaluate
a message’s threat level if one or more URLs are found.
Based on the message’s threat level, CASE recommends a period of time to quarantine the message to prevent
an outbreak. CASE also determines the rescan intervals so it can reevaluate the message based on updated
Outbreak Rules from SIO. The higher the threat level, the more often it rescans the message while it is
quarantined.
CASE also rescans messages when they’re released from the quarantine. A message can be quarantined again
if CASE determines that it is spam or contains a virus upon rescan.
For more information about CASE, see Cisco Anti-Spam: an Overview , on page 386.
Delaying Messages
The period between when an outbreak or email attack occurs and when software vendors release updated rules
is when your network and your users are the most vulnerable. A modern virus can propagate globally and a
malicious website can deliver malware or collect your users’ sensitive information during this period. Outbreak
Filters protects your users and network by quarantining suspect messages for a limited period of time, giving
Cisco and other vendors time to investigate the new outbreak.
When a virus outbreak occurs, suspicious messages with attachments are quarantined until updated Outbreak
Rules and new anti-virus signatures prove the email’s attachment is clean or a virus.
Small scale, non-viral threats contain URLs to malicious websites that may be online for a short period of
time in order to evade detection by web security services or through URL shortening services in order to
circumvent web security by putting a trustworthy website in the middle. By quarantining messages containing
URLs that meet your threat level threshold, not only does CASE have the opportunity to reevaluate the
message’s content based on updated Outbreak Rules from SIO, but the messages can remain in the quarantine
long enough that the linked website may go offline or be blocked by a web security solution.
See Dynamic Quarantine, on page 433 for more information on how Outbreak Filters quarantine suspicious
messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
428
Outbreak Filters
Redirecting URLs
Redirecting URLs
When CASE scans a message at the Outbreak Filters stage, it searches for URLs in the message body in
addition to other suspicious content. CASE uses published Outbreak Rules to evaluate whether the message
is a threat and then scores the message with the appropriate threat level. Depending on the threat level, Outbreak
Filters protects the recipient by rewriting all the URLs to redirect the recipient to the Cisco web security proxy,
except for URLs pointing to bypassed domains, and delaying the delivery of the message in order for TOC
to learn more about the website if it appears to be part of a larger outbreak. See URL Rewriting and Bypassing
Domains, on page 442 for more information on bypassing URLs for trusted domains.
After the email gateway releases and delivers the message, any attempt by the recipient to access the website
is redirected through the Cisco web security proxy. This is an external proxy hosted by Cisco that displays a
splash screen that warns the user that the website may be dangerous, if the website is still operational. If the
website has been taken offline, the splash screen displays an error message.
If the recipient decides to click the message’s URLs, the Cisco web security proxy displays a splash screen
in the user’s web browser to warn the user about the content of the message. The following figure shows an
example of the splash screen warning. The recipient can either click Ignore this warning to continue on to
the website or Exit to leave and safely close the browser window.
Figure 29: Cisco Security Splash Screen Warning (proxy_splash_screen)
The only way to access the Cisco web security proxy is through a rewritten URL in a message. You cannot
access the proxy by typing a URL in your web browser.
Note You can customize the appearance of this splash screen and display your organization’s branding such as
company logo, contact information, and so on. See Customizing the Notification That End Users See If a Site
Is Malicious , on page 455.
Tip To redirect all URLs in suspected spam messages to the Cisco Web Security proxy service, see Using Custom
Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy: Configuration Example , on
page 403.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
429
Outbreak Filters
Modifying Messages
Modifying Messages
The Outbreak Filters feature modifies the message body of a non-viral threat message not only to rewrite the
URLs but to alert the user that the message is a suspected threat. The Outbreak Filters feature can modify the
subject header and add a disclaimer about the message’s content above the message body. See Message
Modification, on page 441 for more information.
The threat disclaimer is created using the Disclaimer template through the Mail Policies > Text Resources
page. See Overview of Text Resource Management, on page 652 for more information.
Types of Rules: Adaptive and Outbreak
Two types of rules are used by Outbreak Filters to detect potential outbreaks: Adaptive and Outbreak. The
Outbreak Filters feature uses these two rule sets to provide the highest efficacy and the most focused set of
criteria for threat detection to ensure that filters can be laser focused on a particular outbreak. The Outbreak
Filters rules and actions are visible to the administrator, not hidden away behind the scenes, providing instant
access to quarantined messages and the reason why they were quarantined.
Related Topics
• Adaptive Rules, on page 430
• Outbreak Rules, on page 430
Outbreak Rules
Outbreak Rules are generated by the Cisco Threat Operations Center (TOC), which is a part of the Cisco
Security Intelligence Operations, and focus on the message as a whole, rather than just attachment filetypes.
Outbreak Rules use SenderBase data (real time and historical traffic data) and any combination of message
parameters such as attachment file type, file name keywords, or anti-virus engine update to recognize and
prevent outbreaks in real time. Outbreak Rules are given a unique ID used to refer to the rule in various places
in the GUI (such as the Outbreak quarantine).
Real-time data from the global SenderBase network is then compared to this baseline, identifying anomalies
that are proven predictors of an outbreak. The TOC reviews the data and issues a threat indicator or Threat
Level. The Threat Level is a numeric value between 0 (no threat) and 5 (extremely risky), and measures the
likelihood that a message is a threat for which no other gateway defense is widely deployed by Cisco customers
(for more information, see Threat Levels, on page 431). Threat Levels are published as Outbreak Rules by the
TOC.
Some example characteristics that can be combined in Outbreak Rules include:
• File Type, File Type & Size, File Type & File Name Keyword, etc.
• File Name Keyword & File Size
• File Name Keyword
• Message URL
• File Name & Sophos IDE
Adaptive Rules
Adaptive Rules are a set of rules within CASE that accurately compare message attributes to attributes of
known virus outbreak messages. These rules have been created after studying known threat messages and
known good messages within an extensive virus corpus. Adaptive Rules are updated often as the corpus is
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
430
Outbreak Filters
Outbreaks
evaluated. They complement existing Outbreak Rules to detect outbreak messages at all times. While Outbreak
Rules take effect when a possible outbreak is occurring, Adaptive Rules (once enabled) are “always on,”
catching outbreak messages locally before the full anomaly has formed on a global basis. Additionally,
Adaptive Rules continuously respond to small and subtle changes in email traffic and structure, providing
updated protection to customers.
Outbreaks
A Outbreak Filter rule is basically a Threat Level (e.g. 4) associated with a set of characteristics for an email
message and attachment — things such as file size, file type, file name, message content, and so on. For
example, assume the Cisco SIO notices an increase in the occurrences of a suspicious email message carrying
a .exe attachment that is 143 kilobytes in size, and whose file name includes a specific keyword (“hello” for
example). An Outbreak Rule is published increasing the Threat Level for messages matching this criteria.
Your email gateway checks for and downloads newly published Outbreak and Adaptive Rules every 5 minutes
by default (see Updating Outbreak Filter Rules, on page 439). Adaptive Rules are updated less frequently than
Outbreak Rules. On the email gateway, you set a threshold for quarantining suspicious messages. If the Threat
Level for a message equals or exceeds the quarantine threshold, the message is sent to the Outbreak quarantine
area. You can also set up a threshold for modifying non-viral threat messages to rewrite any URLs found in
suspicious messages or add a notification at the top of message body.
Threat Levels
The following table provides a basic set of guidelines or definitions for each of the various levels.
Level Risk Meaning
0 None There is no risk that the message is a threat.
1 Low The risk that the message is a threat is low.
2 Low/Medium The risk that the message is a threat is low to medium. It is a “suspected” threat.
3 Medium Either the message is part of a confirmed outbreak or there is a medium to large
risk of its content being a threat.
4 High Either the message is confirmed to be part of a large scale outbreak or its content
is very dangerous.
5 Extreme The message’s content is confirmed to part of an outbreak that is either extremely
large scale or large scale and extremely dangerous.
For more information about threat levels and outbreak rules, see Outbreak Filters Rules, on page 438.
Related Topics
• Guidelines for Setting Your Quarantine Threat Level Threshold, on page 431
• Containers: Specific and Always Rules, on page 432
Guidelines for Setting Your Quarantine Threat Level Threshold
The quarantine threat level threshold allows administrators to be more or less aggressive in quarantining
suspicious messages. A low setting (1 or 2) is more aggressive and will quarantine more messages; conversely,
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
431
Outbreak Filters
Containers: Specific and Always Rules
a higher score (4 or 5) is less aggressive and will only quarantine messages with an extremely high likelihood
of being malicious.
The same threshold applies to both virus outbreaks and non-virus threats, but you can specify different
quarantine retention times for virus attacks and other threats. See Dynamic Quarantine, on page 433 for more
information.
Cisco recommends the default value of 3.
Containers: Specific and Always Rules
Container files are files, such as zipped (.zip) archives, that contain other files. The TOC can publish rules
that deal with specific files within archive files.
For example, if a virus outbreak is identified by TOC to consist of a .zip file containing a .exe, a specific
Outbreak Rule is published that sets a threat level for .exe files within .zip files (.zip(exe)), but does not set
a specific threat level for any other file type contained within .zip files (e.g. .txt files). A second rule (.zip(*))
covers all other file types within that container file type. An Always rule for a container will always be used
in a message's Threat Level calculation regardless of the types of files that are inside a container. An always
rule will be published by the SIO if all such container types are known to be dangerous.
Table 40: Fallback Rules and Threat Level Scores
Outbreak Rule Threat Level Description
.zip(exe) 4 This rule sets a threat level of 4 for .exe files within .zip files.
.zip(doc) 0 This rule sets a threat level of 0 for .doc files within .zip files.
zip(*) 2 This rule sets a threat level of 2 for all .zip files, regardless of the types of files
they contain.
How the Outbreak Filters Feature Works
Email messages pass through a series of steps, the “email pipeline,” when being processed by your email
gateway (for more information about the email pipeline, see Understanding the Email Pipeline, on page 65).
As the messages proceed through the email pipeline, they are run through the anti-spam and anti-virus scanning
engines if those engines are enabled for that mail policy. In other words, known spam or messages containing
recognized viruses are not scanned by the Outbreak Filters feature because they will have already been removed
from the mail stream — deleted, quarantined, etc. — based on your anti-spam and anti-virus settings. Messages
that arrive at the Outbreak Filters feature have therefore been marked spam- and virus-free. Note that a message
quarantined by Outbreak Filters may be marked as spam or containing a virus when it is released from the
quarantine and rescanned by CASE, based on updated spam rules and virus definitions.
Note Messages that skip anti-spam and anti-virus scanning due to filters or the engines being disabled will still be
scanned by Outbreak Filters.
Related Topics
• Message Scoring, on page 433
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
432
Outbreak Filters
Message Scoring
• Dynamic Quarantine, on page 433
Message Scoring
When a new virus attack or non-viral threat is released into the wild, no anti-virus or anti-spam software is
able to recognize the threat yet, so this is where the Outbreak Filters feature can be invaluable. Incoming
messages are scanned and scored by CASE using the published Outbreak and Adaptive Rules (see Types of
Rules: Adaptive and Outbreak, on page 430). The message score corresponds with the message’s threat level.
Based on which, if any, rules the message matches, CASE assigns the corresponding threat level. If there is
no associated threat level (the message does not match any rules), then the message is assigned a threat level
of 0.
Once that calculation has been completed, the email gateway checks whether the threat level of that message
meets or exceeds your quarantine or message modification threshold value and quarantines message or rewrites
its URLs. It the threat level is below the thresholds, it will be passed along for further processing in the pipeline.
Additionally, CASE reevaluates existing quarantined messages against the latest rules to determine the latest
threat level of a message. This ensures that only messages that have a threat level consistent with an outbreak
message stay within the quarantine and messages that are no longer a threat flow out of the quarantine after
an automatic reevaluation.
In the case of multiple scores for an outbreak message — one score from an Adaptive Rule (or the highest
score if multiple Adaptive Rules apply), and another score from an Outbreak Rule (or the highest score if
multiple Outbreak Rules apply) — intelligent algorithms are used to determine the final threat level.
It is possible to use the Outbreak Filters feature without having enabled anti-virus scanning on the email
gateway. The two security services are designed to complement each other, but will also work separately.
That said, if you do not enable anti-virus scanning on your email gateway, you will need to monitor your
anti-virus vendor’s updates and manually release or re-evaluate some messages in the Outbreak quarantine.
When using Outbreak Filters without anti-virus scanning enabled, keep the following in mind:
• You should disable Adaptive Rules
• Messages will get quarantined by Outbreak Rules
• Messages will get released if the threat level is lowered or time expires
Downstream anti-virus vendors (desktops/groupware) may catch the message on release.
Note Anti-spam scanning needs to be enabled globally on an email gateway for the Outbreak Filters feature to scan
for non-viral threats.
Dynamic Quarantine
The Outbreak Filters feature’s Outbreak quarantine is a temporary holding area used to store messages until
they’re confirmed to be threats or it’s safe to deliver to users. (See Outbreak Lifecycle and Rules Publishing,
on page 434 for more information.) Quarantined messages can be released from the Outbreak quarantine in
several ways. As new rules are downloaded, messages in the Outbreak quarantine are reevaluated based on
a recommended rescan interval calculated by CASE. If the revised threat level of a message falls under the
quarantine retention threshold, the message will automatically be released (regardless of the Outbreak
quarantine’s settings), thereby minimizing the time it spends in the quarantine. If new rules are published
while messages are being re-evaluated, the rescan is restarted.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
433
Outbreak Filters
Outbreak Lifecycle and Rules Publishing
Please note that messages quarantined as virus attacks are not automatically released from the outbreak
quarantine when new anti-virus signatures are available. New rules may or may not reference new anti-virus
signatures; however, messages will not be released due to an anti-virus engine update unless an Outbreak
Rule changes the threat level of the message to a score lower than your Threat Level Threshold.
Messages are also released from the Outbreak quarantine after CASE’s recommended retention period has
elapsed. CASE calculates the retention period based on the message’s threat level. You can define separate
maximum retention times for virus outbreaks and non-viral threats. If CASE’s recommended retention time
exceeds the maximum retention time for the threat type, the email gateway releases messages when the
maximum retention time elapses. For viral messages the default maximum quarantine period is 1 day. The
default period for quarantining non-viral threats is 4 hours. You can manually release messages from the
quarantine.
The email gateway also releases messages when the quarantine is full and more messages are inserted (this
is referred to as overflow). Overflow only occurs when the Outbreak quarantine is at 100% capacity, and a
new message is added to the quarantine. At this point, messages are released in the following order of priority:
• Messages quarantined by Adaptive Rules (those scheduled to be released soonest are first)
• Messages quarantined by Outbreak Rules (those scheduled to be released soonest are first)
Overflow releases stop the moment the Outbreak quarantine is below 100% capacity. For more information
about how quarantine overflow is handled, see Retention Time for Messages in Quarantines , on page 930 and
Default Actions for Automatically Processed Quarantined Messages , on page 931.
Messages released from the Outbreak quarantine are scanned by the anti-virus and anti-spam engines again
if they’re enabled for the mail policy. If it is now marked as a known virus or spam, then it will be subject to
your mail policy settings (including a possible second quarantining in the Virus quarantine or Spam quarantine).
For more information, see The Outbreak Filters Feature and the Outbreak Quarantine, on page 443.
Thus it is important to note that in a message's lifetime, it may actually be quarantined twice — once due to
the Outbreak Filters feature, and once when it is released from the Outbreak quarantine. A message will not
be subject to a second quarantine if the verdicts from each scan (prior to Outbreak Filters, and when released
from the Outbreak quarantine) match. Also note that the Outbreak Filters feature does not take any final actions
on messages. The Outbreak Filters feature will either quarantine a message (for further processing) or move
the message along to the next step in the pipeline.
Related Topics
• Outbreak Lifecycle and Rules Publishing, on page 434
Outbreak Lifecycle and Rules Publishing
Very early in a virus outbreak’s life cycle, broader rules are used to quarantine messages. As more information
becomes available, increasingly focused rules are published, narrowing the definition of what is quarantined.
As the new rules are published, messages that are no longer considered possible virus messages are released
from quarantine (messages in the outbreak quarantine are rescanned as new rules are published).
Table 41: Example Rules for an Outbreak Lifecycle
Time Rule Type Rule Description Action
T=0 Adaptive Rule A consolidated rule set based on Messages are automatically
(based on past over 100K message attributes, quarantined if they match
outbreaks) which analyzes message content, Adaptive Rules
context and structure
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
434
Outbreak Filters
Managing Outbreak Filters
Time Rule Type Rule Description Action
T=5 min Outbreak Rule Quarantine messages containing Quarantine all attachments that
.zip (exe) files are .zips containing a .exe
T=10 min Outbreak Rule Quarantine messages that have .zip Any message with .zip (exe)
(exe) files greater than 50 KB files that are less than 50 KB
would be released from
quarantine
T=20 min Outbreak Rule Quarantine messages that have .zip Any message that does not
(exe) files between 50 to 55 KB, match this criteria would be
and have “Price” in the file name released from quarantine
T=12 hours Outbreak Rule Scan against new signature All remaining messages are
scanned against the latest
anti-virus signature
Managing Outbreak Filters
Log in to the Graphical User Interface (GUI), select Security Services in the menu, and click Outbreak Filters.
Figure 30: Outbreak Filters Main Page
The Outbreak Filters page shows two sections: the Outbreak Filters Overview and a listing of current Outbreak
Filter Rules (if any).
In the figure above, Outbreak Filters are enabled, Adaptive Scanning is enabled, and the maximum message
size is set to 512k. To change these settings, click Edit Global Settings For more information about editing
Global Settings, see Configuring Outbreak Filters Global Settings, on page 436.
The Outbreak Filter Rules section lists the time, date, and version of the latest update for various components
(the rules engine as well as the rules themselves), as well as a listing of the current Outbreak Filter rules with
threat level.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
435
Outbreak Filters
Configuring Outbreak Filters Global Settings
For more information about Outbreak Rules, see Outbreak Filters Rules, on page 438.
Related Topics
• Configuring Outbreak Filters Global Settings, on page 436
• Outbreak Filters Rules, on page 438
• The Outbreak Filters Feature and Mail Policies, on page 439
• The Outbreak Filters Feature and the Outbreak Quarantine, on page 443
Configuring Outbreak Filters Global Settings
Procedure
Step 1 Click Security Services > Outbreak Filters.
Step 2 Click Edit Global Settings.
Step 3 Depending on your requirements, do the following:
• Enable Outbreak Filters globally
• Enable Adaptive Rules scanning
• Set a maximum size for files to scan (note that you are entering the size in bytes )
• Enable alerts for the Outbreak Filter
• Enable Web Interaction Tracking. See Web Interaction Tracking , on page 452.
Step 4 Submit and commit your changes.
What to do next
This functionality is also available via the outbreakconfig CLI command (see the CLI Reference Guide for
AsyncOS for Cisco Secure Email Gateway). After you make your changes, submit and commit them.
Note You cannot enable the logging of URLs using the web interface. For instructions to enable logging of URLs
using CLI, see Enabling Logging of URLs and Message Tracking Details for URLs , on page 437 .
Related Topics
• Enabling the Outbreak Filters Feature, on page 437
• Enabling Adaptive Rules, on page 437
• Enabling Alerts for Outbreak Filters, on page 437
• Enabling Logging of URLs and Message Tracking Details for URLs , on page 437
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
436
Outbreak Filters
Enabling the Outbreak Filters Feature
Enabling the Outbreak Filters Feature
To enable the Outbreak Filters feature globally, check the box next to Enable Outbreak Filters on the Outbreak
Filters Global Settings page, and click Submit. You must have agreed to the Outbreak Filters license agreement
first.
Once enabled globally, the Outbreak Filters feature can then be enabled or disabled individually for each
incoming and outgoing mail policy, including the default policies. For more information, seeThe Outbreak
Filters Feature and Mail Policies, on page 439.
The Outbreak Filters feature uses the Context Adaptive Scanning Engine (CASE) to detect viral threats,
regardless of whether anti-spam scanning is enabled, but you do need to have Anti-Spam or Intelligent
Multi-Scan enabled globally on the email gateway to scan for non-viral threats.
Note If you have not already agreed to the license during system setup (see Step 4: Security, on page 47), you must
click Enable on the Security Services > Outbreak Filters page, and then read and agree to the license.
Enabling Adaptive Rules
Adaptive Scanning enables the use of Adaptive Rules in Outbreak Filters. A set of factors or traits (file size,
etc.) are used to determine the likelihood of a message being part of an outbreak when no virus signature or
spam criteria relating to the message’s content is available. To enable Adaptive Scanning, check the box next
to Enable Adaptive Rules on the Outbreak Filters Global Settings page, and click Submit.
Enabling Alerts for Outbreak Filters
Check the box labeled “Emailed Alerts” to enable alerting for the Outbreak Filters feature. Enabling emailed
alerts for Outbreak Filters merely enables the alerting engine to send alerts regarding Outbreak Filters.
Specifying which alerts are sent and to which email addresses is configured via the Alerts page in the System
Administration tab. For more information on configuring alerts for Outbreak Filters, see Alerts, SNMP Traps,
and Outbreak Filters, on page 446.
Enabling Logging of URLs and Message Tracking Details for URLs
Logging of URL-related logs, and display of this information in Message Tracking details, is disabled by
default. This includes the logs for the following events:
• Category of any URL in the message matches the URL category filters
• Reputation score of any URL in the message matches URL reputation filters
• Outbreak Filter rewrites any URL in the message
To enable logging of these events, use the outbreakconfig command in the command-line interface (CLI).
Related Topics
• Example: Enabling Logging of URLs Using the outbreakconfig Command , on page 437
• Managing Outbreak Filter Rules, on page 439
• Example: Enabling Logging of URLs Using the outbreakconfig Command , on page 437
Example: Enabling Logging of URLs Using the outbreakconfig Command
The following example shows how to enable logging of URLs using the outbreakconfig command
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
437
Outbreak Filters
Outbreak Filters Rules
mail.example.com> outbreakconfig
Outbreak Filters: Enabled
Choose the operation you want to perform:
- SETUP - Change Outbreak Filters settings.
[]> setup
Outbreak Filters: Enabled
Would you like to use Outbreak Filters? [Y]>
Outbreak Filters enabled.
Outbreak Filter alerts are sent when outbreak rules cross the threshold (go above or back
down below), meaning that new messages of
certain types could be quarantined or will no longer be quarantined, respectively.
Would you like to receive Outbreak Filter alerts? [N]>
What is the largest size message Outbreak Filters should scan?
[524288]>
Do you want to use adaptive rules to compute the threat level of messages? [Y]>
Logging of URLs is currently disabled.
Do you wish to enable logging of URL's? [N]> Y
Logging of URLs has been enabled.
The Outbreak Filters feature is now globally enabled on the system. You must use the
'policyconfig' command in the CLI or the Email
Security Manager in the GUI to enable Outbreak Filters for the desired Incoming and Outgoing
Mail Policies.
Choose the operation you want to perform:
- SETUP - Change Outbreak Filters settings.
[]>
Outbreak Filters Rules
Outbreak Rules are published by the Cisco Security Intelligence Operations and your email gateway checks
for and downloads new outbreak rules every 5 minutes. You can change this update interval. SeeConfiguring
Server Settings for Downloading Upgrades and Updates , on page 1030 for more information.
Related Topics
• Managing Outbreak Filter Rules, on page 439
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
438
Outbreak Filters
Managing Outbreak Filter Rules
Managing Outbreak Filter Rules
Because the Outbreak Filters Rules are automatically downloaded for you, there really is no management
needed on the part of the user.
However, if for some reason your email gateway is not able to reach Cisco’s update servers for new rules
over a period of time, it is possible that your locally-cached scores are no longer valid, i.e., if a known viral
attachment type now has an update in the anti-virus software and/or is no longer a threat. At this time, you
may wish to no longer quarantine messages with these characteristics.
You can manually download updated outbreak rules from Cisco’s update servers by clicking Update Rules
Now.
Note The Update Rules Now button does not “flush” all existing outbreak rules on the email gateway. It only
replaces outbreak rules that have been updated. If there are no updates available on Cisco’s update servers,
then the email gateway will not download any outbreak rules when you click this button.
Related Topics
• Updating Outbreak Filter Rules, on page 439
Updating Outbreak Filter Rules
By default, your email gateway will attempt to download new Outbreak Filters rules every 5 minutes. You
can change this interval via the Security Services > Service Updates page. For more information, see Service
Updates , on page 1026.
The Outbreak Filters Feature and Mail Policies
The Outbreak Filters feature has settings that can be set per mail policy. The Outbreak Filters feature can be
enabled or disabled for each mail policy on the email gateway. Specific file extensions and domains can be
exempted from processing by the Outbreak Filters feature, per mail policy. This functionality is also available
via the policyconfig CLI command (see the CLI Reference Guide for AsyncOS for Cisco Secure Email
Gateway).
Note Anti-Spam or Intelligent Multi-Scan scanning needs to be enabled globally on an email gateway for the
Outbreak Filters feature to scan for non-viral threats.
To modify the Outbreak Filters feature settings for a specific mail policy, click the link in the Outbreak Filters
column of the policy to change.
To enable and customize the Outbreak Filters feature for a particular mail policy, select Enable Outbreak
Filtering (Customize Settings).
You can configure the following Outbreak Filter settings for a mail policy:
• Quarantine threat level
• Maximum quarantine retention time
• Deliver non-viral threat messages immediately without adding them to quarantine
• File extension types for bypassing
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
439
Outbreak Filters
Setting a Quarantine Level Threshold
• Message modification threshold
• Alter subject header using custom text and Outbreak Filter variables such as $threat_verdict ,
$threat_category , $threat_type , $threat_description , and $threat_level .
• Include the following email headers:
• X-IronPort-Outbreak-Status
• X-IronPort-Outbreak-Description
• Send the message to an alternate destination such as an email gateway or an exchange server.
• URL rewriting
• Threat disclaimer
Select Enable Outbreak Filtering (Inherit Default mail policy settings) to use the Outbreak Filters settings
that are defined for the default mail policy. If the default mail policy has the Outbreak Filters feature enabled,
all other mail policies use the same Outbreak Filter settings unless they are customized.
Once you have made your changes, commit your changes.
Related Topics
• Setting a Quarantine Level Threshold, on page 440
• Maximum Quarantine Retention, on page 440
• Bypassing File Extension Types, on page 440
• Message Modification, on page 441
Setting a Quarantine Level Threshold
Select a Quarantine Threat Level threshold for outbreak threats from the list. A smaller number means that
you will be quarantining more messages, while a larger number results in fewer messages quarantined. Cisco
recommends the default value of 3.
For more information, see Guidelines for Setting Your Quarantine Threat Level Threshold, on page 431.
Maximum Quarantine Retention
Specify the maximum amount of time that messages stay in the Outbreak Quarantine. You can specify different
retention times for messages that may contain viral attachments and messages that may contain other threats,
like phishing or malware links. For non-viral threats, check the Deliver messages without adding them to
quarantine check box to deliver the messages immediately without adding them to quarantine.
Note You cannot quarantine non-viral threats unless you enable Message Modification for the policy.
CASE recommends a quarantine retention period when assigning the threat level to the message. The email
gateway keeps the message quarantined for the length of time that CASE recommends unless it exceeds the
maximum quarantine retention time for its threat type.
Bypassing File Extension Types
You can modify a policy to bypass specific file types. Bypassed file extensions are not included when CASE
calculates the threat level for the message; however, the attachments are still processed by the rest of the email
security pipeline.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
440
Outbreak Filters
Bypassing File Extensions: Container File Types
To bypass a file extension, click Bypass Attachment Scanning, select or type in a file extension, and click
Add Extension. AsyncOS displays the extension type in the File Extensions to Bypass list.
To remove an extension from the list of bypassed extensions, click the trash can icon next to the extension in
the File Extensions to Bypass list.
Related Topics
• Bypassing File Extensions: Container File Types, on page 441
Bypassing File Extensions: Container File Types
When bypassing file extensions, files within container files (a .doc file within a .zip, for example) are bypassed
if the extension is in the list of extensions to bypass. For example, if you add .doc to the list of extensions to
bypass, all .doc files, even those within container files are bypassed.
Message Modification
Enable Message Modification if you want the email gateway to scan messages for non-viral threats, such as
phishing attempts or links to malware websites.
Based on the message’s threat level, AsyncOS can modify the message to rewrite all of the URLs to redirect
the recipient through the Cisco web security proxy if they attempt to open the website from the message. The
email gateway can also add a disclaimer to the message to alert the user that the message’s content is suspicious
or malicious.
You need to enable message modification in order to quarantine non-viral threat messages.
Related Topics
• Message Modification Threat Level, on page 441
• Message Subject, on page 441
• Outbreak Filters Email Headers, on page 442
• Alternate Destination Mail Host, on page 442
• URL Rewriting and Bypassing Domains, on page 442
• Threat Disclaimer, on page 443
Message Modification Threat Level
Select a Message Modification Threat Level threshold from the list. This setting determines whether to modify
a message based on the threat level returned by CASE. A smaller number means that you will be modifying
more messages, while a larger number results in fewer messages being modified. Cisco recommends the
default value of 3.
Message Subject
You can alter the text of the subject header on non-viral threat messages containing modified links to notify
users that the message has been modified for their protection. Prepend or append the subject header with
custom text, Outbreak Filter variables such as $threat_verdict , $threat_category , $threat_type ,
$threat_description , and $threat_level , or a combination of both. To insert variables, click Insert
Variables, and select from the list of variables.
White space is not ignored in the Message Subject field. Add spaces after (if prepending) or before (if
appending) the text you enter in this field to separate your added text from the original subject of the message.
For example, add the text [MODIFIED FOR PROTECTION] with a few trailing spaces if you are prepending.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
441
Outbreak Filters
Outbreak Filters Email Headers
Note The Message Subject field only accepts US-ASCII characters.
Outbreak Filters Email Headers
You can add the following additional headers to the message:
Header Format Example Options
X-IronPort- X-IronPort-Outbreak-Status: X-IronPort-Outbreak- • Enable for all messages
Outbreak- $threat_verdict, level Status: Yes, level • Enable only for non-viral outbreak
Status $threat_level, 4, Phish - Password • Disable
$threat_category -
$threat_type
X-IronPort- X-IronPort-Outbreak- X-IronPort-Outbreak- • Enable
Outbreak- Description: Description: It may • Disable
Description $threat_description trick victims into
submitting their
username and
password on a fake
website.
Note If you want to filter messages based on these headers, you must send the Outbreak Filter processed messages
back to an email gateway (by configuring an alternate destination mail host), and scan them using a content
filter that matches these headers.
Alternate Destination Mail Host
If you want to perform a content filter-based scan on the Outbreak Filter processed messages, you must
configure the Outbreak Filter to send the processed messages back to an email gateway. This is because, in
the processing pipeline, the Outbreak Filter scan is performed after the content filter scan.
In the Alternate Destination Mail Host field, enter the IP address (IPv4 or IPv6) or the FQDN of the email
gateway where you want to send the processed messages for further scans.
URL Rewriting and Bypassing Domains
If the message’s threat level exceeds the message modification threshold, the Outbreak Filters feature rewrites
all URLs in the message to redirect the user to the Cisco web security proxy’s splash page if they click on
any of them. (See Redirecting URLs, on page 429 for more information.) If the message’s threat level exceeds
the quarantine threshold, the appliance also quarantines the message. If a small scale, non-viral outbreak is
in progress, quarantining the message gives TOC time to analyze any suspect websites linked from possible
outbreak messages and determine whether the websites are malicious. CASE uses updated Outbreak Rules
from SIO to rescan the message to determine if it is part of the outbreak. After the retention period expires,
the email gateway releases the message from the quarantine.
AsyncOS rewrites all of the URLs inside a message except for the ones pointing to bypassed domains.
The following options are available for URL rewriting:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
442
Outbreak Filters
Threat Disclaimer
• Enable only for unsigned messages. This option allows AsyncOS to rewrite URLs in unsigned messages
that meet or exceed the message modification threshold, but not signed messages. Cisco recommends
using this setting for URL rewriting.
Note The email gateway may rewrite URLs in a DomainKeys/DKIM-signed message
and invalidate the message’s signature if a server or appliance on your network
other than the email gateway is responsible for verifying the DomainKeys/DKIM
signature.
The email gateway considers a message signed if it is encrypted using S/MIME
or it contains an S/MIME signature.
• Enable for all messages. This option allows AsyncOS to rewrite URLs in all messages that meet or
exceed the message modification threshold, including signed ones. If AsyncOS modifies a signed message,
the signature becomes invalid.
• Disable. This option disables URL rewriting for Outbreak Filters.
You can modify a policy to exclude URLs to certain domains from modification. To bypass domains, enter
the IPv4 address, IPv6 address, CIDR range, hostname, partial hostname or domain in the Bypass Domain
Scanning field. Separate multiple entries using commas.
The Bypass Domain Scanning feature is similar to, but independent of, the global allowed list used by URL
filtering. For more information about that allowed list, see Creating Allowed Lists for URL Filtering , on page
453.
Threat Disclaimer
The email gateway can append a disclaimer message above the heading of a suspicious message to warn the
user of its content. This disclaimer can be in HTML or plain text, depending on the type of message.
Select the disclaimer text you want to use from the Threat Disclaimer list or click the Mail Policies > Text
Resources link to create a new disclaimer using the Disclaimer Template. The Disclaimer Template includes
variables for outbreak threat information. You can see a preview of the threat disclaimer by clicking Preview
Disclaimer. For custom disclaimer messages, you can use variables to display the threat level, the type of
threat, and a description of the threat in the message. For information on creating a disclaimer message, see
Overview of Text Resource Management, on page 652.
The Outbreak Filters Feature and the Outbreak Quarantine
Messages quarantined by the Outbreak Filters feature are sent to the Outbreak quarantine. This quarantine
functions like any other quarantine (for more information about working with quarantines, see Policy, Virus,
and Outbreak Quarantines, on page 927) except that it has a “summary” view, useful for deleting or releasing
all messages from the quarantine, based on the rule used to place the message in the quarantine (for Outbreak
Rules, the Outbreak ID is shown, and for Adaptive Rules, a generic term is shown). For more information
about the summary view, see Outbreak Quarantine and the Manage by Rule Summary View, on page 444.
Related Topics
• Monitoring the Outbreak Quarantine, on page 444
• Outbreak Quarantine and the Manage by Rule Summary View, on page 444
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
443
Outbreak Filters
Monitoring the Outbreak Quarantine
Monitoring the Outbreak Quarantine
Though a properly configured quarantine requires little if any monitoring, it is a good idea to keep an eye on
the Outbreak Quarantine, especially during and after virus outbreaks when legitimate messages may be delayed.
If a legitimate message is quarantined, one of the following occurs depending on the settings for the Outbreak
quarantine:
• If the quarantine’s Default Action is set to Release, the message will be released when the retention time
period expires or when the quarantine overflows. You can configure the Outbreak quarantine so that the
following actions are performed on messages before they are released due to overflow: strip attachments,
modify the subject, and add an X-Header. For more information about these actions, see Default Actions
for Automatically Processed Quarantined Messages , on page 931.
• If the quarantine’s Default Action is set to Delete, the message will be deleted when the retention time
period expires, or when the quarantine overflows.
• Overflow occurs when the quarantine is full and more messages are added. In this case the messages
closest to their expiration date (not necessarily the oldest messages) are released first, until enough room
is available for the new messages. You can configure the Outbreak quarantine so that the following
actions are performed on messages before they are released due to overflow: strip attachments, modify
the subject, add an X-Header.
Because quarantined messages are rescanned whenever new rules are published, it is very likely that messages
in the Outbreak quarantine will be released prior to the expiration time.
Still, it can be important to monitor the Outbreak quarantine if the Default Action is set to Delete. Cisco
recommends most users to not set the default action to Delete. For more information about releasing messages
from the Outbreak quarantine, or changing the Default Action for the Outbreak Quarantine, see Default Actions
for Automatically Processed Quarantined Messages , on page 931.
Conversely, if you have messages in your Outbreak quarantine that you would like to keep in the quarantine
longer while you wait for a new rule update, for example, you can delay the expiration of those messages.
Keep in mind that increasing the retention time for messages can cause the size of the quarantine to grow.
Note If anti-virus scanning is disabled globally (not via a mail policy) while a message is in the Outbreak quarantine,
the message is not anti-virus scanned when it leaves the quarantine, even if anti-virus scanning is re-enabled
prior to the message leaving the quarantine.
Note You can use the Outbreak Filters feature without having enabled anti-virus scanning on the email gateway.
However, Outbreak Filters cannot scan for non-viral threats if anti-spam scanning is not enabled on the
appliance.
Outbreak Quarantine and the Manage by Rule Summary View
You can view the contents of the Outbreak quarantine by clicking on the name of the quarantine in the listing
on the Monitor menu in the GUI. The Outbreak quarantine has an additional view as well, the Outbreak
Quarantine Manage by Rule Summary link.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
444
Outbreak Filters
Using the Summary View to Perform Message Actions on Messages in the Outbreak Quarantine Based on Rule ID.
Figure 31: The Outbreak Quarantine Manage by Rule Summary Link
Related Topics
• Using the Summary View to Perform Message Actions on Messages in the Outbreak Quarantine Based
on Rule ID., on page 445
Using the Summary View to Perform Message Actions on Messages in the Outbreak Quarantine Based on Rule ID.
Click on the Manage by Rule Summary link to see a listing of the contents of the Outbreak quarantine, grouped
by rule ID:
Figure 32: The Outbreak Quarantine Manage by Rule Summary View
From this view, you can choose to release, delete, or delay the exit for all messages pertaining to a specific
outbreak or adaptive rule, rather than selecting individual messages. You can also search through or sort the
listing.
This functionality is also available via the quarantineconfig -> outbreakmanage CLI command. For more
information, see the CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway.
Monitoring Outbreak Filters
The email gateway includes several tools to monitor the performance and activity of the Outbreak Filters
feature.
Related Topics
• Outbreak Filters Report, on page 446
• Outbreak Filters Overview and Rules Listing, on page 446
• Outbreak Quarantine, on page 446
• Alerts, SNMP Traps, and Outbreak Filters, on page 446
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
445
Outbreak Filters
Outbreak Filters Report
Outbreak Filters Report
The Outbreak Filters report to view the current status and configuration of Outbreak Filters on your email
gateway as well as information about recent outbreaks and messages quarantined due to Outbreak Filters.
View this information on the Monitor > Outbreak Filters page. For more information, see the “Email Security
Monitor” chapter.
Outbreak Filters Overview and Rules Listing
The overview and rules listing provide useful information about the current status of the Outbreak Filters
feature. View this information via the Security Services > Outbreak Filters page.
Outbreak Quarantine
Use the outbreak quarantine to monitor how many messages are being flagged by your Outbreak Filters threat
level threshold. Also available is a listing of quarantined messages by rule. For information, see Outbreak
Quarantine and the Manage by Rule Summary View, on page 444 and Policy, Virus, and Outbreak Quarantines,
on page 927
Alerts, SNMP Traps, and Outbreak Filters
The Outbreak Filters feature supports two different types of notifications: regular AsyncOS alerts and SNMP
traps.
SNMP traps are generated when a rule update fails. For more information about SNMP traps in AsyncOS,
see the “Managing and Monitoring via the CLI” chapter.
AsyncOS has two types of alerts for the Outbreak Filter feature: size and rule
AsyncOS alerts are generated whenever the Outbreak quarantine’s size goes above 5, 50, 75, and 95 of the
maximum size. The alert generated for the 95% threshold has a severity of CRITICAL, while the remaining
alert thresholds are WARNING. Alerts are generated when the threshold is crossed as the quarantine size
increases. Alerts are not generated when thresholds are crossed as the quarantine size decreases. For more
information about alerts, see Alerts, on page 1043.
AsyncOS also generates alerts when rules are published, the threshold changes, or when a problem occurs
while updating rules or the CASE engine.
Troubleshooting The Outbreak Filters Feature
This section provides some basic troubleshooting tips for the Outbreak Filters feature.
Related Topics
• Reporting Incorrectly Classified Messages to Cisco , on page 447
• Multiple Attachments and Bypassed Filetypes, on page 447
• Message and Content Filters and the Email Pipeline, on page 447
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
446
Outbreak Filters
Reporting Incorrectly Classified Messages to Cisco
Reporting Incorrectly Classified Messages to Cisco
Use the checkbox on the Manage Quarantine page for the Outbreak quarantine to notify Cisco of
misclassifications.
Multiple Attachments and Bypassed Filetypes
Bypassed file types are only excluded if a message’s only attachment is of that type, or in the case of multiple
attachments, if the other attachments do not yet have existing rules. Otherwise the message is scanned.
Message and Content Filters and the Email Pipeline
Message and content filters are applied to messages prior to scanning by Outbreak Filters. Filters can cause
messages to skip or bypass the Outbreak Filters scanning.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
447
Outbreak Filters
Message and Content Filters and the Email Pipeline
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
448
CHAPTER 20
Protecting Against Malicious or Undesirable
URLs
This chapter contains the following sections:
• URL-Related Protections and Controls , on page 449
• Setting Up URL Filtering, on page 450
• Taking Action Based on the Reputation or Category of URLs in Messages , on page 456
• Handling Unscannable Messages for URL Filtering, on page 460
• Detecting Malicious URLs in Messages Using Content Filter, on page 460
• Detecting Malicious URLs in Messages Using Message Filter, on page 462
• Monitoring URL Filtering Results , on page 463
• Displaying URL Details in Message Tracking , on page 463
• Troubleshooting URL Filtering, on page 463
• About URL Categories, on page 467
URL-Related Protections and Controls
Control and protection against malicious or undesirable links is incorporated into the anti-spam, outbreak,
content, and message filtering processes in the work queue. These controls:
• Increase the effectiveness of protection from malicious URLs in messages and attachments.
URL filtering is incorporated into Outbreak Filtering. This strengthened protection is useful even if your
organization already has a Cisco Web Security Appliance or similar protection from web-based threats,
because it blocks threats at the point of entry.
You can also use content or message filters to take action based on the Web Based Reputation Score
(WBRS) of URLs in messages.
Note As a best practice, Cisco recommends rewriting URLs with a questionable, neutral,
and favorable or unknown reputation to redirect them to the Cisco Web Security
Proxy for click-time evaluation of their safety.
• Better identify spam
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
449
Protecting Against Malicious or Undesirable URLs
Which URLs Are Evaluated
The email gateway uses the reputation and category of links in messages, in conjunction with other
spam-identification algorithms, to help identify spam. For example, if a link in a message belongs to a
marketing web site, the message is more likely to be a marketing message.
• Support enforcement of corporate acceptable use policies
The category of URLs (for example, Adult Content or Illegal Activities) can be used in conjunction with
content and message filters to enforce corporate acceptable use policies.
• Allow you to identify users in your organization who most frequently clicked a URL in a message that
has been rewritten for protection, as well as links that have most frequently been clicked.
Related Topics
• Which URLs Are Evaluated , on page 450
• Web Interaction Tracking Page, on page 856
Which URLs Are Evaluated
URLs in incoming and outgoing messages (including attachments) are evaluated. Any valid string for a URL
is evaluated, including strings with the following:
• http, https, or www
• domain or IP address
• port number preceded by a colon (:)
• uppercase or lowercase letters
When evaluating URLs to determine whether a message is spam, if necessary for load management, the system
prioritizes screening of incoming messages over outgoing messages.
Setting Up URL Filtering
• Requirements for URL Filtering , on page 450
• Enable URL Filtering, on page 451
• About the Connection to Talos Intelligence Services , on page 452
• Web Interaction Tracking , on page 452
• URL Filtering in Cluster Configurations, on page 453
• Creating Allowed Lists for URL Filtering , on page 453
• Customizing the Notification That End Users See If a Site Is Malicious , on page 455
Requirements for URL Filtering
In addition to enabling URL filtering, you must enable other features depending on desired functionality.
For enhanced protection against spam:
• Anti-spam scanning must be enabled globally and per applicable mail policy. This can be either the
IronPort Anti-Spam or the Intelligent Multi-Scan feature. See the anti-spam chapter.
For enhanced protection against malware:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
450
Protecting Against Malicious or Undesirable URLs
Enable URL Filtering
• The Outbreak Filters feature must be enabled globally and per applicable mail policy. See the Outbreak
Filters chapter.
To take action based on URL reputation, or to enforce acceptable use policies using message and content
filters:
• The Outbreak Filters feature must be enabled globally. See the Outbreak Filters chapter.
Enable URL Filtering
You can enable URL filtering using the Security Services > URL Filtering page in the web interface or the
websecurityconfig command in CLI.
Before You Begin
• Ensure that the requirements for the individual URL filtering features that you want to use have been
met. See Requirements for URL Filtering , on page 450.
• (Optional) Create a list of URLs that you want all URL filtering functionalities to ignore. See Creating
Allowed Lists for URL Filtering , on page 453.
Procedure
Step 1 Select Security Services > URL Filtering.
Step 2 Click Enable.
Step 3 Select the Enable URL Category and Reputation Filters check box.
Step 4 (Optional) If you have created a list of URLs to exempt from URL filtering when evaluating messages for
spam and malware, and from all content and message filtering, select that list.
This setting does not cause the message to bypass anti-spam or Outbreak Filters processing generally.
Step 5 (Optional) Enable Web Interaction Tracking. See Web Interaction Tracking , on page 452.
Step 6 Submit and commit your changes.
If you have met the applicable prerequisites, and you have already configured Outbreak Filters and Anti-Spam
protection, then you do not need to make additional configurations to benefit from enhanced automatic detection
of spam and malicious URLs.
What to do next
• To take action based on the reputation of URLs in messages, see Taking Action Based on the Reputation
or Category of URLs in Messages , on page 456.
• To use URL categories in content and message filters, for example to enforce acceptable use policies,
see Taking Action Based on the Reputation or Category of URLs in Messages , on page 456.
• To redirect all URLs in suspected spam messages to the Cisco Web Security proxy service, see Using
Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy: Configuration
Example , on page 403.
• (Optional) To customize the appearance of end user notification page, see Customizing the Notification
That End Users See If a Site Is Malicious , on page 455.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
451
Protecting Against Malicious or Undesirable URLs
About the Connection to Talos Intelligence Services
• Ensure that you receive alerts about issues related to this feature. See Future URL Category Set Changes
, on page 480, the release notes for your AsyncOS release, and Adding Alert Recipients, on page 1045.
About the Connection to Talos Intelligence Services
URL reputation and category are provided by cloud-based Talos Intelligence Services.
The email gateway connects to the Talos Intelligence Services either directly or through a web proxy, using
the port specified for URL filtering services in Firewall Information, on page 1325 Communication is over
HTTPS with mutual certificate authentication. Certificates are updated automatically (see Service Updates ,
on page 1026.) For additional information about required certificates, see the Release Notes available from the
location specified in Certificates for URL Filtering Features , on page 452.
If an HTTP or HTTPS proxy has been configured on the Security Services > Service Updates page, the
email gateway will use it when communicating with Talos Intelligence Services. For more information about
using a proxy server, see Configuring Server Settings for Downloading Upgrades and Updates , on page 1030.
Note Certificates are not saved with a configuration file.
Related Topics
• Certificates for URL Filtering Features , on page 452
• Alert: Beaker Connector: Error Fetching Enrollment Certificate , on page 464
• Alert: Beaker Connector: Certificate Is Invalid , on page 464
Certificates for URL Filtering Features
AsyncOS is designed to automatically deploy and update the certificates needed for communications with
cloud services used for URL filtering features. However, if for any reason the system is unable to update these
certificates, you will receive an alert that requires action from you.
Ensure that the email gateway is configured to send you these alerts (System type, Warning severity). For
instructions, see Alerts, on page 1043.
If you receive an alert about an invalid certificate, contact Cisco TAC, which can provide the required
replacement certificate. For instructions to use the replacement certificate, see Manually Configuring a
Certificate for Communication with Talos Intelligence Services , on page 467.
Web Interaction Tracking
The web interaction tracking feature provides information about the end users who clicked on rewritten URLs
and the action (allowed, blocked, or unknown) associated with each user click. Once you enable this feature,
you can use the Web Interaction Tracking report to view information such as top malicious URLs clicked,
top users who clicked on malicious URLs, and so on. For more information about the Web Interaction Tracking
report, see Web Interaction Tracking Page, on page 856.
Web Interaction Tracking data is provided by a cloud-based Cisco Aggregator Server.
Related Topics
• Configuring Web Interaction Tracking, on page 453
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
452
Protecting Against Malicious or Undesirable URLs
Configuring Web Interaction Tracking
• About the Connection to Cisco Aggregator Server, on page 453
Configuring Web Interaction Tracking
Depending on your requirements, you can enable web interaction tracking on one of the global settings pages:
• Outbreak Filters. Track end users who clicked URLs rewritten by Outbreak Filters. See Configuring
Outbreak Filters Global Settings, on page 436.
• URL Filtering. Track end users who clicked URLs rewritten by policies (using content and message
filters). See Enable URL Filtering, on page 451.
About the Connection to Cisco Aggregator Server
The email gateway connects to the Cisco Aggregator Server every 30 minutes (non-configurable), either
directly or through a web proxy, using the port specified for URL filtering services in Firewall Information,
on page 1325 Communication is over HTTPS with mutual certificate authentication. Certificates are updated
automatically (see Service Updates , on page 1026.)
If an HTTP or HTTPS proxy has been configured on the Security Services > Service Updates page, the
email gateway will use it when communicating with the Cisco Aggregator Server. For more information about
using a proxy server, see Configuring Server Settings for Downloading Upgrades and Updates , on page 1030.
Note Certificates are not saved with a configuration file.
URL Filtering in Cluster Configurations
• You can enable URL filtering at the machine, group or cluster level.
• If URL filtering is enabled at machine level, URL allowed lists and web interaction tracking can be
configured at machine, group or cluster level.
• If URL filtering is enabled at group level, URL allowed lists and web interaction tracking must be
configured at group or cluster level.
• If URL filtering is enabled at cluster level, URL allowed lists and web interaction tracking must be
configured at cluster level.
• The standard rules for clusters for Message Filters and Content Filters apply.
Creating Allowed Lists for URL Filtering
If you specify a global allowed list when configuring the URL Filtering feature, then URLs on the allowed
list are not evaluated for reputation or category, for anti-spam, Outbreak Filtering, or content and message
filtering. However, the messages that contain these URLs are evaluated as usual by anti-spam scanning and
Outbreak Filters. You can also specify a URL allowed list in each URL Filtering condition (rule) and action
in content and message filters, to supplement the global URL allowed list.
To categorize allowed list URLs from Outbreak Filtering generally, use the Bypass Domain Scanning option
that you configure on the Mail Policies: Outbreak Filters page. URL allowed lists for URL filtering are similar
to, but independent of, Bypass Domain Scanning. For more information about that feature, see URL Rewriting
and Bypassing Domains, on page 442.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
453
Protecting Against Malicious or Undesirable URLs
Importing a URL List
There is no relationship between URL filtering allowed lists described in this section and the allowd list used
for sender reputation filtering based on IP Reputation score.
Before You Begin
Consider importing a list of URLs instead of creating one in the web interface. See Importing a URL List ,
on page 454.
Procedure
Step 1 Select Mail Policies > URL Lists.
Step 2 Select Add URL List or click a list to edit.
Be sure all URLs that you want to designate globally as an allowed list are in a single list. You can select only
one global allowed list for URL filtering.
Step 3 Create and submit the URL list.
To view a list of supported URL formats, enter a semicolon (;) into the URLs box and click Submit. Then
click the more... link that appears.
Each URL, domain, or IP address can be on a separate line, or separate each with a comma.
Step 4 Commit your changes.
What to do next
• To designate a URL list as the global allowed list, see Enable URL Filtering, on page 451.
• To designate a URL list as the allowed list for a specific condition (rule) or action in a content or message
filter, see Taking Action Based on the Reputation or Category of URLs in Messages , on page 456 and
Content Filter Actions, on page 290. For message filters, see also URL Category Actions , on page 224
and URL Category Rule , on page 187.
Related Topics
• Importing a URL List , on page 454
Importing a URL List
You can import a URL list to use as a allowed list for URL filtering.
Procedure
Step 1 Create the text file to import:
• The first line must be the name of the URL list.
• Each URL must be on a separate line.
Step 2 Upload the file to the /configuration directory on the appliance.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
454
Protecting Against Malicious or Undesirable URLs
Customizing the Notification That End Users See If a Site Is Malicious
Step 3 Use the urllistconfig > new command in the command-line interface.
Customizing the Notification That End Users See If a Site Is Malicious
If an end user clicks a malicious URL identified by Outbreak Filtering or a Policy (using Content or Message
Filters), the Cisco Web Security proxy displays a notification in the end user’s web browser. This notification
states that the site is malicious and access to it has been blocked.
When an end user clicks on a URL rewritten using Outbreak Filtering, the notification page is displayed for
10 seconds and then is redirected to the Cisco Web Security proxy for click-time evaluation.
You can customize the appearance of this notification page and display your organization’s branding such as
company logo, contact information, and so on.
Note If you do not customize the notification page, end users see a Cisco branded notification page.
Before You Begin
• Enable URL filtering. See Enable URL Filtering, on page 451.
Procedure
Step 1 Select Security Services > Block Page Customization.
Step 2 Click Enable.
Step 3 Check the Enable Block Page customization check box and enter the following details:
• URL of the organization’s logo. It is recommended that the logo image is hosted on a publicly accessible
server.
• Organization’s name
• Organization’s contact information
Step 4 Choose the language of the notification. You can choose any one of the languages supported by the web
interface.
Note The default language of the end user's browser takes precedence over the language you have selected
here. Also, if the default language of the end user's browser is not supported by AsyncOS, then the
notification is displayed in the language you have selected here.
Step 5 (Optional) Preview the notification page by clicking Preview Block Page Customization link.
Step 6 Submit and commit your changes.
Next Steps
Set up URL rewriting in one of the following ways:
• Using Outbreak Filters. See Redirecting URLs, on page 429.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
455
Protecting Against Malicious or Undesirable URLs
Taking Action Based on the Reputation or Category of URLs in Messages
• Using Content or Message Filters. See Taking Action Based on the Reputation or Category of URLs in
Messages , on page 456.
Taking Action Based on the Reputation or Category of URLs in
Messages
You can take action based on the reputation or category of URL links in the message body or message
attachment using message filters and content filters in incoming and outgoing mail policies.
Because Outbreak Filters take many factors into consideration when evaluating messages for malware, and
URL reputation alone may not trigger aggressive message handling, you may want to create filters based on
URL reputation.
For example, you can use URL Reputation filters to:
• (For URLs in message body only) Rewrite URLs of neutral or unknown reputation to redirect them to
the Cisco cloud Web Security proxy service for click-time evaluation.
• Drop messages that include URLs that have reputation scores in the Untrusted range.
You can use URL Category filters to:
• Filter categories of URLs to enforce organizational policies for acceptable web use, for example to
prevent users from visiting adult or gambling sites while at the office.
• Provide enhanced protection from malicious sites, which may not exist long enough to be classified. (For
URLs in message body only) You can redirect all URLs in the Unclassified category to the Cisco cloud
Web Security proxy service for evaluation at the time a user clicks a link.
Related Topics
• Using URL-Related Conditions (Rules) and Actions , on page 456
• Filtering by URL Reputation or URL Category: Conditions and Rules , on page 457
• Modifying URLs in Messages: Using URL Reputation and URL Category Actions in Filters , on page
458
• Redirected URLs: What Does the End User Experience? , on page 459
Using URL-Related Conditions (Rules) and Actions
To Example Do This
Take action on the message Drop or quarantine messages. Create a URL Reputation or URL Category
as a whole. condition or rule, then pair it with any
action other than a URL Reputation or
URL Category action.
Exception: Do not pair a URL Reputation
condition or rule with a Bounce action.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
456
Protecting Against Malicious or Undesirable URLs
Filtering by URL Reputation or URL Category: Conditions and Rules
To Example Do This
(For URls in message body Replace a URL in the message Create a URL Reputation or URL Category
only) Modify URLs in a with a text note, or make the URL action only; do not use a separate URL
message, or modify their unclickable. filtering condition.
behavior.
As always, you must specify a content filter in a mail policy in order to use it.
Related Topics
• Filtering by URL Reputation or URL Category: Conditions and Rules , on page 457
• Modifying URLs in Messages: Using URL Reputation and URL Category Actions in Filters , on page
458
Filtering by URL Reputation or URL Category: Conditions and Rules
You can perform actions on messages based on the reputation or category of URLs in the message body and
message attachments. If you want to perform any action other than modifying URLs or their behavior, add a
URL Reputation or URL Category condition and select the reputation scores or URL categories for which
you want to apply the action.
For example, if you want to apply the Drop (Final Action) action to all messages that include URLs in the
Adult category, add a condition of type URL Category with the Adult category selected.
If you do not specify a category, the action you choose is applied to all messages.
URL reputation score ranges for trusted, neutral, and untrusted URLs are predefined and not editable. However,
you can specify a custom range instead. The specified endpoints are included in the range you specify. For
example, if you create a custom range from -8 to -10, then -8 and -10 are included in the range. Use "Unknown"
for URLs for which a reputation score cannot be determined.
Note Neutral URL reputation means that URLs are currently clean, but may turn malicious in future, as they are
prone to attacks. For such URLs, administrators can create non-blocking policies, for example, redirecting
them to the Cisco Web Security Proxy for click-time evaluation.
URLs that are included on the selected URL allowed list or on the global URL allowed list not evaluated.
The action that you pair with this condition is taken if any URL in the message matches the reputation score
or any category specified in the condition.
If you want to modify URLs in a message, or modify their behavior, configure only a URL Reputation or
URL Category action. You do not need a separate URL Reputation or URL Category condition or rule for
this purpose.
Note Do not pair a URL Reputation condition with a Bounce action.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
457
Protecting Against Malicious or Undesirable URLs
Modifying URLs in Messages: Using URL Reputation and URL Category Actions in Filters
Tip To check the category of a particular URL, visit the link in Reporting Uncategorized and Misclassified URLs
, on page 480.
Related Topics
• Creating Allowed Lists for URL Filtering , on page 453
• Content Filters, on page 281
Modifying URLs in Messages: Using URL Reputation and URL Category Actions
in Filters
Use a URL Reputation or URL Category action to modify URLs in a message, or their behavior, based on
the reputation or category of the URL.
URL Reputation and URL Category actions do not require a separate condition. Instead, the selected action
is applied based on the reputation or categories that you select in the URL Reputation or URL Category action.
The action is applied only to URLs that meet the criteria specified in the action. Other URLs in the message
are not modified.
If you do not specify a category, the action you choose is applied to all messages.
URL reputation score ranges for trusted, neutral, and untrusted URLs are predefined and not editable. However,
you can specify a custom range instead. The specified endpoints are included in the range you specify. For
example, if you create a custom range from -8 to -10, then -8 and -10 are included in the range. Use “Unknown”
for URLs for which a reputation score cannot be determined.
Note Neutral URL reputation means that URLs are currently clean, but may turn malicious in future, as they are
prone to attacks. For such URLs, administrators can create non-blocking policies, for example, redirecting
them to the Cisco Web Security Proxy for click-time evaluation.
The following URL-related actions are only applicable for URLs in the message body::
• Defang a URL so that it is unclickable. Message recipients can still see and copy the URL.
• Redirect a URL so that if the message recipient clicks the link, the transaction is routed to a Cisco web
security proxy in the cloud, which blocks access if the site is malicious.
Example: You might want to redirect all URLs in the Uncategorized category to the Cisco Cloud Web
Security proxy service, as malicious sites used in phishing attacks often do not exist long enough to be
classified.
See also Redirected URLs: What Does the End User Experience? , on page 459.
To redirect URLs to a different proxy, see the example in the following bullet.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
458
Protecting Against Malicious or Undesirable URLs
Redirected URLs: What Does the End User Experience?
Note The Cisco Cloud Web Security proxy service has no configurable options in this
release. For example, there is no threat score threshold to adjust or action to
specify based on threat score.
• Replace the URL with any text.
To include the original URL in the text that appears in the message, use the $URL variable.
Examples:
• Replace all URLs in the Illegal Downloads category with a note:
Message from your system administrator: A link to an illegal downloads web site has
been removed from this message.
• Include the original URL along with a warning:
WARNING! The following URL may contain malware: $URL
This becomes: WARNING: The following URL may contain malware: http://example.com.
• Redirect to a custom proxy or web security service:
http://custom_proxy/$URL
This becomes: http://custom_proxy/http://example.com
The reputation and category of URLs that are included on the selected URL allowed list or on the global URL
allowed list are not evaluated.
If you defang or replace URLs, you can choose to ignore URLs in signed messages.
Pairing a URL Reputation or URL Category action with a URL Reputation or URL Category condition (or
rule) is not recommended. If you pair a condition (rule) and action that include different categories, then no
match occurs.
Tip To check the category of a particular URL, visit the link in Reporting Uncategorized and Misclassified URLs
, on page 480.
Related Topics
• Creating Allowed Lists for URL Filtering , on page 453
• Using Custom Headers to Redirect URLs in Suspected Spam to the Cisco Web Security Proxy:
Configuration Example , on page 403
• Content Filters, on page 281
• URL Reputation Rules , on page 186
• URL Category Rule , on page 187
Redirected URLs: What Does the End User Experience?
Based on the evaluation by the Cisco Cloud Web Security proxy service:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
459
Protecting Against Malicious or Undesirable URLs
Handling Unscannable Messages for URL Filtering
• If the site is benign, the user is directed to the target web site and has no knowledge that the link has been
redirected.
• If the site is malicious, the user sees a notice that the site is malicious and access to it has been blocked.
You can customize the appearance of end user notification page and display your organization’s branding
such as company logo, contact information, and so on. See Customizing the Notification That End Users
See If a Site Is Malicious , on page 455.
• If communication with the Cisco Cloud Web Security proxy service times out, the user is allowed to
access the target web site.
• If any other error occurs, the user sees a notice.
Related Topics
• Modifying URLs in Messages: Using URL Reputation and URL Category Actions in Filters , on page
458
Handling Unscannable Messages for URL Filtering
In the following scenarios, the URL filtering scanning fails, and the following header -
X-URL-LookUp-ScanningError is added to the message:
• Unable to obtain the URL Reputation and Category
• Unable to expand the shortened URLs in the message
• Number of URLs in the message body or message attachments exceeds the maximum URL scan limit
You can add a content filter, select the X-URL-LookUp-ScanningError header in the Other Header condition,
and configure appropriate actions to take on the message.
Detecting Malicious URLs in Messages Using Content Filter
Use the ‘URL Reputation’ content filter to detect URLs in messages categorized as malicious by the ETF
engine and take appropriate actions on such messages.
You can configure the 'URL Reputation' content filter for ETF in any one of the following ways:
• Use the 'URL Reputation' condition with any appropriate action.
• Use the 'URL Reputation' action with any or no condition.
• Use the 'URL Reputation' condition and action.
The following procedure is used to detect malciicous URLs using the 'URL Reputation' condition and action:
Note • If you only want to use the 'URL Reputation' condition with any appropriate action, do not follow steps
11-20 of the procedure.
• If you only want to use the 'URL Reputation' action with any or no condition., do not follow steps 4-10
of the procedure.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
460
Protecting Against Malicious or Undesirable URLs
Detecting Malicious URLs in Messages Using Content Filter
Before you begin
• Make sure that you enable URL filtering on your email gateway. To enable URL filtering, go to Security
Services > URL Filtering page in the web interface. For more information, see Protecting Against
Malicious or Undesirable URLs, on page 449.
• Make sure that you enable Outbreak Filters on your email gateway. To enable Outbreak Filters, go to
Security Services > Outbreak Filters page in the web interface. For more information, see Outbreak
Filters, on page 425.
• Make sure that you enable Anti-Spam engine on your email gateway. To enable the Anti-Spam engine,
go to Security Services > Anti-Spam page in the web interface. For more information, see Managing
Spam and Graymail, on page 383.
• (Optional) Create a URL list. To create one, go to Mail Polices > URL Lists page in the web interface.
For more information, see Protecting Against Malicious or Undesirable URLs, on page 449.
Procedure
Step 1 Go to Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 Enter a name and description for the content filter.
Step 4 Click Add Condition.
Step 5 Click URL Reputation.
Step 6 Select External Threat Feeds.
Step 7 Select the ETF source(s) to detect malicious URLs.
Step 8 (Optional) Select the list of allow listed URLs that you do not want the email gateway to detect for threats.
Step 9 Select the required Check URLs within option to detect malicious URLs in the message body and subject
and/or message attachments.
Step 10 Click OK.
Step 11 Click Add Action.
Step 12 Click URL Reputation.
Step 13 Select External Threat Feeds.
Step 14 Make sure that you select the same ETF source(s) that you selected in the condition (Step 7).
Step 15 (Optional) Select the same list of allow listed URLs that you selected in Step 8.
Step 16 Select the required Check URLs within option to detect malicious URLs in the 'message body and subject'
and/or 'message attachments'
Step 17 Select the required action that you want to perform on the URLs within the message body and subject and/or
message attachments.
Note In Step 16, if you choose the 'Check URLs within' option as 'Attachments', you can only strip the
attachment from the message.
Step 18 Select whether you want to take actions on all messages or unsigned messages.
Step 19 Click OK.
Step 20 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
461
Protecting Against Malicious or Undesirable URLs
Detecting Malicious URLs in Messages Using Message Filter
Note If you have configured URL Reputation content filters for Web Based Reputation Score (WBRS)
and ETF on your email gateway, it is recommended to set the order of the WBRS URL Reputation
content filter higher than the order of the ETF URL Reputation filter, to improve the performance
of your emal gateway.
Detecting Malicious URLs in Messages Using Message Filter
As an example, use the ‘URL Reputation’ message filter rule syntax to detect malicious URLs in messages
using the ETF engine, and to defang the URL.
Syntax:
defang_url_in_message: if (url-external-threat-feeds (['etf_source1'],
<'URL_allowedlist'>,
<’message_attachments'> , <’message_body_subject’> ,))
{ url-etf-defang(['etf-source1'], "", 0); } <’URL_allowedlist’> ,
<’Preserve_signed’>)}
Where
• ‘url-external-threat-feeds’ is the URL Reputation rule.
• ‘etf_source1’ is the ETF source(s) used to detect malicious URLs in the messages or message
attachments.
• ‘URL_allowedlist’ is the name of a URL allowed list. If a URL allowed list is not present, it is displayed
as “”.
• ‘message_attachments’ is used to check for malicious URLs in the message attachments. A value of
'1' is used to detect malicious URLs in the message attachments.
• ‘message_body_subject’ is used to check for malicious URLs in the message body and subject. A value
of '1' is used to detect malicious URLs in the message body and subject.
Note A value of “1,1” is used to detect malciocus URLs in the message body, subject,
and message attachments.
• ‘url-etf-defang’ is one of the actions that you can take on messages that contain malicious URLs.
The following examples are the ETF-based actions that you can apply on messages that contain malicious
URLs:
• url-etf-strip(['etf_source1'], "None", 1)
• url-etf-defang-strip(['etf_source1'], "None", 1, "Attachment removed")
• url-etf-defang-strip(['etf_source1'], "None", 1)
• url-etf-proxy-redirect(['etf_source1'], "None", 1)
• url-etf-proxy-redirect-strip(['etf_source1'], "None", 1)
• url-etf-proxy-redirect-strip(['etf_source1'], "None", 1, " Attachment removed")
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
462
Protecting Against Malicious or Undesirable URLs
Monitoring URL Filtering Results
• url-etf-replace(['etf_source1'], "", "None", 1)
• url-etf-replace(['etf_source1'], "URL removed", "None", 1)
• url-etf-replace-strip(['etf_source1'], "URL removed ", "None", 1)
• url-etf-replace-strip(['etf_source1'], "URL removed*", "None", 1, "Attachment removed")
• ‘Preserve_signed’ is represented by ‘1’ or ‘0’. ‘1’ indicates that this action applies to unsigned messages
only and ‘0’ indicates that this action applies to all messages.
In the following example, if a URL in the message attachment is detected as malicious by the ETF
engine, the attachment is stripped.
Strip_Malicious_URLs: if (true) {url-etf-strip(['threat_feed_source'], "", 0);}
Monitoring URL Filtering Results
To view data about malicious and neutral URLs detected, select Monitor > URL Filtering. For important
information about the data on this page, see URL Filtering Page , on page 855.
Displaying URL Details in Message Tracking
To display details in Message Tracking for URLs caught by outbreak filters and relevant content filters:
• Message Tracking must be enabled.
• Outbreak filters and/or content filters based on URL reputation or URL Category must be operational.
• For outbreak filters, URL Rewriting must be enabled. See URL Rewriting and Bypassing Domains, on
page 442.
• URL logging must be enabled. See Enabling Logging of URLs and Message Tracking Details for URLs
, on page 437.
For more information about the data displayed, see Message Tracking Details , on page 922.
To manage administrative user access to these potentially sensitive details, see Controlling Access to Sensitive
Information in Message Tracking, on page 981.
Troubleshooting URL Filtering
Related Topics
• Viewing Logs , on page 464
• Alert: Beaker Connector: Error Fetching Enrollment Certificate , on page 464
• Alert: Beaker Connector: Certificate Is Invalid , on page 464
• Unable to Connect to Talos Intelligence Services, on page 465
• Alert: Unable to Connect to the Cisco Aggregator Server, on page 465
• Alert: Unable to Retrieve Web Interaction Tracking Information from the Cisco Aggregator Server, on
page 465
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
463
Protecting Against Malicious or Undesirable URLs
Viewing Logs
• Using the websecurityadvancedconfig Command , on page 466
• Message Tracking Search Does Not Find Messages with Specified Category , on page 466
• Malicious URLs and Marketing Messages Are Not Caught by Anti-Spam or Outbreak Filters , on page
466
• URLs in a Filtered Category Are Not Handled Correctly , on page 466
• End User Reaches Malicious Site via Rewritten URL , on page 467
• Manually Configuring a Certificate for Communication with Talos Intelligence Services , on page 467
Viewing Logs
URL filtering information is posted to the following logs:
• Mail Logs ( mail_logs ). Information related to the result of scanning a URL (action taken of a message
depending on the URL) is posted to this log.
• URL Filtering Logs ( web_client ). Information related to errors, timeouts, network issues, and so on
while attempting the URL lookup are posted this log.
Most information is at Info or Debug level.
Logs do not include information about what happens when a user clicks a redirected link in a message.
"SDS" and in logs refers to URL reputation services. "Beaker Connector" refers to Talos engine.
Alert: Beaker Connector: Error Fetching Enrollment Certificate
Problem
You receive an info-level alert about an error fetching the enrollment client certificate.
Solution
This certificate is required to connect to the following cloud-based services: Talos Intelligence Services (to
obtain URL reputation and category) and Cisco Aggregator Server (to obtain web interaction tracking data).
Try the following:
1. Check for networking issues such as incorrect proxy settings or firewall issues.
2. Verify that your URL Filtering feature key is valid and active.
3. If the problem persists, contact Cisco TAC.
Alert: Beaker Connector: Certificate Is Invalid
Problem
You receive a critical alert about an invalid Beaker connector certificate.
Solution
This certificate is required to connect to Talos Intelligence Services in the cloud in order to obtain URL
reputation and category.
To obtain and manually install a certificate, see Manually Configuring a Certificate for Communication with
Talos Intelligence Services , on page 467.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
464
Protecting Against Malicious or Undesirable URLs
Unable to Connect to Talos Intelligence Services
Unable to Connect to Talos Intelligence Services
Problem
The Security Services > URL Filtering page persistently indicates an issue connecting to Talos Intelligence
Services.
Solution
• If you have enabled URL filtering but have not yet committed the change, commit the change.
• Check for recent alerts related to the connection with Talos Intelligence Services. See Viewing Recent
Alerts, on page 1046. If applicable, see Alert: Beaker Connector: Error Fetching Enrollment Certificate ,
on page 464 and Alert: Beaker Connector: Certificate Is Invalid , on page 464.
• If you are connecting via a proxy specified in Security Services > Service Updates, verify that this is
configured and working properly.
• Check for other network issues that might prevent connection.
• If you see errors in the URL Filtering Logs related to timed out requests to the Talos client, use the
websecuritydiagnostics command and the websecurityadvancedconfig command in the
command-line interface to investigate and make changes:
• If the diagnostics show that Response Time is not less than the configured URL Lookup Timeout,
increase the URL Lookup Timeout value accordingly.
• Check the URL Filtering Logs for non-timeout errors in communications with the URL scanner, Cisco
Web Security Services, or Talos client. "Talos client" in logs represents Talos Intelligence Services. If
you see such log messages, contact TAC.
Alert: Unable to Connect to the Cisco Aggregator Server
Problem
You receive the following warning alert: Unable to Connect to the Cisco Aggregator Server.
Solution
Do the following:
1. Check the connectivity between the email gateway and the Cisco Aggregator Server by pinging the
hostname of the server from the email gateway. Use the aggregatorconfig command in CLI to view the
hostname of the Cisco Aggregator Server.
2. If you are connecting via a proxy specified in Security Services > Service Updates, verify that this is
configured and working properly.
3. Check for other network issues that might prevent connection.
4. Check if the DNS service is running.
5. If the problem persists, contact Cisco TAC.
Alert: Unable to Retrieve Web Interaction Tracking Information from the Cisco
Aggregator Server
Problem
You receive the following warning alert: Unable to retrieve web interaction tracking information from the
Cisco Aggregator Server.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
465
Protecting Against Malicious or Undesirable URLs
Using the websecurityadvancedconfig Command
Solution
Do the following:
1. If you are connecting via a proxy specified in Security Services > Service Updates, verify that this is
configured and working properly.
2. Check for other network issues that might prevent connection.
3. Check if the DNS service is running.
4. If the problem persists, contact Cisco TAC.
Using the websecurityadvancedconfig Command
Except for changes explicitly described in this document, make no other changes using the
websecurityadvancedconfig command without guidance from TAC.
Message Tracking Search Does Not Find Messages with Specified Category
Problem
Messages that contain URLs in a particular category are not found when searching by that category.
Solution
See Expected Messages Are Missing from Search Results , on page 925.
Malicious URLs and Marketing Messages Are Not Caught by Anti-Spam or
Outbreak Filters
Problem
Malicious URLs and messages containing marketing links are not caught by the anti-spam or outbreak filters.
Solution
• This can occur because web site reputation and category are only two among many criteria that anti-spam
and outbreak filters use to determine their verdicts. You can increase the sensitivity of these filters by
lowering the thresholds required to take action such as rewriting or replacing URLs with text, or
quarantining or dropping messages. For details, see The Outbreak Filters Feature and Mail Policies, on
page 439 and Defining Anti-Spam Policies , on page 399. Alternatively, create content or message filters
based on URL reputation score.
• This can also occur if the email gateway is unable to connect to the Talos Intelligence Services. See
Unable to Connect to Talos Intelligence Services, on page 465.
URLs in a Filtered Category Are Not Handled Correctly
Problem
The defined action in a content or message filter based on URL category is not applied.
Solution
• Use the Trace feature (described in the Troubleshooting chapter) to follow the message processing path.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
466
Protecting Against Malicious or Undesirable URLs
End User Reaches Malicious Site via Rewritten URL
• This can occur if the email gateway is unable to connect to the Talos Intelligence Services. See Unable
to Connect to Talos Intelligence Services, on page 465.
• If there are no connection issues, the URLs may not yet be categorized, or may be miscategorized. See
Reporting Uncategorized and Misclassified URLs , on page 480. You can use this site to determine the
category of a URL.
End User Reaches Malicious Site via Rewritten URL
Problem
A malicious URL was redirected to the Cisco Web Security Proxy, but the end user was able to access the
site anyway.
Solution
This can occur if:
• The site was not yet identified as a malicious site.
• The connection to the Cisco Web Security Proxy timed out, which should be a rare occurrence. Ensure
that network issues are not interfering with the connection.
Manually Configuring a Certificate for Communication with Talos Intelligence
Services
Use this procedure if the email gateway is unable to automatically obtain a certificate for communication with
Talos Intelligence Services.
Procedure
Step 1 Obtain the required certificate.
Step 2 Upload the certificate using Network > Certificates, or use the certconfig command in the command-line
interface.
Step 3 In the command-line interface, enter the websecurityconfig command.
Step 4 Follow the prompts to set the client certificate for Talos Intelligence Services Authentication.
About URL Categories
Related Topics
• URL Category Descriptions , on page 468
• Determining the Category of a URL , on page 480
• Reporting Uncategorized and Misclassified URLs , on page 480
• Future URL Category Set Changes , on page 480
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
467
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Descriptions
These URL categories are the same categories that are used on recent releases of AsyncOS for Web Security
appliances.
URL Category Abbrev Code Description Example URLs
ia-tion
Adult adlt 1006 Directed at adults, but not www.adultentertainmentexpo.com
necessarily pornographic. May
www.adultnetline.com
include adult clubs (strip clubs,
swingers clubs, escort services,
strippers); general information
about sex, non-pornographic in
nature; genital piercing; adult
products or greeting cards;
information about sex not in the
context of health or disease.
Advertisements adv 1027 Banner and pop-up www.adforce.com
advertisements that often
www.doubleclick.com
accompany a web page; other
advertising websites that provide
advertisement content.
Advertising services and sales
are classified as “Business and
Industry.”
Alcohol alc 1077 Alcohol as a pleasurable www.samueladams.com
activity; beer and wine making,
www.whisky.com
cocktail recipes; liquor sellers,
wineries, vineyards, breweries,
alcohol distributors. Alcohol
addiction is classified as “Health
and Nutrition.” Bars and
restaurants are classified as
“Dining and Drinking.”
Arts art 1002 Galleries and exhibitions; artists www.moma.org
and art; photography; literature
www.nga.gov
and books; performing arts and
theater; musicals; ballet;
museums; design; architecture.
Cinema and television are
classified as “Entertainment.”
Astrology astr 1074 Astrology; horoscope; fortune www.astro.com
telling; numerology; psychic
www.astrology.com
advice; tarot.
Auctions auct 1088 Online and offline auctions, www.craigslist.com
auction houses, and classified
www.ebay.com
advertisements.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
468
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Business and busi 1019 Marketing, commerce, www.freightcenter.com
Industry corporations, business practices,
www.staples.com
workforce, human resources,
transportation, payroll, security
and venture capital; office
supplies; industrial equipment
(process equipment), machines
and mechanical systems; heating
equipment, cooling equipment;
materials handling equipment;
packaging equipment;
manufacturing: solids handling,
metal fabrication, construction
and building; passenger
transportation; commerce;
industrial design; construction,
building materials; shipping and
freight (freight services,
trucking, freight forwarders,
truckload carriers, freight and
transportation brokers, expedited
services, load and freight
matching, track and trace, rail
shipping, ocean shipping, road
feeder services, moving and
storage).
Chat and Instant chat 1040 Web-based instant messaging www.icq.com
Messaging and chat rooms.
www.meebo.com
Cheating and plag 1051 Promoting cheating and selling www.bestessays.com
Plagiarism written work, such as term
www.superiorpapers.com
papers, for plagiarism.
Child Abuse cprn 1064 Worldwide illegal child sexual —
Content abuse content.
Computer csec 1065 Offering security products and www.computersecurity.com
Security services for corporate and home
www.symantec.com
users.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
469
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Computers and comp 1003 Information about computers www.xml.com
Internet and software, such as hardware,
www.w3.org
software, software support;
information for software
engineers, programming and
networking; website design; the
web and Internet in general;
computer science; computer
graphics and clip art. “Freeware
and Shareware” is a separate
category.
Dating date 1055 Dating, online personals, www.eharmony.com
matrimonial agencies.
www.match.com
Digital Postcards card 1082 Enabling sending of digital www.all-yours.net
postcards and e-cards.
www.delivr.net
Dining and food 1061 Eating and drinking www.hideawaybrewpub.com
Drinking establishments; restaurants, bars,
www.restaurantrow.com
taverns, and pubs; restaurant
guides and reviews.
Dynamic and dyn 1091 IP addresses of broadband links http://109.60.192.55
Residential that usually indicates users
http://dynalink.co.jp
attempting to access their home
network, for example for a http://ipadsl.net
remote session to a home
computer.
Education edu 1001 Education-related, such as www.education.com
schools, colleges, universities,
www.greatschools.org
teaching materials, and teachers’
resources; technical and
vocational training; online
training; education issues and
policies; financial aid; school
funding; standards and testing.
Entertainment ent 1093 Details or discussion of films; www.eonline.com
music and bands; television;
www.ew.com
celebrities and fan websites;
entertainment news; celebrity
gossip; entertainment venues.
Compare with the “Arts”
category.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
470
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Extreme extr 1075 Material of a sexually violent or www.car-accidents.com
criminal nature; violence and
www.crime-scene-photos.com
violent behavior; tasteless, often
gory photographs, such as
autopsy photos; photos of crime
scenes, crime and accident
victims; excessive obscene
material; shock websites.
Fashion fash 1076 Clothing and fashion; hair www.fashion.net
salons; cosmetics; accessories;
www.findabeautysalon.com
jewelry; perfume; pictures and
text relating to body
modification; tattoos and
piercing; modeling agencies.
Dermatological products are
classified as “Health and
Nutrition.”
File Transfer fts 1071 File transfer services with the www.rapidshare.com
Services primary purpose of providing
www.yousendit.com
download services and hosted
file sharing
Filter Avoidance filt 1025 Promoting and aiding www.bypassschoolfilter.com
undetectable and anonymous
www.filterbypass.com
web usage, including cgi, php
and glype anonymous proxy
services.
Finance fnnc 1015 Primarily financial in nature, finance.yahoo.com
such as accounting practices and
www.bankofamerica.com
accountants, taxation, taxes,
banking, insurance, investing,
the national economy, personal
finance involving insurance of
all types, credit cards, retirement
and estate planning, loans,
mortgages. Stock and shares are
classified as “Online Trading.”
Freeware and free 1068 Providing downloads of free and www.freewarehome.com
Shareware shareware software.
www.shareware.com
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
471
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Gambling gamb 1049 Casinos and online gambling; www.888.com
bookmakers and odds; gambling
www.gambling.com
advice; competitive racing in a
gambling context; sports
booking; sports gambling;
services for spread betting on
stocks and shares. Websites
dealing with gambling addiction
are classified as “Health and
Nutrition.” Government-run
lotteries are classified as
“Lotteries”.
Games game 1007 Various card games, board www.games.com
games, word games, and video
www.shockwave.com
games; combat games; sports
games; downloadable games;
game reviews; cheat sheets;
computer games and Internet
games, such as role-playing
games.
Government and gov 1011 Government websites; foreign www.usa.gov
Law relations; news and information
www.law.com
relating to government and
elections; information relating
to the field of law, such as
attorneys, law firms, law
publications, legal reference
material, courts, dockets, and
legal associations; legislation
and court decisions; civil rights
issues; immigration; patents and
copyrights; information relating
to law enforcement and
correctional systems; crime
reporting, law enforcement, and
crime statistics; military, such
as the armed forces, military
bases, military organizations;
anti-terrorism.
Hacking hack 1050 Discussing ways to bypass the www.hackthissite.org
security of websites, software,
www.gohacking.com
and computers.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
472
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Hate Speech hate 1016 Websites promoting hatred, www.kkk.com
intolerance, or discrimination on
www.nazi.org
the basis of social group, color,
religion, sexual orientation,
disability, class, ethnicity,
nationality, age, gender, gender
identity; sites promoting racism;
sexism; racist theology; hate
music; neo-Nazi organizations;
supremacism; Holocaust denial.
Health and hlth 1009 Health care; diseases and www.health.com
Nutrition disabilities; medical care;
www.webmd.com
hospitals; doctors; medicinal
drugs; mental health; psychiatry;
pharmacology; exercise and
fitness; physical disabilities;
vitamins and supplements; sex
in the context of health (disease
and health care); tobacco use,
alcohol use, drug use, and
gambling in the context of
health (disease and health care);
food in general; food and
beverage; cooking and recipes;
food and nutrition, health, and
dieting; cooking, including
recipe and culinary websites;
alternative medicine.
Humor lol 1079 Jokes, sketches, comics and www.humor.com
other humorous content. Adult
www.jokes.com
humor likely to offend is
classified as “Adult.”
Illegal Activities ilac 1022 Promoting crime, such as www.ekran.no
stealing, fraud, illegally
www.thedisease.net
accessing telephone networks;
computer viruses; terrorism,
bombs, and anarchy; websites
depicting murder and suicide as
well as explaining ways to
commit them.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
473
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Illegal ildl 1084 Providing the ability to www.keygenguru.com
Downloads download software or other
www.zcrack.com
materials, serial numbers, key
generators, and tools for
bypassing software protection
in violation of copyright
agreements. Torrents are
classified as “Peer File
Transfer.”
Illegal Drugs drug 1047 Information about recreational www.cocaine.org
drugs, drug paraphernalia, drug
www.hightimes.com
purchase and manufacture.
Infrastructure infr 1018 Content delivery infrastructure www.akamai.net
and Content and dynamically generated
www.webstat.net
Delivery content; websites that cannot be
Networks classified more specifically
because they are secured or
otherwise difficult to classify.
Internet voip 1067 Telephonic services using the www.evaphone.com
Telephony Internet.
www.skype.com
Job Search job 1004 Career advice; resume writing www.careerbuilder.com
and interviewing skills; job
www.monster.com
placement services; job
databanks; permanent and
temporary employment
agencies; employer websites.
Lingerie and ling 1031 Intimate apparel and swim wear, www.swimsuits.com
Swimsuits especially when modeled.
www.victoriassecret.com
Lotteries lotr 1034 Sweepstakes, contests and www.calottery.com
state-sponsored lotteries.
www.flalottery.com
Mobile Phones cell 1070 Short Message Services (SMS); www.cbfsms.com
ring tones and mobile phone
www.zedge.net
downloads. Cellular carrier
websites are included in the
“Business and Industry”
category.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
474
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Nature natr 1013 Natural resources; ecology and www.enature.com
conservation; forests;
www.nature.org
wilderness; plants; flowers;
forest conservation; forest,
wilderness, and forestry
practices; forest management
(reforestation, forest protection,
conservation, harvesting, forest
health, thinning, and prescribed
burning); agricultural practices
(agriculture, gardening,
horticulture, landscaping,
planting, weed control,
irrigation, pruning, and
harvesting); pollution issues (air
quality, hazardous waste,
pollution prevention, recycling,
waste management, water
quality, and the environmental
cleanup industry); animals, pets,
livestock, and zoology; biology;
botany.
News news 1058 News; headlines; newspapers; www.cnn.com
television stations; magazines;
news.bbc.co.uk
weather; ski conditions.
Non-Governmental ngo 1087 Non-governmental organizations www.panda.org
Organizations such as clubs, lobbies,
www.unions.org
communities, non-profit
organizations and labor unions.
Non-Sexual nsn 1060 Nudism and nudity; naturism; www.artenuda.com
Nudity nudist camps; artistic nudes.
www.naturistsociety.com
Online comm 1024 Affinity groups; special interest www.igda.org
Communities groups; web newsgroups;
www.ieee.org
message boards. Excludes
websites classified as
“Professional Networking” or
“Social Networking.”
Online Storage osb 1066 Offsite and peer-to-peer storage www.adrive.com
and Backup for backup, sharing, and hosting.
www.dropbox.com
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
475
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Online Trading trad 1028 Online brokerages; websites that www.tdameritrade.com
enable the user to trade stocks
www.scottrade.com
online; information relating to
the stock market, stocks, bonds,
mutual funds, brokers, stock
analysis and commentary, stock
screens, stock charts, IPOs,
stock splits. Services for spread
betting on stocks and shares are
classified as “Gambling.” Other
financial services are classified
as “Finance."
Organizational pem 1085 Websites used to access business —
Email email (often via Outlook Web
Access).
Parked Domains park 1092 Websites that monetize traffic www.domainzaar.com
from the domain using paid
www.parked.com
listings from an ad network, or
are owned by “squatters” hoping
to sell the domain name for a
profit. These also include fake
search websites which return
paid ad links.
Peer File p2p 1056 Peer-to-peer file request www.bittorrent.com
Transfer websites. This does not track the
www.limewire.com
file transfers themselves.
Personal Sites pers 1081 Websites about and from private www.karymullis.com
individuals; personal homepage
www.stallman.org
servers; websites with personal
contents; personal blogs with no
particular theme.
Photo Searches img 1090 Facilitating the storing and www.flickr.com
and Images searching for, images,
www.photobucket.com
photographs, and clip-art.
Politics pol 1083 Websites of politicians; political www.politics.com
parties; news and information
www.thisnation.com
on politics, elections,
democracy, and voting.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
476
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Pornography porn 1054 Sexually explicit text or www.redtube.com
depictions. Includes explicit
www.youporn.com
anime and cartoons; general
explicit depictions; other fetish
material; explicit chat rooms;
sex simulators; strip poker; adult
movies; lewd art; web-based
explicit email.
Professional pnet 1089 Social networking for the www.linkedin.com
Networking purpose of career or professional
www.europeanpwn.net
development. See also “Social
Networking.”
Real Estate rest 1045 Information that would support www.realtor.com
the search for real estate; office
www.zillow.com
and commercial space; real
estate listings, such as rentals,
apartments, and homes; house
building.
Reference ref 1017 City and state guides; maps, www.wikipedia.org
time; reference sources;
www.yellowpages.com
dictionaries; libraries.
Religion rel 1086 Religious content, information www.religionfacts.com
about religions; religious
www.religioustolerance.org
communities.
SaaS and B2B saas 1080 Web portals for online business www.netsuite.com
services; online meetings.
www.salesforce.com
Safe for Kids kids 1057 Directed at, and specifically kids.discovery.com
approved for, young children.
www.nickjr.com
Science and sci 1012 Science and technology, such as www.physorg.com
Technology aerospace, electronics,
www.science.gov
engineering, mathematics, and
other similar subjects; space
exploration; meteorology;
geography; environment; energy
(fossil, nuclear, renewable);
communications (telephones,
telecommunications).
Search Engines srch 1020 Search engines and other initial www.bing.com
and Portals points of access to information
www.google.com
on the Internet.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
477
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Sex Education sxed 1052 Factual websites dealing with www.avert.org
sex; sexual health;
www.scarleteen.com
contraception; pregnancy.
Shopping shop 1005 Bartering; online purchasing; www.amazon.com
coupons and free offers; general
www.shopping.com
office supplies; online catalogs;
online malls.
Social snet 1069 Social networking. See also www.facebook.com
Networking “Professional Networking.”
www.twitter.com
Social Science socs 1014 Sciences and history related to www.archaeology.org
society; archaeology;
www.anthropology.net
anthropology; cultural studies;
history; linguistics; geography;
philosophy; psychology;
women's studies.
Society and scty 1010 Family and relationships; www.childcare.gov
Culture ethnicity; social organizations;
www.familysearch.org
genealogy; seniors; child-care.
Software swup 1053 Websites that host updates for www.softwarepatch.com
Updates software packages.
www.versiontracker.com
Sports and sprt 1008 All sports, professional and www.espn.com
Recreation amateur; recreational activities;
www.recreation.gov
fishing; fantasy sports; public
parks; amusement parks; water
parks; theme parks; zoos and
aquariums; spas.
Streaming Audio aud 1073 Real-time streaming audio www.live-radio.net
content including Internet radio
www.shoutcast.com
and audio feeds.
Streaming Video vid 1072 Real-time streaming video www.hulu.com
including Internet television,
www.youtube.com
web casts, and video sharing.
Tobacco tob 1078 Pro-tobacco websites; tobacco www.bat.com
manufacturers; pipes and
www.tobacco.org
smoking products (not marketed
for illegal drug use). Tobacco
addiction is classified as “Health
and Nutrition.”
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
478
Protecting Against Malicious or Undesirable URLs
URL Category Descriptions
URL Category Abbrev Code Description Example URLs
ia-tion
Transportation trns 1044 Personal transportation; www.cars.com
information about cars and
www.motorcycles.com
motorcycles; shopping for new
and used cars and motorcycles;
car clubs; boats, airplanes,
recreational vehicles (RVs), and
other similar items. Note, car
and motorcycle racing is
classified as “Sports and
Recreation.”
Travel trvl 1046 Business and personal travel; www.expedia.com
travel information; travel
www.lonelyplanet.com
resources; travel agents;
vacation packages; cruises;
lodging and accommodation;
travel transportation; flight
booking; airfares; car rental;
vacation homes.
Unclassified — — Websites which are not in the —
Cisco database are recorded as
unclassified for reporting
purposes. This may include
mistyped URLs.
Weapons weap 1036 Information relating to the www.coldsteel.com
purchase or use of conventional
www.gunbroker.com
weapons such as gun sellers, gun
auctions, gun classified ads, gun
accessories, gun shows, and gun
training; general information
about guns; other weapons and
graphic hunting sites may be
included. Government military
websites are classified as
“Government and Law.”
Web Hosting whst 1037 Website hosting; bandwidth www.bluehost.com
services.
www.godaddy.com
Web Page tran 1063 Translation of web pages babelfish.yahoo.com
Translation between languages.
translate.google.com
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
479
Protecting Against Malicious or Undesirable URLs
Determining the Category of a URL
URL Category Abbrev Code Description Example URLs
ia-tion
Web-Based mail 1038 Public web-based email mail.yahoo.com
Email services. Websites enabling
www.hotmail.com
individuals to access their
company or organization’s email
service are classified as
“Organizational Email.”
Determining the Category of a URL
To look up the category of a particular URL, visit the site shown in Reporting Uncategorized and Misclassified
URLs , on page 480.
Reporting Uncategorized and Misclassified URLs
To report URLs that have been miscategorized, and URLs that are not categorized but should be, visit:
https://talosintelligence.com/reputation_center/support
To check the status of submitted URLs, click the Status on Submitted URLs tab on this page.
Future URL Category Set Changes
Rarely, the set of URL categories may change as a result of emerging trends and technologies. For example,
a category may be added or removed, renamed, merged with another category, or split into two categories.
These changes can affect the results from existing filters, so if changes occur, the email gateway will send an
alert (System type, Warning severity). If you receive such an alert, you should evaluate and possibly update
content and message filters to work with the updated categories. Existing filters will not automatically be
changed. To ensure that you receive these alerts, see Adding Alert Recipients, on page 1045.
The following changes do not require category set changes and will not generate alerts:
• Routine categorization of newly-categorized sites.
• Recategorization of misclassified sites.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
480
CHAPTER 21
File Reputation Filtering and File Analysis
This chapter contains the following sections:
• Overview of File Reputation Filtering and File Analysis , on page 481
• Configuring File Reputation and Analysis Features, on page 485
• File Reputation and File Analysis Reporting and Tracking , on page 502
• Taking Action When File Threat Verdicts Change , on page 505
• Troubleshooting File Reputation and Analysis , on page 505
Overview of File Reputation Filtering and File Analysis
Advanced Malware Protection protects against zero-day and targeted file-based threats in email attachments
by:
• Obtaining the reputation of known files.
• Analyzing behavior of certain files that are not yet known to the reputation service.
• Continuously evaluating emerging threats as new information becomes available, and notifying you
about files that are determined to be threats after they have entered your network.
This feature is available for incoming messages and outgoing messages.
The file reputation and file analysis services have options for either public- or private-cloud (on-premesis).
• The private-cloud file reputation service is provided by Cisco AMP Virtual Private Cloud appliance,
operating in either “proxy” or “air-gap” (on-premises) mode. See Configuring an On-premises File
Reputation Server, on page 486.
• The private-cloud file analysis service is provided by an on-premises Cisco AMP Threat Grid appliance.
See Configuring an On-Premises File Analysis Server , on page 486.
File Threat Verdict Updates
Threat verdicts can change as new information emerges. A file may initially be evaluated as unknown or
clean, and the file may therefore be released to the recipient. If the threat verdict changes as new information
becomes available, you will be alerted, and the file and its new verdict appear in the AMP Verdict Updates
report. You can investigate the point-of-entry message as a starting point to remediating any impacts of the
threat.
Verdicts can also change from malicious to clean.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
481
File Reputation Filtering and File Analysis
File Processing Overview
When no dynamic content is found in a file after file analysis, the verdict is Low Risk. The file is not sent for
file analysis, and the message continues through the email pipeline.
When the appliance processes subsequent instances of the same file, the updated verdict is immediately
applied.
Information about the timing of verdict updates is included in the file-criteria document referenced in Supported
Files for File Reputation and Analysis Services , on page 483.
Related Topics
• File Reputation and File Analysis Reporting and Tracking , on page 502
• Taking Action When File Threat Verdicts Change , on page 505
File Processing Overview
Evaluation of file reputation and sending of files for analysis occur immediately after anti-virus scanning,
regardless of verdicts from previous scanning engines, unless a final action has been taken on the message.
Note By default, if a message has malformed MIME headers, the file reputation service returns a verdict of
“unscannable.” The appliance will also attempt to extract the attachments from this message. If the appliance
is unable to extract the attachments, verdict will remain as “unscannable.” If the appliance is able to extract
the attachments, the file reputation of the attachments is evaluated. If the attachments are malicious, the verdict
is changed from “unscannable” to “malicious.”
Communications between the appliance and the file reputation service are encrypted and protected from
tampering.
After a file’s reputation is evaluated:
• If a message does not contain any attachments, the file reputation service will return a verdict of “skipped.”
• If the file is known to the file reputation service and is determined to be clean, the message continues
through the workqueue.
• If the file reputation service returns a verdict of malicious, for any attachment in the message, then the
appliance applies the action that you have specified in the applicable mail policy.
• If the file is known to the reputation service but there is insufficient information for a definitive verdict,
the reputation service returns a reputation score based on characteristics of the file such as threat fingerprint
and behavioral analysis. If this score meets or exceeds the configured reputation threshold, the appliance
applies the action that you have configured in the mail policy for files that contain malware .
• If the reputation service has no information about the file, and the file does not meet the criteria for
analysis (see Supported Files for File Reputation and Analysis Services , on page 483), the file is considered
clean and the message continues through the workqueue.
• If you have enabled the File Analysis service, and the reputation service has no information about the
file, and the file meets the criteria for files that can be analyzed (see Supported Files for File Reputation
and Analysis Services , on page 483), then the message can be quarantined (see Quarantining Messages
with Attachments Sent for Analysis, on page 497) and the file sent for analysis. If you have not configured
the appliance to quarantine messages when attachments are sent for analysis, or the file is not sent for
analysis, then the message is released to the user.
• For deployments with on-premises file analysis, the reputation evaluation and file analysis occur
simultaneously. If the reputation service returns a verdict, that verdict is used, as the reputation service
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
482
File Reputation Filtering and File Analysis
Supported Files for File Reputation and Analysis Services
includes inputs from a wider range of sources. If the file is unknown to the reputation service, the file
the file analysis verdict is used.
• If the file reputation verdict information is unavailable because the connection with the server timed out,
the file is considered as Unscannable and the actions configured are applied.
Figure 33: Advanced Malware Protection Workflow for Public-Cloud File Analysis Deployments
If the file is sent for analysis:
• If the file is sent to the cloud for analysis: Files are sent over HTTPS.
• Analysis normally takes minutes, but may take longer.
• A file that is flagged as malicious after File Analysis may not be identified as malicious by the reputation
service. File reputation is determined by a variety of factors over time, not necessarily by a single file
analysis verdict.
• Results for files analyzed using an on premises Cisco AMP Threat Grid appliance are cached locally.
For information about verdict updates, see File Threat Verdict Updates , on page 481.
Supported Files for File Reputation and Analysis Services
The reputation service evaluates most file types. File type identification is determined by file content and is
not dependent on the filename extension.
Some files with unknown reputation can be analyzed for threat characteristics. When you configure the file
analysis feature, you choose which file types are analyzed. New types can be added dynamically; you will
receive an alert when the list of uploadable file types changes, and can select added file types to upload.
Details about what files are supported by the reputation and analysis services are available only to registered
Cisco customers. For information about which files are evaluated and analyzed, see File Criteria for Advanced
Malware Protection Services for Cisco Content Security Products, available from https://www.cisco.com/c/
en/us/support/security/email-security-appliance/products-user-guide-list.html. The criteria for evaluating a
file’s reputation and for sending files for analysis may change at any time.
In order to access this document, you must have a Cisco customer account with a support contract. To register,
visit https://tools.cisco.com/RPF/register/register.do.
You should configure policies to block delivery of files that are not addressed by Advanced Malware Protection.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
483
File Reputation Filtering and File Analysis
Archive or Compressed File Processing
Note A file (either in incoming mail or outgoing mail) that has already been uploaded for analysis from any source
will not be uploaded again. To view analysis results for such a file, search for the SHA-256 from the File
Analysis reporting page.
Related Topics
• Enabling and Configuring File Reputation and Analysis Services , on page 487
• Ensuring That You Receive Alerts About Advanced Malware Protection Issues, on page 501
• Archive or Compressed File Processing, on page 484
Archive or Compressed File Processing
If the file is compressed or archived,
• Reputation of the compressed or archive file is evaluated.
For information about which archived and compressed files are examined, including file formats, see the
information linked from Supported Files for File Reputation and Analysis Services , on page 483.
In this scenario,
• If one of the extracted files is malicious, the file reputation service returns a verdict of Malicious for the
compressed or the archive file.
• If the compressed or archive file is malicious and all the extracted files are clean, the file reputation
service returns a verdict of Malicious for the compressed or the archive file.
• If the verdict of any of the extracted files is unknown, the extracted files are optionally (if configured
and the file type is supported for file analysis) sent for file analysis.
• If the verdict of any of the extracted files or attachments is low risk, the file is not sent for file analysis.
• If the extraction of a file fails while decompressing a compressed or an archive file, the file reputation
service returns a verdict of Unscannable for the compressed or the archive file. Keep in mind that, in this
scenario, if one of the extracted files is malicious, the file reputation service returns a verdict of Malicious
for the compressed or the archive file (Malicious verdict takes precedence over Unscannable verdict).
• An archive or compressed file is treated as unscannable in the following scenarios:
• The data compression ratio is more than 20.
• The archive file contains more than five levels of nesting.
• The archive file contains more than 200 child files.
• The archive file size is more than 50 MB.
• The archive file is password protected or unreadable.
Note Reputation of the extracted files with safe MIME types, for example, text/plain, are not evaluated.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
484
File Reputation Filtering and File Analysis
Privacy of Information Sent to the Cloud
Privacy of Information Sent to the Cloud
• Only the SHA that uniquely identifies a file is sent to the reputation service in the cloud. The file itself
is not sent.
• If you are using the file analysis service in the cloud and a file qualifies for analysis, the file itself is sent
to the cloud.
• Information about every file that is sent to the cloud for analysis and has a verdict of "malicious" is added
to the reputation database. This information is used along with other data to determine a reputation score.
Information about files analyzed by an on premises Cisco AMP Threat Grid appliance is not shared with
the reputation service.
Configuring File Reputation and Analysis Features
• Requirements for Communication with File Reputation and Analysis Services , on page 485
• Configuring an On-premises File Reputation Server, on page 486
• Configuring an On-Premises File Analysis Server , on page 486
• Enabling and Configuring File Reputation and Analysis Services , on page 487
• (Public Cloud File Analysis Services Only) Configuring Appliance Groups , on page 494
• Configuring the Mail Policy for File Reputation Scanning and File Analysis, on page 495
• Quarantining Messages with Attachments Sent for Analysis, on page 497
• Using the File Analysis Quarantine, on page 498
• Centralized File Analysis Quarantine , on page 500
• X-Headers for File Reputation and Analysis , on page 500
• Sending Notifications to End Users about Dropped Messages or Attachments , on page 501
• Advanced Malware Protection and Clusters , on page 501
• Ensuring That You Receive Alerts About Advanced Malware Protection Issues, on page 501
• Configuring Centralized Reporting for Advanced Malware Protection Features , on page 502
Requirements for Communication with File Reputation and Analysis Services
• All Email Security appliances that use these services must be able to connect to them directly over the
internet (excluding File Analysis services configured to use an on-premises Cisco AMP Threat Grid
Appliance.)
• By default, communication with file reputation and analysis services .
• By default, communication with file reputation and cloud-based analysis services is routed through the
interface that is associated with the default gateway. To route this traffic through a different interface,
create a static route for each address in the Advanced section of the Security Services > File Reputation
and Analysis page.
• The following firewall ports must be open:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
485
File Reputation Filtering and File Analysis
Configuring an On-premises File Reputation Server
Firewall Description Protocol In/Out Hostname Appliance
Ports Interface
32137 Access to cloud TCP Out As configured in Security Management,
(default) or services for obtaining Services > Anti-Malware and unless a static
443 file reputation. Reputation, Advanced section, route is
Cloud Server Pool parameter. configured to
route this traffic
443 Access to cloud TCP Out As configured in Security through a data
services for file Services > Anti-Malware and port.
analysis. Reputation, Advanced section.
Configuring an On-premises File Reputation Server
If you will use a Cisco AMP Virtual Private Cloud appliance as a private-cloud file analysis server:
• You can obtain the Cisco Advanced Malware Protection Virtual Private Cloud Appliance documentation,
including the Installation and Configuration of FireAMP Private Cloud guide, from
http://www.cisco.com/c/en/us/support/security/fireamp-private-cloud-virtual-appliance/tsd-products-support-series-home.html
Use that documentation to perform the tasks described in this topic.
Additional documentation is available using the Help link in the AMP Virtual Private Cloud appliance.
• Set up and configure the Cisco AMP Virtual Private Cloud appliance in either “proxy” or “air-gap”
(on-premises) mode.
• Ensure the Cisco AMP Virtual Private Cloud appliance software version is 2.2, which enables integration
with Cisco Email Security appliance.
• Download the AMP Virtual Private Cloud certificate and keys on that appliance for upload to this Email
Security appliance
• Use the Root Certificate option to skip standard validation when the root authority, trusted by the Email
Security Appliance, does not sign the tunnel proxy server certificate.
Note After you have set up the on-premises file-reputation server, you will configure connection to it from this
Email Security appliance; see Step 6 of Enabling and Configuring File Reputation and Analysis Services , on
page 487
Configuring an On-Premises File Analysis Server
If you will use a Cisco AMP Threat Grid Appliance as a private-cloud file analysis server:
• Obtain the Cisco AMP Threat Grid Appliance Setup and Configuration Guide and the Cisco AMP Threat
Grid Appliance Administration Guide. Cisco AMP Threat Grid Appliance documentation is available
from
http://www.cisco.com/c/en/us/support/security/amp-threat-grid-appliances/products-installation-guides%20-list.html.
Use this documentation to perform the tasks described in this topic.
Additional documentation is available from the Help link in the AMP Threat Grid appliance.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
486
File Reputation Filtering and File Analysis
Enabling and Configuring File Reputation and Analysis Services
In the Administration Guide, search for information about all of the following: integrations with other
Cisco appliances, CSA, Cisco Sandbox API, ESA, and Email Security Appliances, .
• Set up and configure the Cisco AMP Threat Grid Appliance.
• If necessary, update your Cisco AMP Threat Grid Appliance software to version 1.2.1, which supports
integration with Cisco Email Security appliances.
See the AMP Thread Grid documentation for instructions for determining the version number and for
performing the update.
• Ensure that your appliances can communicate with each other over your network. Cisco Email Security
appliances must be able to connect to the CLEAN interface of the AMP Threat Grid appliance.
• If you will deploy a self-signed certificate: Generate a self-signed SSL certificate from the Cisco AMP
Threat Grid appliance to be used on your Email Security appliance . See instructions for downloading
SSL certificates and keys in the administrator’s guide for your AMP Threat Grid appliance. Be sure to
generate a certificate that has the hostname of your AMP Threat Grid appliance as CN. The default
certificate from the AMP Threat Grid appliance does NOT work.
• Registration of your Email Security appliance with your Threat Grid appliance occurs automatically
when you submit the configuration for File Analysis, as described in Enabling and Configuring File
Reputation and Analysis Services , on page 487. However, you must activate the registration as described
in the same procedure.
Enabling and Configuring File Reputation and Analysis Services
Before you begin
• Acquire feature keys for the file reputation service and the file analysis service and transfer them to this
appliance.
• Meet the Requirements for Communication with File Reputation and Analysis Services , on page 485.
• Verify connectivity to the update servers configured on the Updates page .
• If you will use a Cisco AMP Virtual Private Cloud Appliance as a private cloud file reputation server,
see Configuring an On-premises File Reputation Server, on page 486.
• If you will use a Cisco AMP Threat Grid Appliance as a private cloud file analysis server, see Configuring
an On-Premises File Analysis Server , on page 486.
Procedure
Step 1 Select Security Services > File Reputation and Analysis.
Step 2 Click Edit Global Settings.
Step 3 Click Enable File Reputation Filtering and optionally Enable File Analysis.
• If Enable File Reputation Filtering is checked, you must configure the section File Reputation Server
(in Step 6), by either choosing the URL of an external public-reputation cloud server, or by providing
the Private reputation cloud server connection information.
• Similarly, if Enable File Analysis is checked, you must configure the section File Analysis Server URL
(in Step 7), providing either the URL of an external cloud server, or the Private analysis cloud connection
information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
487
File Reputation Filtering and File Analysis
Enabling and Configuring File Reputation and Analysis Services
Note New file types may be added after an upgrade and are not enabled by default. If you have
enabled file analysis, and require the new file types to be included in analysis, you must enable
them.
Step 4 Accept the license agreement if presented.
Step 5 In the File Analysis section, select the required file types from the appropriate file groups (for example,
“Microsoft Documents”) to send for file analysis.
For information about supported file types, see the document described in Supported Files for File Reputation
and Analysis Services , on page 483
Note Cisco periodically checks for potentially malicious file types to prevent zero day threats. If new
threats are identified, details of such file types are sent to your appliance through updater servers.
Select the Other potentially malicious file types option to enable this functionality. If you enable
this functionality, your appliance will send such file types for analysis in addition to the file types
you have selected.
Step 6 Expand the Advanced Settings for File Reputation panel and adjust the following options as needed:
Option Description
Cloud Domain The name of the domain to be used for file reputation queries.
File Reputation Server Choose either: the host name of the public reputation cloud server, or Private
reputation cloud.
If you choose Private reputation cloud, provide the following:
• Server – The host name or IP address of the Cisco AMP Virtual Private
Cloud appliance.
• Public Key – Provide a valid public key for encrypted communications
between this appliance and your private cloud appliance. This must be the
same key used by the private cloud server: locate the key file on this
appliance, and then click Upload File.
Note You must have already downloaded the key file from the server to
this appliance.
AMP for Endpoints Click Register the Appliance with AMP for Endpoints to integrate your
Console Integration appliance with AMP for Endpoints console. For detailed instructions, see
Integrating the Appliance with AMP for Endpoints Console, on page 491.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
488
File Reputation Filtering and File Analysis
Enabling and Configuring File Reputation and Analysis Services
Option Description
SSL Communication for Check Use SSL (Port 443) to communicate on port 443 instead of the default
File Reputation port, 32137. Refer to the Cisco AMP Virtual Private Cloud Appliance user guide
for information about enabling SSH access to the server.
Note SSL communication over port 32137 may require you to open that
port in your firewall.
This option also allows you to configure an upstream proxy for communication
with the file reputation service. If checked, provide the appropriate Server,
Username and Passphrase information.
When Use SSL (Port 443) is selected, you can also check Relax Certificate
Validation to skip standard certificate validation if the tunnel proxy server's
certificate is not signed by a trusted root authority. For instance, select this
option if using a self-signed certificate on a trusted internal tunnel proxy server.
Note If you checked Use SSL (Port 443) in the SSL Communication for
File Reputation section of the Advanced Settings for File Reputation,
you must add the AMP on-premises reputation server CA certificate
to the certificate store on this appliance, using either the CLI
command certconfig > CERTAUTHORITY > CUSTOM, or Network
> Certificates (Custom Certificate Authorities) in the Web interface.
Obtain this certificate from the server (Configuration > SSL > Cloud
server > download).
Heartbeat Interval The frequency, in minutes, with which to ping for retrospective events.
Query Timeout The number of elapsed seconds before the reputation query times out.
Processing Timeout The number of elapsed seconds before the file processing times out.
File Reputation Client ID The client ID for this appliance on the File Reputation server (read-only).
File Retrospective Check Suppress the retrospective verdict alerts to suppress the retrospective
verdict alerts for messages that are not delivered to the message recipient,
dropped or quarantined.
Note Do not change any other settings in this section without guidance from Cisco support.
Step 7 If you will use the cloud service for file analysis, expand the Advanced Settings for File Analysis panel and
adjust the following options as needed:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
489
File Reputation Filtering and File Analysis
Enabling and Configuring File Reputation and Analysis Services
Option Description
File Analysis Server URL Choose either: the name (URL) of an external cloud server, or Private analysis
cloud.
If specifying an external cloud server, choose the server that is physically nearest
to your appliance. Newly available servers will be added to this list periodically
using standard update processes.
Choose Private analysis cloud to use an on-premises Cisco AMP Threat Grid
appliance for file analysis, and provide the following:
• TG Servers – Enter the IPv4 address or hostname of the standalone or
clustered Cisco AMP Threat Grid appliances. You can add a maximum of
seven Cisco AMP Threat Grid appliances.
Note The Serial Number indicates the order in which you add the
standalone or clustered Cisco AMP Threat Grid appliances. It
does not denote the priority of the appliances.
Note You cannot add standalone and cluster servers in one instance.
It must be either standalone or cluster.
You can add only one standalone server in an instance. If it is a
cluster mode, you can add multiple servers upto seven and all
the servers must belong to the same cluster. You cannot add
multiple clusters.
• Certificate Authority – Choose either Use Cisco Default Certificate
Authority, or Use Uploaded Certificate Authority.
If you choose Use Uploaded Certificate Authority, click Browse to upload
a valid certificate file for encrypted communications between this appliance
and your private cloud appliance. This must be the same certificate used
by the private cloud server.
Note If you have configured the Cisco AMP Threat Grid portal on your
appliance for file analysis, you can access the Cisco AMP Threat
Grid portal (for example, https://panacea.threatgrid.eu) to view and
track the files submitted for file analysis. For more information on
how to access the Cisco AMP Threat Grid portal, contact Cisco TAC.
Proxy Settings Check Use File Reputation Proxy checkbox to use the same File Reputation
tunnel proxy that you have already configured, as an upstream proxy for file
analysis.
If you want to configure a different upstream proxy, uncheck the Use File
Reputation Proxy checkbox and enter the appropriate Server, Port, Username,
and Passphrase information.
File Analysis Client ID The client ID for this appliance on the File Analysis server (read-only).
Step 8 (Optional) Expand the Cache Settings panel, if you want to configure the cache expiry period for File Reputation
disposition values.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
490
File Reputation Filtering and File Analysis
Integrating the Appliance with AMP for Endpoints Console
Step 9 Expand the Threshold Settings panel, if you want to set the upper limit for the acceptable file analysis score.
The score above this threshold indicates that the file is infected. Choose any one of the following options:
• Use value from Cloud Service (95)
• Enter Custom Value – defaults to 95
Step 10 Submit and commit your changes.
Step 11 If you are using an on-premises Cisco AMP Threat Grid appliance, activate the account for this appliance on
the AMP Threat Grid appliance.
Complete instructions for activating the “user” account are available in the AMP Threat Grid documentation.
a) Note the File Analysis Client ID that appears at the bottom of the page section. This identifies the “user”
that you will activate.
b) Sign in to the AMP Threat Grid appliance.
c) Select Welcome... > Manage Users and navigate to User Details.
d) Locate the “user” account based on the File Analysis Client ID of your Email Security appliances.
e) Activate this “user” account for your appliance.
Integrating the Appliance with AMP for Endpoints Console
You can integrate your appliance with AMP for Endpoints console, and perform the following actions in AMP
for Endpoints console:
• Create a simple custom detection list.
• Add new malicious file SHAs to the simple custom detection list.
• Create an application allowed list.
• Add new file SHAs to the application allowed list.
• Create a custom policy.
• Attach the simple custom detection list and the application allowed list to the custom policy.
• Create a custom group.
• Attach the custom policy to the custom group.
• Move your registered appliance from the default group to the custom group.
• View the file trajectory details of a particular file SHA.
To integrate your appliance with AMP for Endpoints console, you need to register your appliance with the
console.
After the integration, when a file SHA is sent to the File Reputation server, the verdict obtained for the file
SHA from the File Reputation Server is overridden by the verdict already available for the same file SHA in
the AMP for Endpoints console.
If a file SHA is already marked as malicious globally, and if the same file SHA is added to the blocked list
in AMP for Endpoints console, the file disposition is malicious.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
491
File Reputation Filtering and File Analysis
Integrating the Appliance with AMP for Endpoints Console
The Advanced Malware Protection report page includes a new section - Incoming Malware Files by Category
to view the percentage of block listed file SHAs received from the AMP for Endpoints console that are
displayed as Custom Detection. The threat name of a block listed file SHA is displayed as Simple Custom
Detection in the Incoming Malware Threat Files section of the report. You can click the link in the More
Details section of the report to view the file trajectory details of a block listed file SHA in the AMP for
Endpoints console.
Before you begin
Make sure you have a user account in AMP for Endpoints console with admin access rights. For more details
on how to create an AMP for Endpoints console user account, contact Cisco TAC.
[For clustered configuration] In a clustered configuration, you can only register your logged-in appliance with
AMP for Endpoints console. If you have already registered your appliance with AMP for Endpoints console
in the standalone mode, make sure to deregister the appliance manually before you join it to a cluster.
Make sure you have enabled and configured File Reputation Filtering. See Enabling and Configuring File
Reputation and Analysis Services , on page 487to know how to enable and configure File Reputation Filtering.
Procedure
Step 1 Select Security Services > File Reputation and Analysis.
Step 2 Click Edit Global Settings.
Step 3 Click Register Appliance with AMP for Endpoints in the Advanced Settings panel for File Reputation in
the File Reputation and File Analysis page of the web interface.
Once you click Register Appliance with AMP for Endpoints, the AMP for Endpoints console login page
appears.
Step 4 Log in to the AMP for Endpoints console with your user credentials.
Step 5 Click Allow in the AMP for Endpoints authorization page to register your appliance.
Once you click Allow, the registration is complete, and it redirects you to the File Reputation and Analysis
page of your appliance. Your appliance name is displayed in the AMP for Endpoints Console Integration
field. You can use the appliance name to customize your appliance settings in the AMP for Endpoints console
page.
What to do next
Next Steps:
• You can go to Accounts > Applications section of the AMP for Endpoints console page, to verify whether
your appliance is registered with AMP for Endpoints console. Your appliance name is displayed in the
Applications section of the AMP for Endpoints console page.
• After registration, your appliance is added to the default group (Audit Group) which has a default policy
(Network Policy) attached to it. The default policy contains file SHAs that are added to the blocked list
or the allowed list. If you want to customize the AMP for Endpoints settings for your appliance, and add
your own file SHAs that are added to the blocked list or the allowed list, see the AMP for Endpoints user
documentation at https://console.amp.cisco.com/docs.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
492
File Reputation Filtering and File Analysis
Important! Changes Needed in File Analysis Setting
• Make sure that the ‘File Reputation Client ID’ value in the File Reputation Settings page and the ‘Device
GUID’ value of your registered appliance in the AMP for Endpoints console portal is the same. If the
values are different, the integration of your appliance with AMP for Endpoints will not work properly
at the machine or cluster level. You will need to deregister and register your appliance again to use the
AMP for Endpoints functionality.
• To deregister your appliance connection from AMP for Endpoints console, you can click Deregister in
the Advanced Settings for File Reputation section in your appliance, or you need to go to the AMP for
Endpoints console page at https://console.amp.cisco.com/. For more information, see the AMP for
Endpoints user documentation at https://console.amp.cisco.com/docs.
Note When you change your File Reputation server to a different data center, your appliance is automatically
deregistered from the AMP for Endpoints console. You must re-register your appliance with AMP for Endpoints
console with the same data center selected for the File Reputation server.
Note If you change your file reputation server at the cluster level, your logged-in appliance is automatically
deregistered from the AMP for Endpoints console. Ensure that you deregister all the other machines in the
cluster. You must re-register all your appliances with AMP for Endpoints console with the same data center
selected for the File Reputation server
Note If a malicious file SHA gets a clean verdict, then verify whether the same file SHA is added to the allowed
list in AMP for Endpoints console.
Important! Changes Needed in File Analysis Setting
If you plan to use a new public cloud File Analysis service, make sure you read the following instructions to
maintain datacenter isolation:
• The existing appliance grouping information is not preserved in the new File Analysis server. You must
regroup your appliances on the new File Analysis server.
• Messages that are quarantined to the File Analysis Quarantine are retained until the retention period.
After the quarantine retention period, the messages are released from the File Analysis Quarantine, and
re-scanned by the AMP engine. The file is then uploaded to the new File Analysis server for analysis
but the message is not sent to the File Analysis Quarantine again.
For more details, refer to the Cisco AMP Thread Grid documentation from
http://www.cisco.com/c/en/us/support/security/amp-threat-grid-appliances/products-installation-guides
-list.html.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
493
File Reputation Filtering and File Analysis
(Public Cloud File Analysis Services Only) Configuring Appliance Groups
(Public Cloud File Analysis Services Only) Configuring Appliance Groups
In order to allow all content security appliances in your organization to view file analysis result details in the
cloud for files sent for analysis from any appliance in your organization, you need to join all appliances to
the same appliance group.
Note You can configure appliance groups at the machine level. The appliance groups cannot be configured at the
cluster level.
Procedure
Step 1 Select Security Services > File Reputation and Analysis.
Step 2 In the Appliance Grouping for File Analysis Cloud Reporting section, enter the File Analysis Group ID.
• If this is the first appliance being added to the group, provide a useful identifier for the group.
• This ID is case-sensitive, and cannot contain spaces.
• The ID you provide must be identical on all appliances that will share data about files that are uploaded
for analysis. However, the ID is not validated on subsequent group appliances.
• If you enter the Group ID incorrectly or need to change it for any other reason, you must open a case
with Cisco TAC.
• This change takes effect immediately; it does not require a Commit.
• All appliances in the group must be configured to use the same File Analysis server in the cloud.
• An appliance can belong to only one group.
• You can add a machine to a group at any time, but you can do it only once.
Step 3 Click Group Now.
Which Appliances Are In the Analysis Group?
Procedure
Step 1 Select Security Services> File Reputation and Analysis.
Step 2 In the Appliance Grouping for File Analysis Cloud Reporting section, click View Appliances.
Step 3 To view the File Analysis Client ID of a particular appliance, look in the following location:
Appliance Location of File Analysis Client ID
Email Security appliance Advanced Settings for File Analysis section on the Security Services > File
Reputation and Analysis page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
494
File Reputation Filtering and File Analysis
Configuring the Mail Policy for File Reputation Scanning and File Analysis
Appliance Location of File Analysis Client ID
Web Security appliance Advanced Settings for File Analysis section on the Security Services >
Anti-Malware and Reputation page.
Security Management At the bottom of the Management Appliance > Centralized Services >
appliance Security Appliances page.
Configuring the Mail Policy for File Reputation Scanning and File Analysis
Procedure
Step 1 Select Mail Policies > Incoming Mail Policies or Mail Policies > Outgoing Mail Policies, whichever is
applicable.
Step 2 Click the link in the Advanced Malware Protection column of the mail policy to modify.
Step 3 Choose options.
• If you do not have an on-premises Cisco AMP Threat Grid Appliance and you do not want to send files
to the cloud, for example for confidentiality reasons, uncheck Enable File Analysis.
• Select the actions that the appliance must perform if an attachment is considered as Unscannable.
Attachments are considered Unscannable when the appliance is unable to scan the file for the following
reasons:
• Message Errors:
• Password-protected archived or compressed file
• Messages with RFC violation.
• Messages that contain more than 200 child files
• Messages that contain more than five nested levels of child files
• Messages with extraction failure
• Rate Limit - The files that are not scanned by the File Analysis server because the appliance has
reached the file upload limit.
• AMP Service not available:
• File Reputation service is not available
• File Analysis service is not available
• File reputation query timeout
• File upload query timeout
• You can configure any one of the following message handling actions on messages that are not scanned
by the AMP engine:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
495
File Reputation Filtering and File Analysis
Configuring the Mail Policy for File Reputation Scanning and File Analysis
• Drop the message
• Deliver the message as it is
• Send the message to the policy quarantine
• Select the following additional actions, if you choose to deliver the message:
• Whether to archive the original message. Archived messages are stored as an mbox-format log file
in the amparchive directory on the appliance. The preconfigured AMP Archive ( amparchive ) log
subscription is required.
• Whether to warn the end user by modifying the message subject, for example, [WARNING:
ATTACHMENT(S) MAY CONTAIN MALWARE].
• Whether to add a custom header to provide granular controls to the administrator.
• Whether to modify the message recipient causing the message to be delivered to a different address.
Click Yes and enter the new recipient address.
• Whether to send the unscannable messages to an alternate destination host. Click Yes and enter an
alternate IP address or hostname.
• Select the following additional actions, if you choose to send the message to the policy quarantine:
• Whether to select a policy quarantine from the drop-down. When flagged for quarantine, the message
is placed in the quarantine when it reaches the end of the email pipeline, and is scanned by all the
other engines in the email pipeline.
• Whether to archive the original message. Archived messages are stored as an mbox-format log file
in the amparchive directory on the appliance. The preconfigured AMP Archive ( amparchive ) log
subscription is required.
• Whether to warn the end user by modifying the message subject, for example, [WARNING:
ATTACHMENT(S) MAY CONTAIN MALWARE].
• Whether to add a custom header to provide granular controls to the administrator.
• Select the actions that AsyncOS must perform if an attachment is considered Malicious. Select the
following:
• Whether to deliver or drop the message.
• Whether to archive the original message. Archived messages are stored as an mbox-format log file
in the amparchive directory on the appliance. The preconfigured AMP Archive ( amparchive ) log
subscription is required.
• Whether to deliver the message after removing the malware attachments.
• Whether to warn the end user by modifying the message subject, for example, [WARNING:
MALWARE DETECTED IN ATTACHMENT(S)].
• Whether to add a custom header to provide granular controls to the administrator.
• Whether to modify the message recipient causing the message to be delivered to a different address.
Click Yes and enter the new recipient address.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
496
File Reputation Filtering and File Analysis
Quarantining Messages with Attachments Sent for Analysis
• Whether to send the malicious messages to an alternate destination host. Click Yes and enter an
alternate IP address or hostname.
• Select the actions that AsyncOS must perform if an attachment is sent for File Analysis. Select the
following:
• Whether to deliver or quarantine the message.
• Whether to archive the original message. Archived messages are stored as an mbox-format log file
in the amparchive directory on the appliance. The preconfigured AMP Archive ( amparchive ) log
subscription is required.
• Whether to warn the end user by modifying the message subject, for example, “ [WARNING:
ATTACHMENT(S) MAY CONTAIN MALWARE] .”
• Whether to add a custom header to provide granular controls to the administrator.
• Whether to modify the message recipient causing the message to be delivered to a different address.
Click Yes and enter the new recipient address.
• Whether to send the messages that are sent for file analysis to an alternate destination host. Click
Yes and enter an alternate IP address or hostname.
• (For Incoming Mail Policy only) Configure the remedial actions to be performed on messages delivered
to end users when the threat verdict changes to malicious. Select Enable Mailbox Auto Remediation and
select one of the following actions:
• Forward to an email address. Select this option to forward the message with malicious attachment
to a specified user, for example, an email administrator.
• Delete the message. Select this option to permanently delete the message with malicious attachment
from the end user’s mailbox.
• Forward to an email address and delete the message. Select this option to forward the message with
malicious attachment to a specified user, for example, an email administrator and permanently delete
that message from the end user’s mailbox.
Note Messages from certain folders (for example, Deleted Items) cannot be deleted as Office
365 services do not support deletion of messages from these folders.
Important Before configuring the Mailbox Auto Remediation settings, review Remediating Messages
in Mailboxes, on page 577
Step 4 Submit and commit your changes.
Quarantining Messages with Attachments Sent for Analysis
You can configure the appliance to quarantine files sent for analysis instead of releasing them immediately
to the workqueue. Quarantined messages and their attachments are rescanned for threats upon release from
quarantine. If the message is released after file analysis results are available to the reputation scanner, any
identified threats will be caught during rescanning.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
497
File Reputation Filtering and File Analysis
Using the File Analysis Quarantine
Procedure
Step 1 Select Mail Policies > Incoming Mail Policies or Mail Policies > Outgoing Mail Policies, whichever is
applicable.
Step 2 Click the link in the Advanced Malware Protection column of the mail policy to modify.
Step 3 Under Messages with File Analysis Pending section, select Quarantine from the Action Applied to Message
drop-down.
The quarantined messages are stored in the File Analysis quarantine. See Using the File Analysis Quarantine,
on page 498.
Step 4 (Optional) Under Messages with File Analysis Pending section, choose the following options:
• Whether to archive the original message. Archived messages are stored as an mbox-format log file in
the amparchive directory on the appliance. The preconfigured AMP Archive ( amparchive ) log
subscription is required.
• Whether to warn the end user by modifying the message subject, for example, “ [WARNING:
ATTACHMENT(S) MAY CONTAIN MALWARE] .”
• Whether to drop attachments in case of any pending file analysis verdict while delivering the final message
from the appliance. The default option is ‘No’
• Whether to add a custom header to provide granular controls to the administrator.
Note The above actions mentioned in step4 are applicable only when a message is released from the
quarantine and not when the message is sent to the quarantine:
• Archiving the original message.
• Modifying a message subject.
• Adding a custom header.
Step 5 Submit and commit your changes.
What to do next
Related Topics
Using the File Analysis Quarantine, on page 498
Using the File Analysis Quarantine
• Edit File Analysis Quarantine Settings, on page 499
• Manually Processing Messages in the File Analysis Quarantine, on page 500
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
498
File Reputation Filtering and File Analysis
Edit File Analysis Quarantine Settings
Edit File Analysis Quarantine Settings
Procedure
Step 1 Select Monitor > Policy, Virus, and Outbreak Quarantines.
Step 2 Click the File Analysis quarantine link.
Step 3 Specify the retention period.
Changing the default from one hour is not recommended.
Step 4 Specify the default action that AsyncOS must take after the retention period has passed.
Step 5 If you do not want messages in this quarantine to be processed before the end of the Retention Period you
specify, even when quarantine disk space is full, deselect Free up space by applying default action on
messages upon space overflow.
Step 6 If you select Release as the Default Action, optionally specify additional actions to apply to messages that
are released before their retention period has passed:
Option Information
Modify Subject Type the text to add and specify whether to add it to the beginning or the end
of the original message subject.
For example, you might want to warn the recipient that the message may contain
malware attachments.
Note In order for a subject with non-ASCII characters to display correctly
it must be represented according to RFC 2047.
Add X-Header An X-Header can provide a record of actions taken on a message. This can be
helpful for example when handling inquiries about why a particular message
was delivered.
Enter a name and value.
Example:
Name = Inappropriate-release-early
Value = True
Strip Attachments Stripping attachments protects against malware attachments in messages.
Step 7 Specify the users who can access this quarantine:
User Information
Local Users The list of local users includes only users with roles that can access quarantines.
The list excludes users with Administrator privileges, because all Administrators
have full access to quarantines.
Externally Authenticated You must have configured external authentication.
Users
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
499
File Reputation Filtering and File Analysis
Manually Processing Messages in the File Analysis Quarantine
User Information
Custom User Roles You see this option only if you have created at least one custom user role with
quarantine access.
Step 8 Submit and commit your changes.
Manually Processing Messages in the File Analysis Quarantine
Procedure
Step 1 Select Monitor > Policy, Virus, and Outbreak Quarantines.
Step 2 In the row for File Analysis quarantine, click the blue number in the Messages column of the table.
Step 3 Depending on your requirements, perform the following actions on messages:
• Delete
• Release
• Delay Scheduled Exit from quarantine
• Send a copy of messages to email addresses that you specify
Centralized File Analysis Quarantine
For information about the centralized File Analysis quarantine, see chapter "Centralized Policy, Virus and
Outbreak Quarantine" of the Cisco Email Security Appliance Guide.
X-Headers for File Reputation and Analysis
You can use X-Headers to mark messages with actions and results of message processing steps. You tag
messages with X-Headers in mail policies, then use content filters to choose handling options and final actions
for these messages.
Values are case-sensitive.
Header Name Possible Values (Case Description
Sensitive)
X-Amp-Result Clean Verdict applied to messages processed by the file
reputation service.
Malicious
Unscannable
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
500
File Reputation Filtering and File Analysis
Sending Notifications to End Users about Dropped Messages or Attachments
Header Name Possible Values (Case Description
Sensitive)
X-Amp-Original-Verdict file unknown Verdict before adjustment based on reputation
threshold. This header exists only if the original
verdict unknown
verdict is one of the possible values.
X-Amp-File-Uploaded true If any file attached to a message was sent for
analysis, this header is "true."
false
Sending Notifications to End Users about Dropped Messages or Attachments
To send notifications to end users when a suspect attachment or its parent message has been dropped based
on file reputation scanning, use an X-header or Custom Header and Content Filters.
Advanced Malware Protection and Clusters
If you use centralized management, you can enable Advanced Malware Protection and mail policies at the
cluster, group and machine level.
Feature keys must be added at the machine level.
Appliance Groups should not be configured at cluster level.
Ensuring That You Receive Alerts About Advanced Malware Protection Issues
Ensure that the appliance is configured to send you alerts related to Advanced Malware Protection.
You will receive alerts when:
Alert Description Type Severity
You are setting up a connection to an on-premises Anti-Malware Warning
(private cloud) Cisco AMP Threat Grid appliance and
you need to activate the account as described in
Enabling and Configuring File Reputation and
Analysis Services , on page 487
Feature keys expire (As is standard for all features)
The file reputation or file analysis service is Anti-Virus and AMP Warning
unreachable.
Communication with cloud services is established. Anti-Virus and AMP Info
The reputation and analysis engine is restarted by a Anti-Virus and AMP Info
watchdog service
A file reputation verdict changes. Anti-Virus and AMP Info
File types that can be sent for analysis have changed. Anti-Virus and AMP Info
You may want to enable upload of new file types.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
501
File Reputation Filtering and File Analysis
Configuring Centralized Reporting for Advanced Malware Protection Features
Alert Description Type Severity
Analysis of some file types is temporarily unavailable. Anti-Virus and AMP Warning
Analysis of all supported file types is restored after a Anti-Virus and AMP Info
temporary outage.
Invalid File Analysis service key. You need to contact AMP Error
Cisco TAC with the file analysis id details to fix this
error.
Related Topics
• Several Alerts About Failure to Connect to File Reputation or File Analysis Servers , on page 506
• Taking Action When File Threat Verdicts Change , on page 505
Configuring Centralized Reporting for Advanced Malware Protection Features
If you will centralize reporting on a Security Management appliance, see important configuration requirements
in the Advanced Malware Protection sections in theemail reporting chapter of the online help or user guide
for your management appliance.
File Reputation and File Analysis Reporting and Tracking
• Identifying Files by SHA-256 Hash , on page 502
• #unique_864
• Viewing File Reputation Filtering Data in Other Reports , on page 504
• About Message Tracking and Advanced Malware Protection Features , on page 504
Identifying Files by SHA-256 Hash
Because filenames can easily be changed, the appliance generates an identifier for each file using a Secure
Hash Algorithm (SHA-256). If an appliance processes the same file with different names, all instances are
recognized as the same SHA-256. If multiple appliances process the same file, all instances of the file have
the same SHA-256 identifier.
In most reports, files are listed by their SHA-256 value (in an abbreviated format
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
502
File Reputation Filtering and File Analysis
File Reputation and File Analysis Report Pages
File Reputation and File Analysis Report Pages
Report Description
Advanced Malware Protection Shows file-based threats that were identified by the file reputation
service.
For files with changed verdicts, see the AMP Verdict updates report.
Those verdicts are not reflected in the Advanced Malware Protection
report.
If a file extracted from a compressed or archived file is malicious,
only the SHA value of the compressed or archived file is included in
the Advanced Malware Protection report.
The Incoming Malware Files by Category section shows the
percentage of file SHAs on the blocked list received from the AMP
for Endpoints console that are categorised as Custom Detection.
The threat name of file SHA on the blocked list obtained from AMP
for Endpoints console is displayed as Simple Custom Detection in
the Incoming Malware Threat Files section of the report.
You can click the link in the More Details section of the report to
view the file trajectory details about file SHA on the blocked list in
the AMP for Endpoints console.
You can view the Low Risk verdict details in the Incoming Files
Handed by AMP section of the report.
Advanced Malware Protection File Displays the time and verdict (or interim verdict) for each file sent
Analysis for analysis. The appliance checks for analysis results every 30
minutes.
To view more than 1000 File Analysis results, export the data as a
.csv file.
Drill down to view detailed analysis results, including the threat
characteristics for each file.
You can also search for additional information about an SHA, or
click the link at the bottom of the file analysis details page to view
additional details on the server that analyzed the file.
Note If extracted files from a compressed or an archive file are
sent for file analysis, only SHA values of these extracted
files are included in the File Analysis report.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
503
File Reputation Filtering and File Analysis
Viewing File Reputation Filtering Data in Other Reports
Report Description
Advanced Malware Protection Because Advanced Malware Protection is focused on targeted and
Reputation zero-day threats, threat verdicts can change as aggregated data
provides more information.
The AMP Reputation report lists the files processed by this appliance
for which the verdict has changed since the message was received.
For more information about this situation, see File Threat Verdict
Updates , on page 481.
To view more than 1000 verdict updates, export the data as a .csv
file.
In the case of multiple verdict changes for a single SHA-256, this
report shows only the latest verdict, not the verdict history.
To view all affected messages for a particular SHA-256 within the
maximum available time range (regardless of the time range selected
for the report) click a SHA-256 link.
Viewing File Reputation Filtering Data in Other Reports
Data for file reputation and analysis is available in other reports where relevant. A Detected by Advanced
Malware Protection" column may be hidden by default in applicable reports. To display additional columns,
click the Columns link below the table.
About Message Tracking and Advanced Malware Protection Features
When searching for file threat information in Message Tracking, keep the following points in mind:
• To search for malicious files found by the file reputation service, select Advanced Malware Protection
Positive for the Message Event option in the Advanced section in Web Message Tracking.
• Message Tracking includes only information about file reputation processing and the original file reputation
verdicts returned at the time a transaction message was processed. For example, if a file was initially
found to be clean, then a verdict update found the file to be malicious, only the clean verdict appears in
Tracking results.
In Message Tracking details, the Processing Details section shows:
• The SHA-256 of each attachment in the message, and
• The final Advanced Malware Protection verdict for the message as a whole, and
• Any attachments which were found to contain malware.
• Verdict updates are available only in the AMP Verdict Updates report. The original message details in
Message Tracking are not updated with verdict changes. To see transactions messages that have a particular
attachment, click a SHA-256 in the verdict updates report.
• Information about File Analysis, including analysis results and whether or not a file was sent for analysis,
are available only in the File Analysis report.
Additional information about an analyzed file may be available from the cloud or on-premises File
Analysis server. To view any available File Analysis information for a file, select Reporting Monitor
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
504
File Reputation Filtering and File Analysis
Taking Action When File Threat Verdicts Change
> File Analysis and enter the SHA-256 to search for the file . If the File Analysis service has analyzed
the file from any source, you can see the details. Results are displayed only for files that have been
analyzed.
If the appliance processed a subsequent instance of a file that was sent for analysis, those instances will
appear in Message Tracking search results.
Taking Action When File Threat Verdicts Change
Procedure
Step 1 View the AMP Verdict Updates report.
Step 2 Click the relevant SHA-256 link to viewmessage tracking data for allmessages that contained that file that
may have been delivered to end users.
Step 3 Using the tracking data, identify the users that may have been compromised, as well as information such as
the file names involved in the breach and sender of the file.
Step 4 Check the File Analysis report to see if this SHA-256 was sent for analysis, to understand the threat behavior
of the file in more detail.
What to do next
Related Topics
File Threat Verdict Updates , on page 481
Troubleshooting File Reputation and Analysis
• Log Files , on page 505
• Using Trace , on page 506
• Several Alerts About Failure to Connect to File Reputation or File Analysis Servers , on page 506
• API Key Error (On-Premises File Analysis) , on page 506
• Files are Not Uploaded As Expected , on page 507
• Alerts about File Types That Can Be Sent for Analysis , on page 507
Log Files
In logs:
• AMP and amp refer to the file reputation service or engine.
• Retrospective refers to verdict updates.
• VRT and sandboxing refer to the file analysis service.
Information about Advanced Malware Protection including File Analysis is logged in AMP Engine Logs.
File reputation filtering and analysis events are logged in AMP Engine logs and Mail logs.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
505
File Reputation Filtering and File Analysis
Using Trace
In the log message “Response received for file reputation query” possible values for “upload action” are:
• 1: SEND. In this case, you must send the file for File Analysis.
• 2: DON’T SEND. In this case, you do not send the file for File Analysis.
• 3: SEND ONLY METADATA. In this case, you send only the metadata and not the entire file for File
Analysis.
• 0: NO ACTION. In this case, no other action is required.
For “Disposition” in mail logs:
• 1: No malware detected or presumed clean (treated as clean)
• 2: Clean
• 3: Malware
Spyname is threat name.
Using Trace
Trace is not available for the file reputation filtering and analysis features. Instead, send a test message from
an account outside your organization.
Several Alerts About Failure to Connect to File Reputation or File Analysis
Servers
Problem
You receive several alerts about failures to connect to the file reputation or analysis services in the cloud. (A
single alert may indicate only a transient issue.)
Solution
• Ensure that you have met the requirements in Requirements for Communication with File Reputation
and Analysis Services , on page 485.
• Check for network issues that may prevent the appliance from communicating with the cloud services.
• Increase the Query Timeout value:
Select Security Services > File Reputation and Analysis. The Query Timeout value is in the Advanced
settings area .
API Key Error (On-Premises File Analysis)
Problem
You receive an API key alert when attempting to view File Analysis report details, or the Email Security
appliance is unable to connect to the AMP Threat Grid server to upload files for analysis.
Solution
This error can occur if you change the hostname of the AMP Threat Grid server and you are using a self-signed
certificate from the AMP Threat Grid server, as well as possibly under other circumstances. To resolve the
issue:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
506
File Reputation Filtering and File Analysis
Files are Not Uploaded As Expected
• Generate a new certificate from the AMP Threat Grid appliance that has the new hostname.
• Upload the new certificate to the Email Security appliance.
• Reset the API key on the AMP Threat Grid appliance. For instructions, see the online help on the AMP
Threat Grid appliance.
Related Topics
• Enabling and Configuring File Reputation and Analysis Services , on page 487
Files are Not Uploaded As Expected
Problem
Files are not evaluated or analyzed as expected. There is no alert or obvious error.
Solution
Consider the following:
• The file may have been sent for analysis by another appliance and thus already be present on the File
Analysis server or in the cache of the appliance that is processing the file.
Alerts about File Types That Can Be Sent for Analysis
Problem
You receive alerts of severity Info about file types that can be sent for file analysis.
Solution
This alert is sent when supported file types change, or when the appliance checks to see what file types are
supported. This can occur when:
• You or another administrator changes the file types selected for analysis.
• Supported file types change temporarily based on availability in the cloud service. In this case, support
for the file types selected on the appliance will be restored as soon as possible. Both processes are dynamic
and do not require any action from you.
• The appliance restarts, for example as part of an AsyncOS upgrade.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
507
File Reputation Filtering and File Analysis
Alerts about File Types That Can Be Sent for Analysis
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
508
CHAPTER 22
Data Loss Prevention
This chapter contains the following sections:
• Overview of Data Loss Prevention , on page 509
• System Requirements for Data Loss Prevention , on page 511
• How to Set Up Data Loss Prevention , on page 511
• Enabling Data Loss Prevention (DLP) , on page 512
• Policies for Data Loss Prevention, on page 512
• Message Actions, on page 530
• Displaying Sensitive DLP Data in Message Tracking , on page 535
• About Updating the DLP Engine and Content Matching Classifiers, on page 536
• Working with DLP Incident Messages and Data , on page 537
• Troubleshooting Data Loss Prevention, on page 538
Overview of Data Loss Prevention
The Data Loss Prevention (DLP) feature secures your organization’s proprietary information and intellectual
property and enforces compliance with government regulations by preventing users from maliciously or
unintentionally emailing sensitive data from your network. You define the types of data that your employees
are not allowed to email by creating DLP policies that are used to scan outgoing messages for any data that
may violate laws or corporate policies.
Related Topics
• Overview of the DLP Scanning Process , on page 509
• How Data Loss Prevention Works , on page 510
Overview of the DLP Scanning Process
Action More Information
1. A user in your organization sends an email The email gateway processes messages that
message to a recipient outside of your are entering or leaving your network.
organization.
Messages sent to other users within your
network are not scanned.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
509
Data Loss Prevention
How Data Loss Prevention Works
Action More Information
2. The email gateway processes the message through Pre-DLP-scanning processes ensure, for
the stages of its email “work queue” before it example, that the message includes no spam
reaches the DLP scanning stage. or malware.
To see where DLP processing occurs in the
workqueue, see the workqueue flow diagram
in Email Pipeline Flows, on page 65.
3. The email gateway scans the message body, See How Data Loss Prevention Works , on
header, and attachments for sensitive content that page 510.
you have identified in DLP Policies.
4. If sensitive content is found, the email gateway You define the actions to be taken. See
takes action to protect the data, such as Message Actions, on page 530.
quarantining the message, dropping it, or
delivering it with restrictions.
Otherwise, the message continues through the
email gateway's work queue and if no issues are
found, the email gateway delivers it to the
recipient.
How Data Loss Prevention Works
When someone in your organization sends a message to a recipient outside your organization, the email
gateway determines which outgoing mail policy applies to the sender or recipient of that message, based on
rules that you defined. The email gateway evaluates the content of the message using the DLP policies that
are specified in that outgoing mail policy.
Specifically, the email gateway scans the message content (including headers and attachments) for text that
matches words, phrases, predefined patterns such as social security numbers, or a regular expression that you
identified as sensitive content in an applicable DLP policy.
The email gateway also evaluates the context of disallowed content in order to minimize false positive matches.
For example, a number matching a credit card number pattern is only a violation if it is accompanied by an
expiration date, credit card company name (Visa, AMEX, etc.), or a person’s name and address.
If message content matches more than one DLP policy, the first matching DLP policy in the list applies, based
on the order that you specified. If an outgoing mail policy has multiple DLP policies that use the same criteria
to determine whether content is a violation, all policies use the result from a single content scan.
When potentially sensitive content appears in a message, the email gateway assigns a risk factor score between
0 - 100 to the potential violation. This score indicates the likelihood that the message contains a DLP violation.
The email gateway then assigns the severity level (such as Critical or Low) that you have defined for that risk
factor score, and performs the message action that you have specified for that severity level in the applicable
DLP Policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
510
Data Loss Prevention
System Requirements for Data Loss Prevention
System Requirements for Data Loss Prevention
Data Loss Prevention is supported on all supported C-Series and X-Series appliances except appliances using
D-Mode licenses.
How to Set Up Data Loss Prevention
Perform these steps in order:
Procedure
Command or Action Purpose
Step 1 Enable the DLP feature. Enabling Data Loss Prevention (DLP) , on page
512
Step 2 Define the possible actions that can be taken Message Actions, on page 530
for messages in which violations are found or
suspected. For example, you can quarantine
such messages.
Step 3 Create DLP policies, which: Choose a method:
• identify the content that must not be • Setting Up DLP Prevention Using a
emailed from your organization, and Wizard , on page 513
• specify which actions will be taken for • Creating a DLP Policy Using a Predefined
each violation. Template , on page 515
• Creating a Custom DLP Policy (Advanced)
, on page 516
Step 4 Set the order of the DLP policies to determine Arranging the Order of the Email DLP Policies
which DLP policy is used to evaluate messages for Violation Matching , on page 529
for DLP violations when the content could
match more than one DLP policy.
Step 5 Ensure that you have created Outgoing Mail See Mail Policies, on page 267
Policies for each group of senders and recipients
To further refine permitted and restricted
whose messages will be scanned for DLP
message senders and recipients in individual
violations.
DLP policies, see Filtering Messages for DLP
Policies, on page 527.
Step 6 Specify which DLP policies apply to which Associating DLP Policies with Outgoing Mail
senders and recipients by assigning DLP Policies, on page 529
policies to Outgoing Mail Policies.
Step 7 Configure settings for storage of and access to • Displaying Sensitive DLP Data in Message
sensitive DLP information. Tracking , on page 535
• Controlling Access to Sensitive
Information in Message Tracking, on page
981
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
511
Data Loss Prevention
Enabling Data Loss Prevention (DLP)
Enabling Data Loss Prevention (DLP)
Procedure
Step 1 Select Security Services > Data Loss Prevention.
Step 2 Click Enable.
Step 3 Scroll to the bottom of the license agreement page and click Accept to accept the agreement.
Note If you do not accept the license agreement, DLP is not enabled on the email gateway.
Step 4 Under Data Loss Prevention Global Settings, select Enable Data Loss Prevention.
Step 5 (Recommended) For now, deselect the other options on this page.
You can change these settings later, following instructions discussed elsewhere in this chapter.
Step 6 Submit and commit your changes.
What to do next
See How to Set Up Data Loss Prevention , on page 511.
Related Topics
• Displaying Sensitive DLP Data in Message Tracking , on page 535
• Setting Up DLP Prevention Using a Wizard , on page 513
• About Updating the DLP Engine and Content Matching Classifiers, on page 536
Policies for Data Loss Prevention
Related Topics
• DLP Policy Description , on page 513
• Predefined DLP Policy Templates, on page 513
• Setting Up DLP Prevention Using a Wizard , on page 513
• Creating a DLP Policy Using a Predefined Template , on page 515
• Creating a Custom DLP Policy (Advanced) , on page 516
• About Defining Disallowed Content Using Content Matching Classifiers , on page 517
• Filtering Messages for DLP Policies, on page 527
• About Assessing Violation Severity , on page 528
• Arranging the Order of the Email DLP Policies for Violation Matching , on page 529
• Associating DLP Policies with the Default Outgoing Mail Policy , on page 529
• Important Information About Editing or Deleting DLP Policies , on page 530
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
512
Data Loss Prevention
DLP Policy Description
DLP Policy Description
A DLP policy includes:
• a set of conditions that determine whether an outgoing message contains sensitive data, and
• the actions to be taken when a message contains such data.
You specify how message content is evaluated, based on:
• Specific disallowed content or patterns of information. Depending on the policy, you may need to create
a regular expression to search for identification numbers. See About Defining Disallowed Content Using
Content Matching Classifiers , on page 517.
• A list of specific senders and recipients for filtering messages. See Filtering Messages for DLP Policies,
on page 527.
• A list of attachment file types for filtering messages. See Filtering Messages for DLP Policies, on page
527.
• Settings that allow different actions to occur based on the severity of the violation. See About Assessing
Violation Severity , on page 528.
You determine the message senders and recipients that each policy applies to when you enable DLP policies
in Outgoing Mail Policies.
Predefined DLP Policy Templates
To simplify creation of DLP policies, your email gateway includes a large collection of predefined policy
templates.
Template categories include:
• Regulatory Compliance. These templates identify messages and attachments that contain personally
identifiable information, credit information, or other protected or non-public information.
• Acceptable Use. These templates identify messages sent to competitors or restricted recipients that
contain sensitive information about an organization.
• Privacy Protection. These templates identify messages and attachments that contain identification
numbers for financial accounts, tax records, or national IDs.
• Intellectual Property Protection. These templates identify popular publishing and design document
file types that may contain intellectual property that an organization would want to protect.
• Company Confidential. These templates identify documents and messages that contain information
about corporate accounting information and upcoming mergers and acquisitions.
• Custom Policy. This “template” lets you create your own policy from scratch using either pre-defined
content matching classifiers or violation identification criteria specified by your organization. This option
is considered advanced and should be used only in the rare cases when the predefined policy templates
do not meet the unique requirements of your network environment.
Some of these templates require customization.
Setting Up DLP Prevention Using a Wizard
The DLP Assessment Wizard helps you configure commonly-used DLP policies and enable them in the email
gateway's default outgoing mail policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
513
Data Loss Prevention
Setting Up DLP Prevention Using a Wizard
Note By default, DLP policies added using the DLP Assessment Wizard deliver all messages, regardless of the
severity of detected DLP violations. You will need to edit the policies created using the wizard.
Before You Begin
• Remove any existing DLP policies from the email gateway. You can only use the DLP Assessment
Wizard if there are no existing DLP policies on the email gateway.
• If you need to detect messages that include student identification numbers or account numbers other than
credit card numbers, US Social Security numbers, and US Drivers License numbers, create a regular
expression that identifies those numbers. For more information, see Regular Expressions for Identifying
Identification Numbers , on page 521.
Procedure
Step 1 Choose Security Services > Data Loss Prevention.
Step 2 Click Edit Settings.
Step 3 Select the Enable and configure DLP using the DLP Assessment Wizard check box.
Step 4 Click Submit.
Step 5 Complete the wizard.
Keep the following in mind:
• Any business that operates in California and owns or licenses computerized personally identifying
information (PII) data for California residents, regardless of their physical location, is required to comply
with US State Regulations (California SB-1386). This law is one of the policy choices in the wizard.
• If you do not enter an email address to receive automatically-generated scheduled DLP Incident Summary
report, the report will not be generated.
• When you review your configured settings, if you return to a step to make a change, you must proceed
through the remaining steps until you reach the review page again. All settings that you previously entered
will be remembered.
• When you complete the wizard, the Outgoing Mail Policies page displays, with your DLP policies enabled
in the default outgoing mail policy. A summary of your DLP policy configuration is displayed at the top
of the page.
Step 6 Commit your changes.
What to do next
• (Optional) To edit these DLP policies, create additional policies, change the overall action on messages,
or change the severity level settings, choose Mail Policies > DLP Policy Manager. For information,
see Creating a DLP Policy Using a Predefined Template , on page 515, Creating a Custom DLP Policy
(Advanced) , on page 516, and Adjusting the Severity Scale , on page 528.
• (Optional) To enable existing DLP policies for other outgoing mail policies, see Using Outgoing Mail
Policies to Assign DLP Policies to Senders and Recipients , on page 529.
Related Topics
• Creating a DLP Policy Using a Predefined Template , on page 515
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
514
Data Loss Prevention
Creating a DLP Policy Using a Predefined Template
• Creating a Custom DLP Policy (Advanced) , on page 516
Creating a DLP Policy Using a Predefined Template
Procedure
Step 1 Select Mail Policies > DLP Policy Manager.
Step 2 Click Add DLP Policy.
Step 3 Click the name of a category to display a list of the available DLP policy templates.
Note To view descriptions of each template, click Display Policy Descriptions.
Step 4 Click Add for the DLP policy template that you want to use.
Step 5 (Optional) Change the predefined name and description of the template.
Step 6 If the policy requires or recommends customizing one or more content matching classifiers, enter a regular
expression to define the pattern of your organization’s identification numbering system and a list of words or
phrases related to the identification numbers that identify them as such or are typically associated with them.
For information, see:
About Defining Disallowed Content Using Content Matching Classifiers , on page 517and Regular Expressions
for Identifying Identification Numbers , on page 521.
Note You cannot add or remove content matching classifiers for policies based on a predefined template.
Step 7 (Optional) Apply the DLP policy only to messages with specific recipients, senders, attachment types, or
previously-added message tags.
For more information, see Filtering Messages for DLP Policies, on page 527.
You can separate multiple entries using a line break or a comma.
Step 8 In the Severity Settings section:
• Choose an action to take for each level of violation severity.For more information, see About Assessing
Violation Severity , on page 528.
• (Optional) Click Edit Scale to adjust the violation severity scale for the policy. For more information,
see Adjusting the Severity Scale , on page 528.
Step 9 Submit and commit your changes.
What to do next
Related Topics
• Setting Up DLP Prevention Using a Wizard , on page 513
• Creating a Custom DLP Policy (Advanced) , on page 516
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
515
Data Loss Prevention
Creating a Custom DLP Policy (Advanced)
Creating a Custom DLP Policy (Advanced)
Note Creating custom policies is very complex; create custom policies only if the predefined DLP policy templates
do not meet the needs of your organization.
You can create a custom DLP policy from scratch using the Custom Policy template and add either a predefined
content matching classifier or a custom classifier to the policy.
Custom policies can return a DLP violation if the content matches a single classifier or all classifiers, depending
on how the policy is defined.
Before You Begin
Suggested: Define the criteria that identify a content violation. See Creating a Content Matching Classifier
for Custom DLP Policies , on page 519. You can also define these criteria from within this procedure.
Procedure
Step 1 Select Mail Policies > DLP Policy Manager.
Step 2 Click Add DLP Policy.
Step 3 Click Custom Policy.
Step 4 Click Add for the Custom Policy template.
Step 5 Enter a name and description for the policy.
Step 6 Identify the content and context that constitute a DLP violation:
a) Select a content matching classifier.
b) Click Add.
• If you selected Create a Classifier, see Creating a Content Matching Classifier for Custom DLP
Policies , on page 519 .
• Otherwise, the selected classifier is added to the table.
c) (Optional) Add additional classifiers to the policy.
For example, you might be able to eliminate known likely false positive matches by adding another
classifier and selecting NOT.
d) If you added multiple classifiers: Choose an option in the table heading to specify whether any or all of
the classifiers must match in order to count the instance as a violation.
Step 7 (Optional) Apply the DLP policy only to messages with specific recipients, senders, attachment types, or
previously-added message tags.
For more information, see Filtering Messages for DLP Policies, on page 527.
You can separate multiple entries using a line break or a comma.
Step 8 In the Severity Settings section:
• Choose an action to take for each level of violation severity. For more information, see About Assessing
Violation Severity , on page 528.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
516
Data Loss Prevention
About Defining Disallowed Content Using Content Matching Classifiers
• (Optional) Click Edit Scale to adjust the violation severity scale for the policy. For more information,
see Adjusting the Severity Scale , on page 528
Step 9 Submit and commit your changes.
What to do next
Related Topics
• Setting Up DLP Prevention Using a Wizard , on page 513
• Creating a DLP Policy Using a Predefined Template , on page 515
About Defining Disallowed Content Using Content Matching Classifiers
Content matching classifiers define the content that cannot be emailed and optionally the context in which
that content must occur in order to be considered a data loss prevention violation.
Suppose you want to prevent patient identification numbers from being emailed from your organization.
In order for the email gateway to recognize these numbers, you must specify the patterns of the record
numbering system used by your organization, using one or more regular expressions. You can also add a list
of words and phrases that might accompany the record number as supporting information. If the classifier
detects the number pattern in an outgoing message, it searches for the supporting information to verify that
the pattern is an identification number and not a random number string. Including context matching information
results in fewer false positive matches.
For this example, you might create a DLP policy that uses the HIPAA and HITECH template. This template
includes the Patient Identification Numbers content matching classifier, which you can customize to detect a
patient’s identification number. To detect numbers in the pattern of 123-CL456789, you would enter the
regular expression [0-9]{3}\-[A-Z]{2}[0-9]{6} for the classifier. Enter “Patient ID” for a related phrase.
Finish creating the policy and enable it in an outgoing mail policy. Submit and commit your changes. Now,
if the policy detects the number pattern in an outgoing message with the phrase “Patient ID” in close proximity
to the number pattern, the DLP policy returns a DLP violation.
About Using Content Matching Classifiers in DLP Policies
Many of the predefined DLP policy templates include content matching classifiers. Some of these classifiers
require customization in order to identify the patterns that are used for data in your organization.
If you create a custom DLP policy you can choose a predefined classifier or create one of your own.
Related Topics
• Content Matching Classifier Examples, on page 518
• Creating a Content Matching Classifier for Custom DLP Policies , on page 519
• Classifier Detection Rules for Identifying Sensitive Content (Custom DLP Policies Only) , on page 520
• Regular Expressions for Identifying Identification Numbers , on page 521
• Using Custom Dictionaries of Sensitive DLP Terms (Custom DLP Policies Only) , on page 522
• Determiners of the Risk Factor of a Suspected Violation , on page 524
• Viewing the Policies in Which Custom Content Classifiers are Used , on page 527
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
517
Data Loss Prevention
Content Matching Classifier Examples
Content Matching Classifier Examples
The following examples show how classifiers match message content:
• Credit Card Number, on page 518
• US Social Security Number, on page 518
• ABA Routing Numbers, on page 518
• Driver License Numbers (US) , on page 518
• National Provider IDs (US), on page 519
• Academic Records (English), on page 519
• Financial Statements (English), on page 519
Credit Card Number
Several DLP policy templates include the Credit Card Number classifier. The credit card number itself is
subject to various constraints, such as the pattern of digits and punctuation, the issuer-specific prefix, and the
final check digit. The classifier requires additional supporting information to make a match, such as an
expiration date, or the name of the card issuer. This reduces the number of false positives.
Examples:
• 378734493671000 (No match because of no supporting information)
• 378734493671000 VISA (Match)
• 378734493671000 exp: 12/2019 (Match)
US Social Security Number
The US Social Security Number classifier requires a properly formatted number as well as supporting data,
such as a date of birth, name, or the string SSN .
Examples:
• 321-02-3456 (No match because of no supporting information)
• SSN: 132-45-6788 (Match)
ABA Routing Numbers
The ABA Routing Number classifier is similar to the Credit Card Number classifier.
Examples:
• 119999992 (No match because of no supporting information)
• ABA No. 800000080 (Match)
Driver License Numbers (US)
Many policies use a US Drivers License classifier. By default, this classifier searches for drivers licenses
issued in the US. US state-specific policies such as California AB-1298 and Montana HB-732 search for their
respective state US drivers' licenses only.
The individual state classifiers match against the patterns for that state, and require the corresponding state
name or abbreviation, and additional supporting data.
Examples:
• CA DL# C3452362 (Match because it has the correct pattern for the number and supporting data)
• California DL# C3452362 (Match)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
518
Data Loss Prevention
National Provider IDs (US)
• DL: C3452362 (No match because there is not enough supporting data)
• California C3452362 (No match because there is not enough supporting data)
• OR DL# C3452362 (Match)
• OR DL# 3452362 (Match because it is the correct pattern for Oregon)
• WV DL# D654321 (Match because it is the correct pattern for West Virginia)
• WV DL# G654321 (Match)
National Provider IDs (US)
The US National Provider Identifier classifier scans for a US National Provider Identifier (NPI) numbers,
which is a 10-digit number with a check digit.
Examples:
• NPI No. 1245319599 (Match for NPI)
• NPI No. 1235678996 (Match for NPI)
• 3459872347 (No match because of no supporting information)
• NPI: 3459872342 (No match because of incorrect check digit)
Academic Records (English)
The predefined FERPA (Family Educational Rights and Privacy Act) DLP policy template uses the Student
Records classifier. Combine it with a customized Student Identification Number classifier to detect specific
student ID patterns for better accuracy.
Example:
• Fall Semester Course Numbers: CHEM101, ECON102, MATH103 (Match)
Financial Statements (English)
The predefined Sarbanes-Oxley (SOX) policy template uses the Corporate Financials classifier to search for
non-public corporate financial information.
Example:
Gross Profits, Current Assets, and Cash Flow Statement for the Quarter ended June 30, 2016.
(Match)
Creating a Content Matching Classifier for Custom DLP Policies
Custom classifiers that you create are added to the list of classifiers that you can use when creating custom
DLP policies.
Procedure
Command or Action Purpose
Step 1 Understand how content matching classifiers See:
are used to identify potential DLP violations.
• About Defining Disallowed Content Using
Content Matching Classifiers , on page 517
• Content Matching Classifier Examples, on
page 518
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
519
Data Loss Prevention
Classifier Detection Rules for Identifying Sensitive Content (Custom DLP Policies Only)
Command or Action Purpose
Step 2 Select Mail Policies > DLP Policy —
Customizations and click Add Custom
Classifier. Enter a classifier name and
description.
Step 3 Enter a proximity and a minimum total score. See Determiners of the Risk Factor of a
Suspected Violation , on page 524
Step 4 Choose one of the following detection rule types See:
and define the associated content matching
• Classifier Detection Rules for Identifying
criteria:
Sensitive Content (Custom DLP Policies
• words or phrases Only) , on page 520
• text from a dictionary • Using Custom Dictionaries of Sensitive
• a regular expression, or DLP Terms (Custom DLP Policies Only)
• an existing data loss prevention entity , on page 522
• Regular Expressions for Identifying
Identification Numbers , on page 521
Step 5 (Optional) Add additional rules by clicking Add For information about Weight and Max Score,
Rule. see Determiners of the Risk Factor of a
Suspected Violation , on page 524.
Step 6 If you include multiple rules, specify whether This setting is at the top of the Rules section.
All or Any rules must match.
Step 7 Submit and commit your changes. —
What to do next
Use your custom content classifier in a custom DLP Policy. See Creating a Custom DLP Policy (Advanced)
, on page 516.
Related Topics
• Viewing the Policies in Which Custom Content Classifiers are Used , on page 527
Classifier Detection Rules for Identifying Sensitive Content (Custom DLP Policies Only)
Content matching classifiers require rules for detecting DLP violations in a message or document. Classifiers
can use one or more of the following detection rules:
• Words or Phrases. A list of words and phrases for which the classifier should look. Separate multiple
entries with a comma or line break.
• Regular Expression. A regular expression to define a search pattern for a message or attachment. You
can also define a pattern to exclude from matching to prevent false positives. See Regular Expressions
for Identifying Identification Numbers , on page 521and Examples of Regular Expressions for Identifying
Identification Numbers , on page 522for more information.
• Dictionary. A dictionary of related words and phrases. Your email gateway includes pre-defined
dictionaries, or you can create your own. See Using Custom Dictionaries of Sensitive DLP Terms (Custom
DLP Policies Only) , on page 522.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
520
Data Loss Prevention
Regular Expressions for Identifying Identification Numbers
• Entity. A predefined pattern that identifies common types of sensitive data, such as credit card numbers,
addresses, social security numbers, or ABA routing numbers. For descriptions of the entities, go to Mail
Policies > DLP Policy Manager, click Add DLP Policy, click Privacy Protection, then click Display
Policy Descriptions.
Regular Expressions for Identifying Identification Numbers
Some policy templates require customization of one or more content matching classifiers, which involves
creating a regular expression to search for identification numbers that may be linked to confidential information,
such as a custom account number, patient identification number or Student ID. You can use the Perl
Compatible Regular Expression (PCRE2) syntax to add regular expressions for content matching classifiers
or the DLP policy templates. The regular expressions are validated for PCRE2 compatibility only when the
DLP feature is enabled on your email gateway.
Note Regular expressions are case sensitive, so they should include upper and lower case, such as [a-zA-Z] . If
only certain letters are used, you can define the regular expression accordingly.
The less specific the pattern, such as an 8-digit number, the more likely you will want the policy to search for
additional words and phrases to distinguish a random 8-digit number from an actual customer number.
Use the following table as a guide for creating regular expressions for classifiers:
Element Description
Regular expression ( abc ) Regular expressions for classifiers match a string if the sequence of
directives in the regular expression match any part of the string.
For example, the regular expression ACC matches the string ACCOUNT
as well as ACCT .
[] Use brackets to indicate a set of characters. Characters can defined
individually or within a range.
For example, [a-z] matches all lowercase letters from a to z , while
[a-zA-Z] matches all uppercase and lowercase letters from A to Z
. [xyz] matches only the letters x , y , or z .
Backslash special characters ( \ ) The backslash character escapes special characters. Thus the sequence
\. only matches a literal period, the sequence \$ only matches a literal
dollar sign, and the sequence \^ only matches a literal caret symbol.
The backslash character also begins tokens, such as \d .
Important Note: The backslash is also a special escape character for
the parser. As a result, if you want to include a backslash in your
regular expression, you must use two backslashes — so that after
parsing, only one “real” backslash remains, which is then passed to
the regular expression system.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
521
Data Loss Prevention
Examples of Regular Expressions for Identifying Identification Numbers
Element Description
\d Token that matches a digit ( 0 - 9 ). To match more than one digit,
enter an integer in {} to define the length of the number.
For example, \d matches only a single digit such as 5 , but not 55 .
Using \d{2} matches a number consisting of two digits, such as 55 ,
but not 5 .
\D Token that matches any non-digit character. To match more than one
non-digit character, enter an integer in {} to define the length.
\w Token that matches any alphanumeric character and the underscore (
a - z , A - Z , 0 - 9 , and _ ).
Number of repetitions {min,max} The regular expression notation that indicates the number of repetitions
of the previous token is supported.
For example, the expression “ \d{8} ” matches 12345678 and
11223344 but not 8 .
Or ( | ) Alternation, or the “or” operator. If A and B are regular expressions,
the expression “ A|B ” will match any string that matches either “A”
or “B.” Can be used to combine number patterns in a regular
expression.
For example, the expression “ foo|bar ” will match either foo or bar ,
but not foobar .
Related Topics
• Examples of Regular Expressions for Identifying Identification Numbers , on page 522
Examples of Regular Expressions for Identifying Identification Numbers
Simple regular expressions that describe patterns of numbers and letters in identification or account numbers
might look like the following:
• An 8-digit number: \d{8}
• Identification code with hyphens between sets of numbers: \d{3}-\d{4}-\d
• Identification code that begins with a single letter that can be upper or lower case: [a-zA-Z]\d{7}
• Identification code that begins with three digits and is followed by nine uppercase letters: \d{3}[A-Z]{9}
• Using | to define two different number patterns to search for: \d{3}[A-Z]{9}|\d{2}[A-Z]{9}-\d
Using Custom Dictionaries of Sensitive DLP Terms (Custom DLP Policies Only)
AsyncOS comes with a set of predefined dictionaries, but you can also create custom DLP dictionaries to
specify terms for the DLP scanning feature to match.
You can create a custom DLP dictionary in several ways:
• Adding Custom DLP Dictionaries Directly , on page 523
• Creating DLP Dictionaries as Text Files , on page 523and then Importing DLP Dictionaries , on page 523.
• Exporting DLP Dictionaries , on page 523 from another email gateway and then Importing DLP Dictionaries
, on page 523.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
522
Data Loss Prevention
Adding Custom DLP Dictionaries Directly
Adding Custom DLP Dictionaries Directly
Procedure
Step 1 Select Mail Policies > DLP Policy Manager.
Step 2 In the Advanced Settings section, click the link beside Custom DLP Dictionaries.
Step 3 Click Add Dictionary.
Step 4 Enter a name for the custom dictionary.
Step 5 Enter new dictionary entries (words and phrases) into the list of terms.
Dictionary terms are case-sensitive and can contain non-ASCII characters.
When entering multiple entries, separate the entries with line breaks.
Step 6 Click Add.
Step 7 Submit and commit your changes.
Creating DLP Dictionaries as Text Files
You can create your own dictionary as a text file on your local machine and import it onto the email gateway.
Use line breaks for each term in the dictionary text file. Dictionary terms are case-sensitive and can contain
non-ASCII characters.
Exporting DLP Dictionaries
Note Predefined DLP dictionaries cannot be exported.
Procedure
Step 1 Select Mail Policies > DLP Policy Manager.
Step 2 Click the link for the Custom DLP Dictionaries section under Advanced Settings.
Step 3 Click Export Dictionary.
Step 4 Select a dictionary to export.
Step 5 Enter a file name for the dictionary.
Step 6 Choose where to save the exported dictionary, either on your local computer or in the configuration directory
on the email gateway.
Step 7 Select an encoding for the file.
Step 8 Click Submit and save the file.
Importing DLP Dictionaries
Before You Begin
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
523
Data Loss Prevention
Determiners of the Risk Factor of a Suspected Violation
If you will import a file that you exported from a non-DLP dictionary on an email gateway, you must first
strip the weight values from the text file and convert any regular expressions to words or phrases.
Procedure
Step 1 Select Mail Policies > DLP Policy Manager.
Step 2 In the Advanced Settings section, click the link beside Custom DLP Dictionaries.
Step 3 Click Import Dictionary.
Step 4 Select a file to import from either your local machine or the configuration directory on the email gateway.
Step 5 Select an encoding.
Step 6 Click Next.
A “Success” message appears and the imported dictionary is displayed in the Add Dictionary page. However,
the process is not yet complete.
Step 7 Name and edit the dictionary.
Step 8 Click Submit.
Determiners of the Risk Factor of a Suspected Violation
When the email gateway scans a message for DLP violations, it assigns a risk factor score to the message.
This score indicates the likelihood that the message contains a DLP violation. A score of 0 means the message
almost certainly does not contain a violation. A score of 100 means it almost certainly does contain a violation.
For DLP Policies Based On Predefined Templates
You cannot view or modify risk factor scoring parameters for DLP policies created from predefined templates.
However, if there are too many false positive matches for a particular DLP policy, you can adjust the severity
scale for that policy. See About Assessing Violation Severity , on page 528. For policies based on templates
that do not have a content matching classifier, such as the SOX (Sarbanes-Oxley) template, the scanning
engine always returns a risk factor value of “75” when a message violates the policy.
For Custom DLP Policies
When you create content matching classifiers for custom DLP policies, you specify values that are used to
determine the risk factor score:
• Proximity. How close the rule matches must occur in the message or attachment to count as a violation.
For example, if a numeric pattern similar to a social security number appears near the top of a long
message and an address appears in the sender’s signature at the bottom, they are presumed to be unrelated
and the data does not count as a match.
• Minimum Total Score. The minimum risk factor score required for sensitive content to be labeled a
DLP violation. If the score of a message’s matches does not meet the minimum total score, its data is
not considered sensitive.
• Weight. For each custom rule you create, you specify a “weight” to indicate the importance of the rule.
A score is obtained by multiplying the number of detection rule matches by the weight of the rule. Two
instances of a rule with a weight of 10 results in a score of 20 . If one rule is more important for the
classifier than the others, it should be assigned a greater weight.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
524
Data Loss Prevention
Determiners of the Risk Factor of a Suspected Violation
• Maximum Score. A rule’s maximum score prevents a large number of matches for a low-weight rule
from skewing the final score of the scan.
• Minimum Score. You can use the recommended minimum score or choose to use the weight depending
on the Use recommended minimum scores for entity-based rules check box selected in the Custom
Classifiers Settings section of the DLP Policy Customizations page. For more information, see Using
Minimum Score for Entity-based Rules (Custom DLP Policies Only), on page 526
To calculate the risk factor, the classifier multiplies the number of matches for a detection rule by the weight
of the rule. If this value exceeds the detection rule’s maximum score, the classifier uses the maximum score
value. If the classifier has more than one detection rule, it adds the scores for all of its detection rules into a
single value. The classifier maps the detection rules score (10 - 10000) on a scale of 10 -100 using the
logarithmic scale shown in the following table to create the risk factor:
Table 42: How Risk Factor Scores Are Calculated From Detection Rule Scores
Rule Scores Risk Factor
0 0
1 1
2 2
3 3
5 6
6 7
7 8
8 9
9 10
10 11
15 16
20 20
25 24
30 26
40 32
50 36
75 44
100 50
125 54
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
525
Data Loss Prevention
Using Minimum Score for Entity-based Rules (Custom DLP Policies Only)
Rule Scores Risk Factor
150 58
257 67
300 70
400 75
500 78
750 84
1000 87
5000 98
8000 99
10000 99
20000 100
Using Minimum Score for Entity-based Rules (Custom DLP Policies Only)
Procedure
Step 1 Go to Mail Policies > DLP Policy Customizations.
Step 2 In the Custom Classifiers Settings section, select the Use recommended minimum scores for entity-based
rules check box.
If you select this option, the score for the entity-based rule is calculated using the configured minimum score
instead of the weight.
For example, when you disable this option and a message has five rule matches of a certain entity with the
weight configured as 10, the rule calculates the score as five matches times 10 occurrences, which is 50. If
you enable this option with a minimum score for an entity as 10, the score is calculated based on the configured
minimum score and the number of partial and full matches.
Note You must review the minimum total score of all the classifiers with entity-based rules when you
select the Use recommended minimum scores for entity-based rules option.
Step 3 Click Submit and commit your changes.
After you enable this option, you must review the minimum scores for entity-based rules of a custom classifier.
For more information, see Creating a Content Matching Classifier for Custom DLP Policies , on page 519.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
526
Data Loss Prevention
Viewing the Policies in Which Custom Content Classifiers are Used
Viewing the Policies in Which Custom Content Classifiers are Used
Procedure
Step 1 Select Mail Policies > DLP Policy Customizations.
Step 2 In the Custom Classifiers section, click the Policies link in the heading of the Custom Classifiers table.
What to do next
Related Topics
• Creating a Content Matching Classifier for Custom DLP Policies , on page 519
Filtering Messages for DLP Policies
To improve performance or accuracy, you can limit a DLP policy to apply only to certain messages based on
the following criteria:
Option Description
Filtering by Senders and You can limit the DLP policy to apply to messages that do or do not include
Recipients recipients or senders that you specify using one of the following:
• Full email address: [email protected]
• Partial email address: user@
• All users in a domain: @example.com
• All users in a partial domain: @.example.com
Separate multiple entries using a line break or a comma.
AsyncOS first matches the recipient or sender of an outgoing message to an
outgoing mail policy, then matches the sender or recipient to the sender and
recipient filters specified in the DLP policies enabled for that mail policy.
For example, you might want to disallow all senders from sending a certain
type of information, except to recipients in a partner domain. You would create
a DLP policy for that information, including a filter that exempts all users in
the partner domain, then include this DLP policy in an Outgoing Mail Policy
that applies to all senders.
Filtering by Attachment You can limit the DLP policy to scanning only messages that do or do not
Types include specific attachment types. Choose an attachment category, then a
predefined file type, or specify file types that are not listed. If you specify a
file type that is not predefined, AsyncOS searches for the file type based on
the attachment’s extension.
You can also limit DLP scanning to attachments with a minimum file size.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
527
Data Loss Prevention
About Assessing Violation Severity
Option Description
Filtering by Message Tag If you want to limit a DLP policy to messages containing a specific phrase,
you can use a message or content filter to search outgoing messages for the
phrase and insert a custom message tag into the message. For more information,
see Content Filter Actions, on page 290and Using Message Filters to Enforce
Email Policies, on page 139
About Assessing Violation Severity
When the DLP scanning engine detects a potential DLP violation, it calculates a risk factor score that represents
the likelihood that the instance actually is a DLP violation. The policy compares the risk factor score to the
Severity Scale defined in that policy in order to determine the severity level (for example, Low or Critical.)
You specify the action to take for violations at each severity level (except Ignore, for which no action is ever
taken.) You can adjust the risk factor scores required to reach each severity level.
Related Topics
• Adjusting the Severity Scale , on page 528
Adjusting the Severity Scale
All policies have a default severity scale. You can adjust this scale for each policy.
For example, by default, a violation has a severity level of Critical if its risk factor score is between 90 and
100. However, for violations that match a particular policy, you may want increased sensitivity to potential
data loss. For this DLP policy, you could change the Critical severity level to any violation with a risk factor
score between 75 and 100.
Procedure
Step 1 Select Mail Policies > DLP Policy Manager.
Step 2 Click the name of the policy to edit.
Step 3 In the Severity Settings section, click Edit Scale.
Step 4 Use the scale’s arrows to adjust the scores for the severity levels.
Step 5 Click Done.
Step 6 In the Severity Scale table, verify that your scores are as you want them.
Step 7 Click Submit.
What to do next
Related Topics
• About Assessing Violation Severity , on page 528
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
528
Data Loss Prevention
Arranging the Order of the Email DLP Policies for Violation Matching
Arranging the Order of the Email DLP Policies for Violation Matching
If a DLP violation matches more than one of the DLP policies enabled in the outgoing mail policy, only the
first matching DLP policy in the list is used.
Procedure
Step 1 On the DLP Policy Manager page, click Edit Policy Order.
Step 2 Click on the row for a policy you want to move and drag it to a new position in the order.
Step 3 Once you have finished reordering the policies, submit and commit your changes.
Associating DLP Policies with Outgoing Mail Policies
Related Topics
• Associating DLP Policies with the Default Outgoing Mail Policy , on page 529
• Using Outgoing Mail Policies to Assign DLP Policies to Senders and Recipients , on page 529
Associating DLP Policies with the Default Outgoing Mail Policy
The default outgoing mail policy is used when no other outgoing mail policy matches the sender or a recipient.
Before You Begin
Complete all activities up to this point in the table in How to Set Up Data Loss Prevention , on page 511. For
example, ensure that you have created the DLP policies that you want to include in the default Outgoing Mail
Policy.
Procedure
Step 1 Choose Mail Policies > Outgoing Mail Policies.
Step 2 In the Default Policy row of the table, click the Disabled link in the DLP column.
Step 3 Select Enable DLP (Customize Settings).
Step 4 Select the DLP policies to enable for the default outgoing mail policy.
Step 5 Submit and commit your changes.
What to do next
Choose the DLP policies for additional Outgoing Mail Policies. See Using Outgoing Mail Policies to Assign
DLP Policies to Senders and Recipients , on page 529.
Using Outgoing Mail Policies to Assign DLP Policies to Senders and Recipients
Specify which DLP policies apply to which senders and recipients by enabling them in outgoing mail policies.
You can use DLP policies only in outgoing mail policies.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
529
Data Loss Prevention
Important Information About Editing or Deleting DLP Policies
Before You Begin
Configure the DLP policy settings for the default Outgoing Mail policy. See Associating DLP Policies with
the Default Outgoing Mail Policy , on page 529.
Procedure
Step 1 Choose Mail Policies > Outgoing Mail Policies.
Step 2 Click the link in the DLP column in any row of the table.
Step 3 Select the DLP policies to associate with this outgoing mail policy.
Step 4 Submit your changes.
Step 5 Repeat as needed for other Outgoing Mail Policies.
Step 6 Commit your changes.
What to do next
See How to Set Up Data Loss Prevention , on page 511.
Important Information About Editing or Deleting DLP Policies
Action Information
Editing a DLP policy If you rename a policy, you must re-enable it in your outgoing mail policies.
Deleting a DLP policy If you delete a policy, you will receive a notification if the DLP policy is used in
one or more outgoing mail policies. Deleting a DLP policy removes it from these
mail policies.
Message Actions
You specify primary and secondary actions that the email gateway will take when it detects a possible DLP
violation in an outgoing message. Different actions can be assigned for different violation types and severities.
Primary actions include:
• Deliver
• Drop
• Quarantine
Secondary actions include:
• Sending a copy to a policy quarantine if you choose to deliver the message. The copy is a perfect clone
of the original, including the Message ID. Quarantining a copy allows you to test the DLP system before
deployment in addition to providing another way to monitor DLP violations. When you release the copy
from the quarantine, the email gateway delivers the copy to the recipient, who will have already received
the original message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
530
Data Loss Prevention
Defining Actions to Take for DLP Violations (Message Actions)
• Encrypting messages. The email gateway only encrypts the message body. It does not encrypt the message
headers.
• Altering the subject header of messages containing a DLP violation.
• Adding disclaimer text to messages.
• Sending messages to an alternate destination mailhost.
• Sending copies (bcc) of messages to other recipients. (For example, you could copy messages with critical
DLP violations to a compliance officer’s mailbox for examination.)
• Sending a DLP violation notification message to the sender or other contacts, such as a manager or DLP
compliance officer. See Drafting DLP Notifications , on page 533.
Note These actions are not mutually exclusive: you can combine some of them within different DLP policies for
various processing needs for different user groups. You can also configure different treatments based on the
different severity levels in the same policy. For example, you may want to quarantine messages with critical
DLP violations and send a notification to a compliance officer, but you may want to deliver messages with
low severity levels.
Related Topics
• Defining Actions to Take for DLP Violations (Message Actions) , on page 531
• Viewing and Editing Message Actions , on page 532
• Drafting DLP Notifications , on page 533
Defining Actions to Take for DLP Violations (Message Actions)
Before You Begin
• Create at least one dedicated quarantine to hold messages (or copies of messages) that violate DLP
policies.
This can be a local quarantine on an email gateway or a centralized quarantine on a Cisco Secure Email
and Web Manager.
For information, see Policy, Virus, and Outbreak Quarantines, on page 927
• If you want to encrypt messages before delivery, make sure you have set up an encryption profile. See
Cisco Email Encryption, on page 539
• To include disclaimer text when delivering messages with DLP violations or suspected violations, specify
disclaimer text in Mail Policies > Text Resources. For information, see Disclaimer Template, on page
655
• To send a notification to the sender of a DLP violation or to another person such as a compliance officer,
first create the DLP notification template. See Drafting DLP Notifications , on page 533.
Procedure
Step 1 Select Mail Policies > DLP Policy Customizations.
Step 2 In the Message Actions section, click Add Message Action.
Step 3 Enter a name for the message action.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
531
Data Loss Prevention
Viewing and Editing Message Actions
Step 4 Enter a description of the message action.
Step 5 Choose whether to drop, deliver, or quarantine messages containing DLP violations.
Note If you select Deliver, you can choose to have a copy of the message sent to a policy quarantine. The
copy of the message is a perfect clone, including the Message ID.
Step 6 If you want to encrypt the message upon delivery or its release from quarantine, select the Enable Encryption
check box and select the following options:
• Encryption Rule. Always encrypts the message or only encrypt it if an attempt to send it over a TLS
connection first fails.
• Encryption Profile. Encrypts the message using the specified encryption profile and delivers it if you
use a Cisco IronPort Encryption Appliance or a hosted key service.
• Encrypted Message Subject. Subject for the encrypted message. Use the value is $Subject to keep
the existing message subject.
Step 7 If you select Quarantine as the action, choose the policy quarantine that you want to use for messages containing
DLP violations.
Step 8 Click Advanced if you want to modify the message using any of the following options:
• Add a custom header
• Modify the message subject
• Deliver it to alternate host
• Send a copy (bcc) to another recipient
• Send a DLP notification message
Step 9 Submit and commit your changes.
Viewing and Editing Message Actions
Procedure
Step 1 Select Mail Policies > DLP Policy Customizations.
Step 2 In the Message Actions section, choose an action:
To Do This
View the mail policies to which each action is Click the Policies link in the heading of the Message
assigned Actions table.
View the description that you entered for each Click the Description link in the heading of the Message
action Actions table.
View or edit details of a Message Action Click the name of the Message Action.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
532
Data Loss Prevention
Drafting DLP Notifications
To Do This
Delete a Message Action Click the trash can icon next to the message action you
want to delete.
A confirmation message notifies you if the message
action is used in one or more DLP policies.
Duplicate a Message Action Click the Duplicate icon next to the message action that
you want to duplicate.
You can use this feature to create a backup copy of
a Message Action before changing it, or to use as
a starting point for a new, similar Message Action.
Step 3 Submit and commit any changes.
Drafting DLP Notifications
Use this procedure to create a template for the notification that will be sent when an email message contains
information that violates your organization’s data loss prevention policies. You can send this notification to
the sender of the message that violated DLP policy, or to another address, for example a manager or DLP
Compliance officer.
Before You Begin
• Familiarize yourself with the DLP Notification Template Variable Definitions, on page 534. You can use
these variables to customize the notification with specific details about each violation.
Procedure
Step 1 Select Mail Policies > Text Resources.
Step 2 Click Add Text Resource.
Step 3 For Type, select DLP Notification Template.
DLP variables are not available for the plain Notification template.
Step 4 Enter notification text and variables.
The notification should inform its recipients that an outgoing message may contain sensitive data that violates
your organization’s data loss prevention policies.
What to do next
Specify this DLP notification template in a Message Action in a DLP policy in the DLP Policy Manager.
Related Topics
• DLP Notification Template Variable Definitions, on page 534
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
533
Data Loss Prevention
DLP Notification Template Variable Definitions
DLP Notification Template Variable Definitions
Use the following variables to include specific information about each DLP violation in the notification.
Variable Substituted With
$DLPPolicy Replaced by the name of the email DLP policy violated.
$DLPSeverity Replaced by the severity of violation. Can be “Low,” “Medium,” “High,” or “Critical.”
$DLPRiskFactor Replaced by the risk factor of the message’s sensitive material (score 0 - 100).
$To Replaced by the message To: header (not the Envelope Recipient).
$From Replaced by the message From: header (not the Envelope Sender).
$Subject Replaced by the subject of the original message.
$Date Replaced by the current date, using the format MM/DD/YYYY.
$Time Replaced by the current time, in the local time zone.
$GMTimestamp Replaced by the current time and date, as would be found in the Received: line of an
email message, using GMT.
$MID Replaced by the Message ID, or “MID” used internally to identify the message. Not
to be confused with the RFC822 “Message-Id” value (use $Header to retrieve that).
$Group Replaced by the name of the sender group the sender matched on when injecting the
message. If the sender group had no name, the string “>Unknown<” is inserted.
$Reputation Replaced by the IP Reputation score of the sender. If there is no reputation score, it is
replaced with “None”.
$filenames Replaced with a comma-separated list of the message’s attachments’ filenames.
$filetypes Replaced with a comma-separated list of the message's attachments' file types.
$filesizes Replaced with a comma-separated list of the message’s attachment’s file sizes.
$remotehost Replaced by the hostname of the system that sent the message to the Cisco appliance.
$AllHeaders Replaced by the message headers.
$EnvelopeFrom Replaced by the Envelope Sender (Envelope From, <MAIL FROM>) of the message.
$Hostname Replaced by the hostname of the email gateway.
$bodysize Replaced by the size, in bytes, of the message.
$header[‘string ’] Replaced by the value of the quoted header, if the original message contains a matching
header. Note that double quotes may also be used.
$remoteip Replaced by the IP address of the system that sent the message to the email gateway.
$recvlistener Replaced by the nickname of the listener that received the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
534
Data Loss Prevention
Displaying Sensitive DLP Data in Message Tracking
Variable Substituted With
$dropped_filenames Same as $filenames , but displays list of dropped files.
$dropped_filename Returns only the most recently dropped filename.
$recvint Replaced by the nickname of the interface that received the message.
$timestamp Replaced by the current time and date, as would be found in the Received: line of an
email message, in the local time zone.
$Time Replaced by the current time, in the local time zone.
$orgid Replaced by the SenderBase Organization ID (an integer value).
$enveloperecipients Replaced by all Envelope Recipients (Envelope To, <RCPT TO>) of the message.
$dropped_filetypes Same as $filetypes , but displays list of dropped file types.
$dropped_filetype Returns only the file type of the most recently dropped file.
Displaying Sensitive DLP Data in Message Tracking
DLP deployment offers the option to log the content that violates your DLP policies, along with the surrounding
content, which can then be viewed in Message Tracking. This content may include sensitive data such as
credit card numbers and social security numbers.
Before You Begin
Enable Message Tracking. See Enabling Message Tracking, on page 915
Procedure
Step 1 Select Security Services > Data Loss Prevention.
Step 2 Click Edit Settings.
Step 3 Select the Enable Matched Content Logging check box.
Step 4 Submit and commit your changes.
What to do next
Specify which administrative users can view this information. See Controlling Access to Sensitive Information
in Message Tracking, on page 981.
Related Topics
• Message Tracking Details , on page 922
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
535
Data Loss Prevention
About Updating the DLP Engine and Content Matching Classifiers
About Updating the DLP Engine and Content Matching
Classifiers
Updates for the Cisco DLP engine and the predefined content matching classifiers on your email gateway are
independent of updates for other security services.
Related Topics
• Determining the Current Version of the DLP Engine , on page 536
• Updating the DLP Engine and Content Matching Classifiers Manually , on page 536
• Enabling Automatic Updates (Not Recommended) , on page 537
• DLP Updates on Centralized (Clustered) Email Gateways , on page 537
Determining the Current Version of the DLP Engine
Procedure
Step 1 Select Security Services > Data Loss Prevention.
Step 2 Look in the Current DLP Version Files section.
Note You can also use the dlpstatus CLI command to view the current version of the DLP engine. See
the CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway for more information.
Updating the DLP Engine and Content Matching Classifiers Manually
Before you Begin
See the following:
• (If applicable) DLP Updates on Centralized (Clustered) Email Gateways , on page 537
Procedure
Step 1 Select Security Services > Data Loss Prevention.
Step 2 Click Update Now in the Current DLP Version Files section.
This button is available only when there are new updates available for download.
Note You can also use the dlpupdate CLI command to update the DLP engine. See the CLI Reference
Guide for AsyncOS for Cisco Secure Email Gateway for more information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
536
Data Loss Prevention
Enabling Automatic Updates (Not Recommended)
Enabling Automatic Updates (Not Recommended)
Use this procedure to enable the email gateway to check for and download updates at a regular interval.
Note Cisco recommends that you do not enable automatic updates. These updates may change the content matching
classifiers used in your DLP policies. Instead, manually download DLP updates and test them in a lab
environment before updating email gateways used in production.
Before You Begin
• On the Security Settings > Service Updates page, make sure you have enabled automatic updates and
specified an update interval for all service updates.
• See DLP Updates on Centralized (Clustered) Email Gateways , on page 537.
Procedure
Step 1 Select Security Services > Data Loss Prevention.
Step 2 Click Edit Settings.
Step 3 Select the Enable automatic updates check box.
Step 4 Submit and commit your changes.
DLP Updates on Centralized (Clustered) Email Gateways
Note the following:
• You cannot enable automatic DLP updates for email gateways in clustered deployments.
• DLP updates are always performed at the machine level, irrespective of DLP configured at the cluster,
machine or group level.
• You can only check the status of an email gateway's DLP engine using the dlpstatus CLI command
at the machine level.
Working with DLP Incident Messages and Data
Note See also the documentation for the Cisco Secure Email and Web Manager, as applicable to your deployment.
To Do This
Search for messages containing DLP violations using See Tracking Messages, on page 915.
criteria such as DLP policy name, violation severity,
and action taken, and view details of messages found
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
537
Data Loss Prevention
Troubleshooting Data Loss Prevention
To Do This
View or manage messages that have been quarantined See Working with Messages in Policy, Virus, or
as suspected DLP violations Outbreak Quarantines, on page 937.
View a summary of DLP incidents See information about DLP Incident Summary
reports in Using Email Security Monitor, on page
833.
View information about DLP violations discovered in See information about DLP Incident reports in Using
outgoing mail Email Security Monitor, on page 833.
Related Topics
• Displaying Sensitive DLP Data in Message Tracking , on page 535
• Controlling Access to Sensitive Information in Message Tracking, on page 981
Troubleshooting Data Loss Prevention
• DLP Fails to Detect Violations in Email Attachments, on page 538
DLP Fails to Detect Violations in Email Attachments
Problem
When using predefined DLP policies, DLP fails to detect violations in email attachments. This can be caused
by:
• The small value of the proximity parameter in the predefined DLP policies
Note You cannot change the proximity of a predefined DLP policy.
• The high severity scale parameter defined in the predefined DLP policies
Solution
• Create a custom policy and adjust the proximity as required. See Creating a Custom DLP Policy
(Advanced) , on page 516
• Lower the severity scale parameter of the predefined DLP policy. See Adjusting the Severity Scale , on
page 528
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
538
CHAPTER 23
Cisco Email Encryption
This chapter contains the following sections:
• Overview of Cisco Email Encryption, on page 539
• How to Encrypt Messages with a Local Key Server, on page 540
• Encrypting Messages using the Email Gateway, on page 541
• Determining Which Messages to Encrypt, on page 546
• Inserting Encryption Headers into Messages, on page 549
Overview of Cisco Email Encryption
AsyncOS supports using encryption to secure inbound and outbound email. To use this feature, you create
an encryption profile that specifies characteristics of the encrypted message and connectivity information for
the key server. The key server may either be:
• The Cisco Registered Envelope Service (managed service), or
• An Cisco Encryption appliance (locally managed server)
Next, you create content filters, message filters, and Data Loss Prevention policies to determine which messages
to encrypt.
1. An outgoing message that meets the filter condition is placed in a queue on the email gateway for encryption
processing.
2. Once the message is encrypted, the key used to encrypt it is stored on the key server specified in the
encryption profile and the encrypted message is queued for delivery.
3. If a temporary condition exists that prohibits the encryption of emails in the queue (i.e., temporary C-Series
busyness or Cisco Secure Email Encryption Service unavailability), messages are re-queued and retried
at a later time.
Note You can also set up the email gateway to first attempt to send a message over a TLS connection before
encrypting it. For more information, see Using a TLS Connection as an Alternative to Encryption, on page
546.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
539
Cisco Email Encryption
How to Encrypt Messages with a Local Key Server
How to Encrypt Messages with a Local Key Server
Table 43: How to Encrypt Messages with a Local Key Server
Steps Do This More Info
Step 1 Set up the Cisco IronPort Encryption appliance on the network. See Setup and Installation, on page 25
Step 2 Enable message encryption. Enabling Message Encryption on the Email Gateway,
on page 542.
Step 3 Specify the encryption key server to use and the security Configuring How a Key Service Handles Encrypted
settings for the encrypted messages by creating an encryption Messages, on page 542.
profile.
Step 4 Define the conditions that messages must meet in order for Determining Which Messages to Encrypt, on page 546.
the email gateway to encrypt them.
Step 5 Determine when to encrypt messages in the email workflow. • Encrypting and Immediately Delivering Messages
using a Content Filter, on page 547.
or
• Encrypting a Message upon Delivery using a
Content Filter, on page 548.
Step 6 (Optional) Flag messages for additional security. Inserting Encryption Headers into Messages, on page
549.
Step 7 Define groups of users for whom you want to encrypt Create a mail policy.
messages.
See Mail Policies, on page 267
Step 8 Associate the encryption actions that you defined with the Associate the content filter with the mail policy.
user groups you defined.
See Mail Policies, on page 267
Related Topics
• Encryption Workflow, on page 540
Encryption Workflow
When using email encryption, the email gateway encrypts a message and stores the message key on a local
key server or a hosted key service. When the recipient opens an encrypted message, the recipient is authenticated
by the key service, and the decrypted message is displayed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
540
Cisco Email Encryption
Encrypting Messages using the Email Gateway
Figure 34: Encryption Workflow
The basic workflow for opening encrypted messages is:
1. When you configure an encryption profile, you specify the parameters for message encryption. For an
encrypted message, the email gateway creates and stores a message key on a local key server or on the
hosted key service (Cisco Registered Envelope Service).
2. The recipient opens the secure envelope in a browser.
3. When a recipient opens an encrypted message in a browser, a password may be required to authenticate
the recipient’s identity. The key server returns the encryption key associated with the message.
Note When opening an encrypted email message for the first time, the recipient is required to register with the key
service to open the secure envelope. After registering, the recipient may be able to open encrypted messages
without authenticating, depending on settings configured in the encryption profile. The encryption profile
may specify that a password isn’t required, but certain features will be unavailable.
4. The decrypted message is displayed.
Encrypting Messages using the Email Gateway
To use encryption with the email gateway, you must configure an encryption profile. You can enable and
configure an encryption profile using the encryptionconfig CLI command, or via Security Services > Cisco
IronPort Email Encryption in the GUI.
Note If PXE and S/MIME encryption is enabled on the email gateway, AsyncOS encrypts messages using S/MIME
first, and then using PXE.
Related Topics
• Enabling Message Encryption on the Email Gateway, on page 542
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
541
Cisco Email Encryption
Enabling Message Encryption on the Email Gateway
• Configuring How a Key Service Handles Encrypted Messages, on page 542
• Configuring the Default Locale of the Envelope, on page 545
• Updating to the Latest Version of the PXE Engine, on page 546
Enabling Message Encryption on the Email Gateway
Procedure
Step 1 Click Security Services > Cisco IronPort Email Encryption.
Step 2 Click Enable.
Step 3 (Optional) Click Edit Settings to configure the following options:
• The maximum message size to encrypt. Cisco’s recommended message size is 10 MB. The maximum
message size the email gateway will encrypt is 25 MB.
Note Encrypting messages larger than the recommended 10 MB limit may slow down the performance
of the email gateway. If you are using the Cisco Registered Envelope Service, message recipients
will be unable to reply to an encrypted message that has attachments larger than 10 MB.
• Email address of the encryption account administrator. When you provision an Encryption Profile, this
email address is registered automatically with the encryption server.
• Configure a proxy server.
Configuring How a Key Service Handles Encrypted Messages
You can create one or more encryption profiles if you use a key service. You might want to create different
encryption profiles if you want to use different levels of security for different groups of email. For example,
you might want messages containing sensitive material to be sent with high security, but other messages to
be sent with medium security. In this case, you might create a high security encryption profile to associate
with the messages containing certain key words (such as ‘confidential’), and create another encryption profile
for other outgoing messages.
You can assign an encryption profile to a custom user role to allow delegated administrators assigned to that
role to use the encryption profile with their DLP policies and content filters. Only administrators, operators,
and delegated users can use encryption profiles when configuring DLP policies and content filters. Encryption
profiles that are not assigned to a custom role are available for use by all delegated administrators with mail
or DLP policy privileges. See Distributing Administrative Tasks, on page 977 for more information.
Note You can configure multiple encryption profiles for a hosted key service. If your organization has multiple
brands, this allows you to reference different logos stored on the key server for the PXE envelopes.
An encryption profile stores the following settings:
• Key server settings. Specify a key server and information for connecting to that key server.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
542
Cisco Email Encryption
Configuring How a Key Service Handles Encrypted Messages
• Envelope settings. Specify details about the message envelope, such as the level of security, whether to
return read receipts, the length of time a message is queued for encryption before it times out, the type
of encryption algorithm to use, and whether to enable a decryption applet to run on the browser.
• Message settings. Specify details about messages, such as whether to enable secure message forwarding
and secure Reply All.
• Notification settings. Specify the notification template to use for text and HTML notifications, as well
as encryption failure notifications. You create the templates in text resources and select the templates
when creating the encryption profile. You can also localize envelopes and specify a message subject for
encryption failure notifications. For more information about notifications, see Encryption Notification
Templates, on page 664 and Bounce and Encryption Failure Notification Templates, on page 663.
Procedure
Step 1 In the Email Encryption Profiles section, click Add Encryption Profile.
Step 2 Enter a name for the Encryption Profile.
Step 3 Click the Used By (Roles) link, select the custom user role you want to have access to the encryption profile,
and click OK.
Delegated administrators assigned to this custom role can use the encryption profile for any DLP policies and
content filters for which they are responsible.
Step 4 In the Key Server Settings section, select from the following key servers:
• Cisco Encryption appliance (in network)
• Cisco Registered Envelope Service (hosted key service)
Step 5 If you select the Cisco Encryption appliance (local key service), enter the following settings:
• Internal URL. This URL is used by the email gateway to contact the in-network Cisco Encryption
appliance.
• External URL. This URL is used when the recipient’s message accesses keys and other services on the
Cisco Encryption appliance. The recipient uses this URL to make inbound HTTP or HTTPS requests.
Step 6 If you select the Cisco Registered Envelope Service, enter the URL for the hosted key service. The key service
URL is https://res.cisco.com .
Step 7 Click Advanced under Key Server Settings to specify whether to use HTTP or HTTPS for transferring the
envelope’s encrypted payload when the recipient opens the envelope. Choose from one of the following:
• Use the Key Service with HTTP. Transfers the encrypted payload from the key service using HTTP
when the recipient opens the envelope. If you are using Cisco Registered Envelope Service, this is the
URL you specified in Step 6. If you are using the Cisco Encryption appliance, this is the external URL
you specified in Step 5.
• Since the payload is already encrypted, transporting it over HTTP is safe and faster than sending over
HTTPS. This provides better performance than sending image requests over HTTPS.
• Use the Key Service with HTTPS. Transfers the encrypted payload from the key service using HTTPS
when the recipient opens the envelope. If you are using Cisco Registered Envelope Service, this is the
URL you specified in Step 6. If you are using the Cisco Encryption appliance, this is the external URL
you specified in Step 5.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
543
Cisco Email Encryption
Configuring How a Key Service Handles Encrypted Messages
• Specify a separate URL for payload transport. If you don’t want to use the key server for your encrypted
payload, you can use another URL and specify whether to use HTTP or HTTPS for the payload transfer.
Step 8 In the Envelope Settings section, select the level of message security:
• High Security. The recipient must always enter a passphrase to open encrypted messages.
• Medium Security. The recipient does not need to enter credentials to open the encrypted message if the
recipient credentials are cached.
• No Passphrase Required. This is the lowest level of encrypted message security. The recipient does
not need to enter a passphrase to open the encrypted message. You can still enable the read receipts,
Secure Reply All, and Secure Message Forwarding features for envelopes that are not passphrase-protected.
Step 9 To enable users to open your organization’s URL by clicking its logo, you can add a link to the logo. Choose
from the following options:
• No link. A live link is not added to the message envelope.
• Custom link URL. Enter the URL to add a live link to the message envelope.
Step 10 (Optional) Enable read receipts. If you enable this option, the sender receives a receipt when recipients open
the secure envelope.
Step 11 (Optional) Click Advanced under Envelope Settings to configure the following settings:
• Enter the length of time (in seconds) that a message can be in the encryption queue before timing out.
Once a message times out, the email gateway bounces the message and sends a notification to the sender.
• Select an encryption algorithm - 'AES 192' or 'AES 256.'
Note AES provides stronger encryption but also takes longer to decrypt, introducing delays for
recipients. AES is typically used in government and banking applications.
• Enable or disable the decryption applet. Enabling this option causes the message attachment to be opened
in the browser environment. Disabling this option causes message attachments to be decrypted at the
key server. If you disable this option, messages may take longer to open, but are not dependent on the
browser environment.
Step 12 In the Message Settings section, do the following:
• To enable secure reply all feature, check the Enable Secure Reply All check box.
• To enable secure message forwarding feature, check the Enable Secure Message Forwarding check
box.
Step 13 (Optional) If you have selected Cisco Registered Envelope Service and this service supports localization of
envelopes, enable localization of envelopes. In Notification Settings section, check the Use Localized Envelope
check box.
Note If you enable localization of envelopes, you cannot select encrypted message HTML or text
notification.
If you want to set the default locale of the envelope, see Configuring the Default Locale of the Envelope, on
page 545.
Step 14 Select the HTML and text notification templates.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
544
Cisco Email Encryption
Configuring the Default Locale of the Envelope
Note The key server uses an HTML or text notification based on the recipient’s email application. You
must configure notifications for both.
Do the following:
a) Select an HTML notification template. Choose from HTML notifications you configured in text resources.
If you did not configure a template, the system uses the default template.
b) Select a text notification template. Choose from text notifications you configured in text resources. If you
did not configure a template, the system uses the default template.
Note These options are unavailable if you use localized envelopes.
Step 15 Enter a subject header for encryption failure notifications. The email gateway sends a notification if the
encryption process times out.
Step 16 Select an encryption failure notification template for the message body. Choose from an encryption failure
notification template you configured in text resources. If you did not configure a template, the system uses
the default template.
Step 17 Submit and commit your changes.
Step 18 If you use Cisco Registered Envelope Service, you must take the additional step of provisioning your email
gateway. Provisioning the email gateway registers the encryption profile with the hosted key service. To
provision the email gateway, click the Provision button for the encryption profile you want to register.
Configuring the Default Locale of the Envelope
The default locale of the envelope is English. If you have selected Cisco Registered Envelope Service and
this service supports localization of envelopes, you can change the locale of the envelope to any one of the
following:
• English
• French
• German
• Japanese
• Portuguese
• Spanish
• Italian
• Korean
• Dutch
• Polish
• Russian
• Chinese
Before You Begin
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
545
Cisco Email Encryption
Updating to the Latest Version of the PXE Engine
• Create an encryption profile with Cisco Registered Envelope Service as Key Service Type and envelope
localization enabled. See Configuring How a Key Service Handles Encrypted Messages, on page 542.
• Make sure that Cisco Registered Envelope Service supports localization of envelopes.
Procedure
Step 1 Click Security Services > Cisco IronPort Email Encryption.
Step 2 Open an existing encryption profile.
Step 3 In the Notification Settings section, choose the locale from the Localized Envelopes drop-down list.
Step 4 Click Submit.
Step 5 Click Commit Changes.
Updating to the Latest Version of the PXE Engine
The Cisco Email Encryption Settings page displays the current versions of the PXE engine and the Domain
Mappings file used by your email gateway. You can use the Security Services > Service Updates page (or
the updateconfig command in the CLI) to configure the email gateway to automatically update the PXE engine.
For more information, see Service Updates , on page 1026.
You can also manually update the engine using the Update Now button of the PXE Engine Updates section
of IronPort Email Encryption Settings page (or the encryptionupdate command in the CLI).
Determining Which Messages to Encrypt
After you create an encryption profile, you need to create an outgoing content filter that determines which
email messages should be encrypted. The content filter scans outgoing email and determines if the message
matches the conditions specified. Once the content filter determines a message matches the condition, the
email gateway encrypts the message and sends the generated key to the key server. It uses settings specified
in the encryption profile to determine the key server to use and other encryption settings.
You can also encrypt messages after they are released after Data Loss Prevention scanning. For more
information, see Defining Actions to Take for DLP Violations (Message Actions) , on page 531.
Related Topics
• Using a TLS Connection as an Alternative to Encryption, on page 546
• Encrypting and Immediately Delivering Messages using a Content Filter, on page 547
• Encrypting a Message upon Delivery using a Content Filter, on page 548
Using a TLS Connection as an Alternative to Encryption
Based on the destination controls specified for a domain, your email gateway can securely relay a message
over a TLS connection instead of encrypting it, if a TLS connection is available. The email gateway decides
whether to encrypt the message or send it over a TLS connection based on the TLS setting in the destination
controls (Required, Preferred, or None) and the action defined in the encryption content filter.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
546
Cisco Email Encryption
Encrypting and Immediately Delivering Messages using a Content Filter
When creating the content filter, you can specify whether to always encrypt a message or to attempt to send
it over a TLS connection first, and if a TLS connection is unavailable, to encrypt the message. The following
table shows you how an email gatewaywill send a message based on the TLS settings for a domain’s destination
controls, if the encryption control filter attempts to send the message over a TLS connection first.
Table 44: TLS Support on Email Gateways
Destination Controls TLS Action if TLS Connection Available Action if TLS Connection Unavailable
Setting
None Encrypt envelope and send Encrypt envelope and send
TLS Preferred Send over TLS Encrypt envelope and send
TLS Required Send over TLS Retry/bounce message
For more information about enabling TLS on destination controls, see Configuring the Gateway to Receive
Email, on page 77.
Encrypting and Immediately Delivering Messages using a Content Filter
Before You Begin
• To understand the concept of building conditions for content filters, see Overview of Content Filters ,
on page 281.
• (Optional) See Inserting Encryption Headers into Messages, on page 549.
Procedure
Step 1 Go to Mail Policies > Outgoing Content Filters.
Step 2 In the Filters section, click Add Filter.
Step 3 In the Conditions section, click Add Condition.
Step 4 Add a condition to filter the messages that you want to encrypt. For example, to encrypt sensitive material,
you might add a condition that identifies messages containing particular words or phrases, such as
“Confidential,” in the subject or body.
Step 5 Click OK.
Step 6 Optionally, click Add Action and select Add Header to insert an encryption header into the messages to
specify an additional encryption setting.
Step 7 In the Actions section, click Add Action.
Step 8 Select Encrypt and Deliver Now (Final Action) from the Add Action list.
Step 9 Select whether to always encrypt messages that meet the condition or to only encrypt messages if the attempt
to send it over a TLS connection fails.
Step 10 Select the encryption profile to associate with the content filter.
The encryption profile specifies settings about the key server to use, levels of security, formatting of the
message envelope, and other message settings. When you associate an encryption profile with the content
filter, the content filter uses these stored settings to encrypt messages.
Step 11 Enter a subject for the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
547
Cisco Email Encryption
Encrypting a Message upon Delivery using a Content Filter
Step 12 Click OK.
The content filter in the following figure shows a content filter that searches for ABA content in the message
body. The action defined for the content filter specifies that the email is encrypted and delivered.
Figure 35: Encryption Content Filter
Step 13 After you add the encrypt action, click Submit.
Step 14 Commit your changes.
What to do next
After you add the content filter, you need to add the filter to an outgoing mail policy. You may want to enable
the content filter on the default policy, or you may choose to apply the filter to a specific mail policy, depending
on your organization’s needs. For information about working with mail policies, see Overview of Mail Policies,
on page 267.
Encrypting a Message upon Delivery using a Content Filter
Create a content filter to encrypt a message on delivery, which means that the message continues to the next
stage of processing, and when all processing is complete, the message is encrypted and delivered.
Before You Begin
• To understand the concept of building conditions for content filters, see Overview of Content Filters ,
on page 281.
• (Optional) See Inserting Encryption Headers into Messages, on page 549.
Procedure
Step 1 Go to Mail Policies > Outgoing Content Filters.
Step 2 In the Filters section, click Add Filter.
Step 3 In the Conditions section, click Add Condition.
Step 4 Add a condition to filter the messages that you want to encrypt. For example, to encrypt sensitive material,
you might add a condition that identifies messages containing particular words or phrases, such as
“Confidential,” in the subject or body.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
548
Cisco Email Encryption
Inserting Encryption Headers into Messages
Step 5 Click OK.
Step 6 Optionally, click Add Action and select Add Header to insert an encryption header into the messages to
specify an additional encryption setting.
Step 7 In the Actions section, click Add Action.
Step 8 Select Encrypt on Delivery from the Add Action list.
Step 9 Select whether to always encrypt messages that meet the condition or to only encrypt messages if the attempt
to send it over a TLS connection fails.
Step 10 Select the encryption profile to associate with the content filter.
The encryption profile specifies settings about the key server to use, levels of security, formatting of the
message envelope, and other message settings. When you associate an encryption profile with the content
filter, the content filter uses these stored settings to encrypt messages.
Step 11 Enter a subject for the message.
Step 12 Click OK.
Step 13 After you add the encrypt action, click Submit.
Step 14 Commit your changes.
What to do next
After you add the content filter, you need to add the filter to an outgoing mail policy. You may want to enable
the content filter on the default policy, or you may choose to apply the filter to a specific mail policy, depending
on your organization’s needs. For information about working with mail policies, see Overview of Mail Policies,
on page 267.
Inserting Encryption Headers into Messages
AsyncOS enables you to add encryption settings to a message by inserting an SMTP header into a message
using either a content filter or a message filter. The encryption header can override the encryption settings
defined in the associated encryption profile, and it can apply specified encryption features to messages.
Note The Cisco Ironport Encryption appliance must be set up to handle flagged messages.
Procedure
Step 1 Go to Mail Policies > Outgoing Content Filters or Incoming Content Filters.
Step 2 In the Filters section, click Add Filter.
Step 3 In the Actions section, click Add Action and select Add/Edit Header to insert an encryption header into the
messages to specify an additional encryption setting.
For example, if you want a Registered Envelope to expire in 24 hours after you send it, type
X-PostX-ExpirationDate as the header name and +24:00:00 as the header value.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
549
Cisco Email Encryption
Encryption Headers
What to do next
Related Topics
• Encryption Headers, on page 550
• Encryption Headers Examples, on page 551
• For more information about creating an encryption content filter, see Encrypting and Immediately
Delivering Messages using a Content Filter, on page 547.
• For information about inserting a header using a message filter, see Using Message Filters to Enforce
Email Policies, on page 139.
Encryption Headers
The following table displays the encryption headers that you can add to messages.
Table 45: Email Encryption Headers
MIME Header Description Value
Indicates whether to enable secure reply for the A Boolean for whether to display the Reply button.
X-PostX-Reply- Enabled
message and displays the Reply button in the Set to true to display the button. The default value
message bar. This header adds an encryption setting is false .
to the message.
Indicates whether to enable secure “reply all” for the A Boolean for whether to display Reply All button.
X-PostX-Reply-All-
message and displays the Reply All button in the Set to true to display the button. The default value
Enabled
message bar. This header overrides the default profile is false .
setting.
Indicates whether to enable secure message A Boolean for whether to display the Forward
X-PostX-Forward-
forwarding and displays the Forward button in the button. Set to true to display the button. The
Enabled
message bar. This header overrides the default profile default value is false .
setting.
Indicates whether to enable read receipts. The sender A Boolean for whether to send a read receipt. Set
X-PostX-Send-Return-
receives a receipt when recipients open the Secure to true to display the button. The default value is
Receipt
Envelope. This header overrides the default profile false .
setting.
Defines a Registered Envelope’s expiration date A string value containing relative date or time.
X-PostX-Expiration Date
before sending it. The key server restricts access to Use the +HH:MM:SS format for relative hours,
the Registered Envelope after the expiration date. minutes, and seconds, and the +D format for
The Registered Envelope displays a message relative days. By default, there is no expiration
indicating that the message has expired. This header date.
adds an encryption setting to the message.
If you use Cisco Registered Envelope Service, you
can log in to the website at http://res.cisco.com and
use the message management features to set, adjust,
or eliminate the expiration dates of messages after
you send them.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
550
Cisco Email Encryption
Encryption Headers Examples
MIME Header Description Value
Defines the Registered Envelope’s “read by” date A string value containing relative date or time.
X-PostX-ReadNotification
before sending it. The local key server generates a Use the +HH:MM:SS format for relative hours,
Date notification if the Registered Envelope has not been minutes, and seconds, and the +D format for
read by this date. Registered Envelopes with this relative days. By default, there is no expiration
header do not work with Cisco Registered Envelope date.
Service, only a local key server. This header adds an
encryption setting to the message.
Indicates whether to disable the decryption applet. A Boolean for whether to disable the decryption
X-PostX-Suppress-Applet-
The decryption applet causes message attachments applet. Set to true to disable the applet. The default
For-Open to be opened in the browser environment. Disabling value is false .
the applet causes the message attachment to be
decrypted at the key server. If you disable this option,
messages may take longer to open, but they are not
dependent on the browser environment. This header
overrides the default profile setting.
Indicates whether to send JavaScript-free envelopes. A Boolean for whether the JavaScript applet
X-PostX-Use-Script
A JavaScript-free envelope is a Registered Envelope should be included or not. Set to false to send a
that does not include the JavaScript that is used to JavaScript-free envelope. The default value is true
open envelopes locally on the recipient's computer. .
The recipient must use either the Open Online
method or the Open by Forwarding method to view
the message. Use this header if a recipient domain's
gateway strips JavaScript and makes the encrypted
message unopenable.This header adds an encryption
setting to the message.
Indicates whether to allow envelope-specific key A Boolean for whether to enable envelope key
X-PostX-Remember-Envelope
caching for offline opening of envelopes. With caching and display the “Remember the password
-Key-Checkbox
envelope key caching, the decryption key for a for this envelope” check box. The default value is
particular envelope is cached on the recipient’s false .
computer when the recipient enters the correct
passphrase and selects the “Remember the password
for this envelope” check box. After that, the recipient
does not need to enter a passphrase again to reopen
the envelope on the computer. This header adds an
encryption setting to the message.
Encryption Headers Examples
This section provides examples of encryption headers.
Related Topics
• Enabling JavaScript-Free Envelopes, on page 552
• Enabling Envelope Key Caching for Offline Opening, on page 552
• Enabling Message Expiration, on page 552
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
551
Cisco Email Encryption
Enabling Envelope Key Caching for Offline Opening
• Disabling the Decryption Applet, on page 552
Enabling Envelope Key Caching for Offline Opening
To send a Registered Envelope with envelope key caching enabled, insert the following header into the
message:
X-PostX-Remember-Envelope-Key-Checkbox: true
The “Remember the password for this envelope” check box is displayed on the Registered Envelope.
Enabling JavaScript-Free Envelopes
To send a Registered Envelope that is JavaScript-free, insert the following header into the message:
X-PostX-Use-Script: false
When the recipient opens the securedoc.html attachment, the Registered Envelope is displayed with an Open
Online link, and the Open button is disabled.
Enabling Message Expiration
To configure a message so that it expires 24 hours after you send it, insert the following header into the
message:
X-PostX-ExpirationDate: +24:00:00
The recipient can open and view the content of the encrypted message during the 24-hour period after you
send it. After that, the Registered Envelope displays a message indicating that the envelope has expired.
Disabling the Decryption Applet
To disable the decryption applet and have the message attachment decrypted at the key server, insert the
following header into the message:
X-PostX-Suppress-Applet-For-Open: true
Note The message may take longer to open when you disable the decryption applet, but it is not dependent on the
browser environment.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
552
CHAPTER 24
S/MIME Security Services
This chapter contains the following sections:
• Overview of S/MIME Security Services, on page 553
• S/MIME Security Services in Email Gateway, on page 553
• Signing, Encrypting, or Signing and Encrypting Outgoing Messages using S/MIME, on page 557
• Verifying, Decrypting, or Decrypting and Verifying Incoming Messages using S/MIME, on page 567
• S/MIME Certificate Requirements, on page 573
• Managing Public Keys, on page 574
Overview of S/MIME Security Services
Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standards-based method for sending and receiving
secure, verified email messages. S/MIME uses public/private key pair to encrypt or sign messages. This way,
• If the message is encrypted, only the message recipient can open the encrypted message.
• If the message is signed, the message recipient can validate the identity of the sender’s domain and can
be assured that the message has not been altered while in transit.
For more information about S/MIME, review the following RFCs:
• RFC 5750: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 - Certificate Handling
• RFC 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 - Message Specification
• RFC 3369: Cryptographic Message Syntax
S/MIME Security Services in Email Gateway
Organizations may want to communicate securely using S/MIME without requiring that all end users possess
their own certificates. For such organizations, the email gateway supports S/MIME security services (signing,
encryption, verification, and decryption) at the gateway level using certificates that identify the organization
rather than the individual user.
The email gateway provides the following S/MIME security services for Business-to-Business (B2B) and
Business-to-Consumer (B2C) scenarios:
• Sign, encrypt, or sign and encrypt messages using S/MIME. See Signing, Encrypting, or Signing and
Encrypting Outgoing Messages using S/MIME, on page 557.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
553
S/MIME Security Services
Understanding How S/MIME Security Services Works
• Verify, decrypt, or decrypt and verify messages using S/MIME. See Verifying, Decrypting, or Decrypting
and Verifying Incoming Messages using S/MIME, on page 567.
Related Topics
• Understanding How S/MIME Security Services Works, on page 554
Understanding How S/MIME Security Services Works
• Scenario: Business-to-Business, on page 554
• Scenario: Business-to-Consumer, on page 556
Scenario: Business-to-Business
Organizations A and B want all the messages communicated between them to be signed and encrypted using
S/MIME. Organization A has configured Cisco Secure Email Gateway to perform S/MIME security services
at the gateway level. Organization B has configured a third-party application to perform S/MIME security
services at the gateway level.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
554
S/MIME Security Services
Scenario: Business-to-Business
Note The current example assumes that organization B is using a third-party application to perform S/MIME security
services. In the real world, this can be any application or email gateway (including Cisco Secure Email
Gateway) that can perform S/MIME security services at the gateway level.
Organization A sending a message to Organization B:
1. Bob (Organization A) uses an email client to send an unsigned and unencrypted message to Dave
(Organization B).
2. Cisco Secure Email Gateway in the Organization A signs and encrypts the messages and sends it to
Organization B.
3. The third-party application at the gateway of Organization B decrypts and verifies the message.
4. Dave receives an unencrypted and signed message.
Organization B sending a message to Organization A:
1. Dave (Organization B) uses an email client to send an unsigned and unencrypted message to Bob
(Organization A).
2. The third-party application at the gateway of Organization B signs and encrypts the message and sends
it to Organization A.
3. Cisco Secure Email Gateway in the Organization A decrypts and verifies the message.
4. Bob receives an unencrypted and signed message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
555
S/MIME Security Services
Scenario: Business-to-Consumer
Scenario: Business-to-Consumer
Organizations A and B want all the messages communicated between them to be signed and encrypted using
S/MIME. Organization A has configured Cisco Secure Email Gateway to perform S/MIME security services
at the gateway level. Organization B has configured the email clients of all the users to perform S/MIME
security services.
Organization A sending a message to Organization B:
1. Alice (Organization A) uses an email client to send an unsigned and unencrypted message to Erin
(Organization B).
2. Secure Email Gateway in the Organization A signs and encrypts the messages and sends it to Organization
B.
3. The email client in the Organization B decrypts and verifies the message and displays it to Erin.
Organization B sending a message to Organization A:
1. Erin (Organization B) uses the email client to sign and encrypt a message and sends it to Alice (Organization
A).
2. Secure Email Gateway in the Organization A decrypts and verifies the message.
3. Alice receives an unencrypted and unsigned message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
556
S/MIME Security Services
Signing, Encrypting, or Signing and Encrypting Outgoing Messages using S/MIME
Signing, Encrypting, or Signing and Encrypting Outgoing
Messages using S/MIME
• S/MIME Signing and Encryption Workflow in Email Gateway, on page 557
• How to Sign, Encrypt, or Sign and Encrypt Outgoing Messages using S/MIME, on page 558
• Setting Up Certificates for S/MIME Signing, on page 559
• Setting Up Public Keys for S/MIME Encryption, on page 561
• Managing S/MIME Sending Profiles, on page 563
• Determining Which Messages to Sign, Encrypt, or Sign and Encrypt, on page 565
• Signing, Encrypting, or Signing and Encrypting and Immediately Delivering Messages using a Content
Filter, on page 566
• Signing, Encrypting, or Signing and Encrypting a Message upon Delivery using a Content Filter, on page
566
Note You can use the email gateway to sign, encrypt, and sign and encrypt outgoing and incoming messages.
S/MIME Signing and Encryption Workflow in Email Gateway
• S/MIME Signing Workflow, on page 557
• S/MIME Encryption Workflow, on page 557
S/MIME Signing Workflow
The following process describes how the email gateway performs S/MIME signing.
1. Apply a hash algorithm to the message to create a message digest.
2. Encrypt the message digest using private key of the email gateway's S/MIME certificate.
3. Create a PKCS7 signature with the encrypted message digest and public key of the email gateway's
S/MIME certificate.
4. Sign the message by attaching the PKCS7 signature to the message.
5. Send the signed message to the recipient.
S/MIME Encryption Workflow
The following process describes how the email gateway performs S/MIME encryption.
1. Create a pseudo-random session key.
2. Encrypt the message body using the session key.
3. Encrypt the session key using the public key of the recipient's (gateway or consumer) S/MIME certificate.
4. Attach the encrypted session key to the message.
5. Send the encrypted message to the recipient.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
557
S/MIME Security Services
How to Sign, Encrypt, or Sign and Encrypt Outgoing Messages using S/MIME
Note If PXE and S/MIME encryption is enabled on the email gateway, it encrypts messages using S/MIME first,
and then using PXE.
How to Sign, Encrypt, or Sign and Encrypt Outgoing Messages using S/MIME
Steps Do This More Info
Step 1 Understand the S/MIME certificate requirements. See S/MIME Certificate Requirements, on
page 573.
Step 2 Depending on your requirements, do one of the See:
following:
• Setting Up Certificates for S/MIME
• For S/MIME signing, set up an S/MIME Signing, on page 559
signing certificate. • Setting Up Public Keys for S/MIME
• For S/MIME encryption, set up the public Encryption, on page 561
key of the recipient’s S/MIME certificate.
• For S/MIME signing and encryption, set up
an S/MIME signing certificate and the public
key of the recipient’s S/MIME certificate,
respectively.
Step 3 Create a profile for signing, encrypting, or signing See Create an S/MIME Sending Profile for
and encrypting messages. Signing, Encrypting, or Signing and
Encrypting Messages, on page 564.
Step 4 Define the conditions that messages must meet in See Determining Which Messages to Sign,
order for the email gateway to sign, encrypt, or Encrypt, or Sign and Encrypt, on page 565.
sign and encrypt them.
Step 5 Determine when in the email workflow to sign, See:
encrypt, or sign and encrypt messages.
• Signing, Encrypting, or Signing and
Encrypting and Immediately
Delivering Messages using a Content
Filter, on page 566
• Signing, Encrypting, or Signing and
Encrypting a Message upon Delivery
using a Content Filter, on page 566
Step 6 Define groups of users for whom you want to sign Create a mail policy.
or encrypt messages.
See Mail Policies, on page 267
Step 7 Associate the signing or encryption actions that Associate the content filter with the mail
you defined with the user groups you defined. policy.
See Mail Policies, on page 267
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
558
S/MIME Security Services
Setting Up Certificates for S/MIME Signing
Note If you want to perform S/MIME signing, encryption, or signing and encryption using CLI, use the
smimeconfig command. See CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway.
Setting Up Certificates for S/MIME Signing
You must set up an S/MIME certificate for signing messages. The email gateway allows you to set up S/MIME
signing certificates using one of the following methods:
• Create a self-signed S/MIME certificate using the email gateway. See Creating a Self-Signed S/MIME
Certificate, on page 559.
• Import an existing S/MIME certificate to the email gateway. See Importing an S/MIME Signing Certificate,
on page 560.
Note Cisco recommends that you use self-signed S/MIME certificates for sending signed messages to the users
within your organization or in a testing environment. For sending signed messages to external users or in a
production environment, use a valid S/MIME certificate obtained from a trusted CA.
For understanding the certificate requirements for S/MIME, see S/MIME Certificate Requirements, on page
573.
Creating a Self-Signed S/MIME Certificate
You can generate self-signed S/MIME certificates that are compliant to RFC 5750 (Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.2 - Certificate Handling) using the web interface or CLI.
Note Cisco recommends that you use self-signed S/MIME certificates for sending signed messages to the users
within your organization or in a testing environment.
Procedure
Step 1 Click Network > Certificates.
Step 2 Click Add Certificate.
Step 3 Choose Create Self-Signed S/MIME Certificate.
Step 4 Enter the following information for the self-signed certificate:
Common Name The fully qualified domain name.
Organization The exact legal name of the organization.
Organizational Unit Section of the organization.
City (Locality) The city where the organization is legally located.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
559
S/MIME Security Services
Importing an S/MIME Signing Certificate
Common Name The fully qualified domain name.
State (Province) The state, county, or region where the organization is legally located.
Country The two letter ISO abbreviation of the country where the
organization is legally located.
Duration before expiration The number of days before the certificate expires.
Subject Alternative Name(Domains) If you configure this field, any user from the specified domain can
send signed messages.
Name of the domain from which you plan to send signed messages.
Examples include domain.com and *.domain.net . For multiple
entries, use a comma-separated list.
Subject Alternative Name(Email) If you configure this field, only the specified users can send signed
messages.
Email address of the user who is planning to send signed messages,
for example, [email protected] . For multiple entries, use a
comma-separated list.
Private Key Size Size of the private key to generate the certificate signing request
(CSR).
Note An S/MIME signing certificate can contain both Subject Alternative Name (Domains) and Subject
Alternative Name (Email).
Step 5 Click Next to view the certificate and signature information.
Step 6 Depending on your requirements, do the following:
• Select the FQDN Validation check box to allow the email gateway to check whether the 'Common
Name,' 'SAN: DNS Name' fields, or both present in the certificate, are in the FQDN format.
• Enter a name for the certificate.
• If you want to submit a CSR for the self-signed certificate to a certificate authority, click Download
Certificate Signing Request to save the CSR in PEM format to a local or network machine.
Step 7 Submit and commit your changes.
What to do next
Note Use the certconfig command to generate self-signed S/MIME certificates using CLI.
Importing an S/MIME Signing Certificate
If you already have an S/MIME certificate for signing messages, you can add it to the email gateway by
importing it.
Before You Begin
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
560
S/MIME Security Services
Setting Up Public Keys for S/MIME Encryption
Make sure that the S/MIME certificate that you plan to import meets the requirements described in S/MIME
Certificate Requirements, on page 573.
Procedure
Step 1 Click Network > Certificates.
Step 2 Click Add Certificate.
Step 3 Choose Import Certificate.
Step 4 Enter the path to the certificate file on your network or local machine.
Step 5 Enter the passphrase for the file.
Step 6 Click Next to view the certificate’s information.
Step 7 [Optional] Select the FQDN Validation check box to allow the email gateway to check whether the 'Common
Name,' 'SAN: DNS Name' fields, or both present in the certificate, are in the FQDN format.
Step 8 Enter a name for the certificate.
Step 9 Submit and commit your changes.
What to do next
Note Use the certconfig command to import S/MIME certificates using CLI.
Setting Up Public Keys for S/MIME Encryption
You must add the public key of the recipient's S/MIME certificate to the email gateway for encrypting messages.
Depending on your organizational policies and processes, you can use one of the following methods to add
the public key to the email gateway:
• Request the recipient to send the public key using an electronic channel, for example, email. You can
then add the public key using the web interface or CLI.
For instructions to add the public key, see Adding a Public Key for S/MIME Encryption, on page 561.
• Enable public key harvesting using the web interface or CLI and request the recipient to send a signed
message. The Email Security email gateway can harvest the public key from the signed message.
For instructions to harvest public key from an incoming signed message, see Harvesting Public Keys,
on page 562.
Adding a Public Key for S/MIME Encryption
Before You Begin
• Make sure that the public key meets the requirements described in S/MIME Certificate Requirements,
on page 573.
• Make sure that the public key is in PEM format.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
561
S/MIME Security Services
S/MIME Harvested Public Keys
Procedure
Step 1 Click Mail Policies > Public Keys.
Step 2 Click Add Public Key.
Step 3 Enter the name of the public key.
Step 4 Enter the public key.
Step 5 Submit and commit your changes.
What to do next
Note Use the smimeconfig command to add public keys using CLI.
S/MIME Harvested Public Keys
You can configure the email gateway to retrieve (harvest) public keys from the incoming S/MIME signed
messages and use the harvested keys to send encrypted messages to the owners (business or consumer) of the
harvested keys.
Public key harvesting can be enabled on the Mail Flow Policies. All the harvested public keys are listed on
the S/MIME Harvested Public Keys page.
Related Topic
• Harvesting Public Keys, on page 562
Harvesting Public Keys
You can configure the email gateway to retrieve (harvest) public key from the incoming S/MIME signed
messages and use it to send encrypted messages to the owner (business or consumer) of the harvested key.
Note By default, public keys from expired or self-signed S/MIME certificates are not harvested.
Before You Begin
Make sure that the public key of the sender’s S/MIME certificate meets the requirements described in S/MIME
Certificate Requirements, on page 573.
Procedure
Step 1 Click Mail Policies > Mail Flow Policies.
Step 2 Create a new Mail Flow Policy or modify an existing one.
Step 3 Scroll down to the Security Features section.
Step 4 Under S/MIME Public Key Harvesting, do the following:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
562
S/MIME Security Services
Managing S/MIME Sending Profiles
• Enable S/MIME public key harvesting.
• (Optional) Choose whether to harvest public keys if the verification of the incoming signed messages
fail.
• (Optional) Choose whether to harvest updated public keys.
Note If an email gateway receives more than one updated public key from the same domain or message
within 48 hours, it sends out a warning alert.
Step 5 Submit and commit your changes.
What to do next
Note The size of the harvested public key repository on the email gateway is 512 MB. If repository is full,the email
gateway will automatically remove unused public keys.
Use the listenerconfig command to enable key harvesting using CLI.
Next Step
Request the recipient to send a signed message to the email gateway administrator. The email gateway will
harvest the public key from the signed message and displays it on the Mail Policies > Harvested Public Keys
page.
Related Topics
• S/MIME Harvested Public Keys, on page 562
Managing S/MIME Sending Profiles
An S/MIME sending profile allows you define parameters such as:
• S/MIME mode to use, for example, sign, encrypt, and so on.
• S/MIME certificate for signing
• S/MIME signing mode to use, for example, opaque or detached.
• Action to take if the public key of the recipient's S/MIME certificate is not available on the email gateway.
For example, one organization requires all the messages sent to them be signed and another one requires all
the messages sent to them be signed and encrypted. In this scenario, you must create two sending profiles,
one for signing alone and one for signing and encryption.
You to can create, edit, delete, import, export, and search S/MIME sending profiles using the web interface
or CLI.
Related Topics
• Create an S/MIME Sending Profile for Signing, Encrypting, or Signing and Encrypting Messages, on
page 564
• Edit an S/MIME Sending Profile, on page 565
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
563
S/MIME Security Services
Create an S/MIME Sending Profile for Signing, Encrypting, or Signing and Encrypting Messages
Create an S/MIME Sending Profile for Signing, Encrypting, or Signing and Encrypting Messages
Procedure
Step 1 Click Mail Policies > Sending Profiles.
Step 2 Click Add Profile.
Step 3 Configure the following fields:
S/MIME Profile Name Enter the name of the sending profile.
S/MIME Mode Choose the S/MIME mode. Possible values are:
• Sign
• Encrypt
• Sign/Encrypt. Sign and then encrypt
• Triple. Sign, encrypt, and then sign again
Note If you are using one of the following S/MIME modes: Sign,
Sign/Encrypt, or Triple, messages will be bounced to the sender if the
signing fails.
Signing Certificate Choose the signing certificate to use.
Note You need to set this field only if you choose one of the following S/MIME
modes: Sign, Sign/Encrypt, or Triple.
S/MIME Sign Mode Choose the mode of S/MIME signing. Possible values are:
• Opaque. An opaque-signed message contains the message and signature
combined in a single part and can be read only by verifying the signature.
• Detached. The signature information is separate from the text being signed.
The MIME type for this is multipart/signed with the second part having a
MIME subtype of application/(x-)pkcs7-signature.
Note You need to set this field only if you choose one of the following S/MIME
modes: Sign, Sign/Encrypt, or Triple.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
564
S/MIME Security Services
Edit an S/MIME Sending Profile
S/MIME Profile Name Enter the name of the sending profile.
S/MIME Action Choose the action that the email gateway must take if the recipient's public key is
not available. Possible values are:
• Bounce. The message is bounced to the sender if any one of the recipient’s
public key is not available.
• Drop. The message is dropped if any one of the recipient’s public key is not
available.
• Split. The message is split. The message to the recipients whose public keys
are not available are delivered without encryption and the message to the
recipients whose public keys are available are encrypted and delivered.
Example: Assume that you are sending a message to [email protected] and
[email protected] and the public key of [email protected] is not available.
In this scenario, if you have selected Split, the email gateway will:
• Deliver the message to [email protected] after encrypting it.
• Deliver the message to [email protected] without encrypting it.
Note You need to set this field only if you choose one of the following S/MIME
modes: Encrypt, Sign/Encrypt, or Triple.
Step 4 Submit and commit your changes.
What to do next
Note Use the smimeconfig command to create sending profiles using CLI.
Edit an S/MIME Sending Profile
Procedure
Step 1 Click Mail Policies > Sending Profiles.
Step 2 Click on the sending profile that you want to modify.
Step 3 Edit the fields as described in Create an S/MIME Sending Profile for Signing, Encrypting, or Signing and
Encrypting Messages, on page 564.
Step 4 Submit and commit your changes.
Determining Which Messages to Sign, Encrypt, or Sign and Encrypt
After you create a sending profile, you need to create an outgoing content filter that determines which email
messages should be signed, encrypted, or signed and encrypted. The content filter scans outgoing email and
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
565
S/MIME Security Services
Signing, Encrypting, or Signing and Encrypting and Immediately Delivering Messages using a Content Filter
determines if the message matches the conditions specified. Once the content filter determines a message
matches the condition, the email gateway signs, encrypts, or signs or encrypts the message.
Related Topics
• How to Filter Messages Based on Content, on page 299
Signing, Encrypting, or Signing and Encrypting and Immediately Delivering
Messages using a Content Filter
Before You Begin
Understand the concept of building conditions for content filters. See How Content Filters Work, on page 281.
Procedure
Step 1 Go to Mail Policies > Outgoing Content Filters.
Step 2 In the Filters section, click Add Filter.
Step 3 In the Conditions section, click Add Condition.
Step 4 Add a condition to filter the messages that you want to sign, encrypt, or sign and encrypt. For example, to
encrypt sensitive material, you might add a condition that identifies messages containing particular words or
phrases, such as “Confidential,” in the subject or body.
Step 5 Click OK.
Step 6 In the Actions section, click Add Action.
Step 7 Select S/MIME Sign/Encrypt (Final Action) from the Add Action list.
Step 8 Select the sending profile to associate with the content filter.
Step 9 Click OK.
Step 10 Submit and commit your changes.
What to do next
After you add the content filter, you need to add the filter to an outgoing mail policy. You may want to enable
the content filter on the default policy, or you may choose to apply the filter to a specific mail policy, depending
on your organization’s needs. For information about working with mail policies, see Overview of Mail Policies,
on page 267.
Signing, Encrypting, or Signing and Encrypting a Message upon Delivery using
a Content Filter
Create a content filter to sign, encrypt, or sign and encrypt a message on delivery, which means that the
message continues to the next stage of processing, and when all processing is complete, the message is signed,
encrypted, or signed and encrypted, and delivered.
Before You Begin
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
566
S/MIME Security Services
Verifying, Decrypting, or Decrypting and Verifying Incoming Messages using S/MIME
• Understand the concept of building conditions for content filters. See Overview of Content Filters , on
page 281.
Procedure
Step 1 Go to Mail Policies > Outgoing Content Filters.
Step 2 In the Filters section, click Add Filter.
Step 3 In the Conditions section, click Add Condition.
Step 4 Add a condition to filter the messages that you want to sign, encrypt, or sign and encrypt. For example, to
encrypt sensitive material, you might add a condition that identifies messages containing particular words or
phrases, such as “Confidential,” in the subject or body.
Step 5 Click OK.
Step 6 In the Actions section, click Add Action.
Step 7 Select S/MIME Sign/Encrypt on Delivery from the Add Action list.
Step 8 Select the sending profile to associate with the content filter.
Step 9 Click OK.
Step 10 Submit and commit your changes.
What to do next
After you add the content filter, you need to add the filter to an outgoing mail policy. You may want to enable
the content filter on the default policy, or you may choose to apply the filter to a specific mail policy, depending
on your organization’s needs. For information about working with mail policies, see Overview of Mail Policies,
on page 267.
Verifying, Decrypting, or Decrypting and Verifying Incoming
Messages using S/MIME
• S/MIME Verification and Decryption Workflow in Email Gateway, on page 567
• How to Verify, Decrypt, or Decrypt and Verify Incoming Messages Using S/MIME, on page 568
• Setting Up Certificates for Decrypting Messages, on page 569
• Setting Up Public Keys for Verifying Signed Messages, on page 570
• Enabling S/MIME Decryption and Verification, on page 572
• Configuring an Action for S/MIME Decrypted or Verified Message, on page 572
Note You can use the email gateway S/MIME security services to verify, decrypt, or decrypt and verify outgoing
and incoming messages.
S/MIME Verification and Decryption Workflow in Email Gateway
• S/MIME Verification Workflow, on page 568
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
567
S/MIME Security Services
S/MIME Verification Workflow
• S/MIME Decryption Workflow, on page 568
S/MIME Verification Workflow
The following process describes how the email gateway performs S/MIME verification.
1. Apply a hash algorithm to the signed message to create a message digest.
2. Decrypt the PKCS7 signature attached to the signed message using the public key of the sender's S/MIME
certificate, and get the message digest.
3. Compare the generated message digest with the message digest retrieved from the signed message. If the
message digests match, the message is verified.
4. Validate the S/MIME certificate of the sender domain with the Certificate Authority.
S/MIME Decryption Workflow
The following process describes how the email gateway performs S/MIME decryption.
1. Decrypt the session key using the private key of the email gateway's S/MIME certificate
2. Decrypt the message body using the session key.
How to Verify, Decrypt, or Decrypt and Verify Incoming Messages Using
S/MIME
Steps Do This More Info
Step 1 Understand the S/MIME certificate requirements. See S/MIME Certificate Requirements,
on page 573.
Step 2 Depending on your requirements, do one of the See
following:
• Setting Up Certificates for
• For S/MIME decryption, add your organization’s Decrypting Messages, on page 569
S/MIME certificate (that contains the private key • Setting Up Public Keys for
required to perform decryption) to the email Verifying Signed Messages, on
gateway. page 570
• For S/MIME verification, add the public key of • Importing a Custom Certificate
the sender's S/MIME certificate required to Authority List, on page 693
perform verification to the email gateway.
• For S/MIME decryption and verification, add
the following to the email gateway:
• Your organization’s S/MIME certificate
(that contains the private key required to
perform decryption) to the email gateway.
• Certificate Authority of the sender domain.
• Public key of the sender's S/MIME
certificate required to perform verification.
Step 3 Configure your mail flow policies to verify, decrypt, See Enabling S/MIME Decryption and
or decrypt and verify incoming messages using Verification, on page 572.
S/MIME.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
568
S/MIME Security Services
Setting Up Certificates for Decrypting Messages
Steps Do This More Info
Step 4 (Optional) Define the action that the email gateway See Configuring an Action for S/MIME
takes on decrypted or verified messages. Decrypted or Verified Message, on page
572.
Note If you want to perform S/MIME verification, decryption, or decryption and verification using CLI, use the
listenerconfig > hostaccess command. See the CLI inline help for more details.
Setting Up Certificates for Decrypting Messages
You must add your organization’s S/MIME certificate (that contains the private key required to perform
decryption) to the email gateway.
Before You Begin
• Share the public key of the email gateway's S/MIME certificate with the sender (business or consumer)
in one of the following ways:
• Send the public key using an electronic channels, for example, email.
• Request the sender to the retrieve the public key using key harvesting.
The sender can use this public key to send encrypted messages to your email gateway.
Note In a B2C scenario, if your organization's S/MIME certificate is a domain
certificate, some email clients (for example, Microsoft Outlook) may not be able
to send encrypted messages using the public key of your organization's S/MIME
certificate. This is because these email clients do not support encryption using
public keys of domain certificates.
• Make sure that the S/MIME certificate that you plan to import meets the requirements described in
S/MIME Certificate Requirements, on page 573.
Procedure
Step 1 Click Network > Certificates.
Step 2 Click Add Certificate.
Step 3 Choose Import Certificate.
Step 4 Enter the path to the certificate file on your network or local machine.
Step 5 Enter the passphrase for the file.
Step 6 Click Next to view the certificate’s information.
Step 7 Enter a name for the certificate.
Step 8 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
569
S/MIME Security Services
Setting Up Public Keys for Verifying Signed Messages
What to do next
Note Use the certconfig command to add the S/MIME certificates using CLI.
Setting Up Public Keys for Verifying Signed Messages
You must add the public key of the sender’s S/MIME certificate to the email gateway for verifying signed
messages. Depending on your organizational policies and processes, you can use one of the following methods
to add the public key to the email gateway:
• Request the sender to send their public key using an electronic channels, for example, email. You can
then add the public key using the web interface or CLI.
For instructions to add the public key, see Adding a Public Key for S/MIME Encryption, on page 561.
• Retrieve the public key using key harvesting. See Harvesting Public Keys, on page 562.
Adding a Public Key for S/MIME Verification
Before You Begin
• Make sure that the public key meets the requirements described in S/MIME Certificate Requirements,
on page 573.
• Make sure that the public key is in PEM format.
Procedure
Step 1 Click Mail Policies > Public Keys.
Step 2 Click Add Public Key.
Step 3 Enter the name of the public key.
Step 4 Enter the public key.
Step 5 Submit and commit your changes.
What to do next
Note Use the smimeconfig command to add public keys using CLI.
Harvesting Public Keys for S/MIME Verification
You can configure the email gateway to retrieve (harvest) public key from the incoming S/MIME signed
messages and use it to verify signed messages from the owner (business or consumer) of the harvested key.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
570
S/MIME Security Services
Enabling Public Key Harvesting
Note By default, public keys from expired or self-signed S/MIME certificates are not harvested.
1. Enable public key harvesting using the web interface or CLI. See Enabling Public Key Harvesting, on
page 571.
2. Request the sender to send a signed message.
3. After the harvesting is complete, add the harvested public key to the email gateway. See Adding a Harvested
Public Key for S/MIME Verification, on page 571.
This step is to ensure that the message is verified at the gateway level.
Enabling Public Key Harvesting
Procedure
Step 1 Click Mail Policies > Mail Flow Policies.
Step 2 Create a new Mail Flow Policy or modify an existing one.
Step 3 Scroll down to the Security Features section.
Step 4 Under S/MIME Public Key Harvesting, do the following:
• Enable S/MIME public key harvesting.
• (Optional) Choose whether to harvest public keys if the verification of the incoming signed messages
fail.
• (Optional) Choose whether to harvest updated public keys.
Note If an email gateway receives more than one updated public key from the same domain or message
within 48 hours, it sends out a warning alert.
Step 5 Submit and commit your changes.
What to do next
Note The size of the harvested public key repository on the email gateway is 512 MB. If the repository is full used,
the email gateway automatically removes unused public keys.
Use the listenerconfig command to enable key harvesting using CLI.
Adding a Harvested Public Key for S/MIME Verification
Procedure
Step 1 Click Mail Policies > Harvested Public Keys.
Step 2 Click on the intended harvested public key and copy the public key.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
571
S/MIME Security Services
Enabling S/MIME Decryption and Verification
Step 3 Add the public key to the email gateway. See Adding a Public Key for S/MIME Verification, on page 570.
Step 4 Submit and commit your changes.
Enabling S/MIME Decryption and Verification
Procedure
Step 1 Click Mail Policies > Mail Flow Policies.
Step 2 Create a new Mail Flow Policy or modify an existing one.
Step 3 Scroll down to the Security Features section.
Step 4 Under S/MIME Decryption/Verification, do the following:
• Enable S/MIME decryption and verification.
• Choose whether to retain or remove the digital signature from the messages after S/MIME verification.
If you do not want your end users to know about S/MIME gateway verification, select Remove.
For triple wrapped messages, only the inner signature is retained or removed.
Step 5 Submit and commit your changes.
What to do next
Tip If S/MIME Decryption and Verification is enabled in the Mail Flow Policies, all the S/MIME messages are
delivered irrespective of the status of the decryption and verification. If you want to configure an action for
handling S/MIME Decrypted or Verified Messages, you can use the message filter rules—
smime-gateway-verified and smime-gateway . For more information, see Configuring an Action for S/MIME
Decrypted or Verified Message, on page 572.
Configuring an Action for S/MIME Decrypted or Verified Message
After the email gateway performs S/MIME decryption, verification, or both, you may want to take different
actions depending on the results. You can use the message filter rules— smime-gateway-verified and
smime-gateway to perform actions on the messages based on the result of decryption, verification, or both.
For more information, see Using Message Filters to Enforce Email Policies, on page 139
Note You can also use the content filter conditions—S/MIME Gateway Message and S/MIME Gateway Verified
to perform actions on the messages based on the result of decryption, verification, or both. For more information,
see Content Filters, on page 281
Example: Quarantine S/MIME Messages that failed Verification, Decryption, or Both
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
572
S/MIME Security Services
S/MIME Certificate Requirements
The following message filter checks if the message is an S/MIME message and quarantines it if the verification
or decryption using S/MIME fails.
quarantine_smime_messages:if (smime-gateway-message and not smime-gateway-verified)
{ quarantine("Policy"); }
S/MIME Certificate Requirements
• Certificate Requirements for Signing, on page 573
• Certificate Requirements for Encryption, on page 574
Certificate Requirements for Signing
The S/MIME certificate for signing must contain the following information:
Common Name The fully qualified domain name.
Organization The exact legal name of the organization.
Organizational Unit Section of the organization.
City (Locality) The city where the organization is legally located.
State (Province) The state, county, or region where the organization is legally located.
Country The two letter ISO abbreviation of the country where the organization
is legally located.
Duration before expiration The number of days before the certificate expires.
Subject Alternative Name(Domains) Name of the domain from which you plan to send signed messages.
Examples include domain.com and *.domain.net . For multiple
entries, use a comma-separated list.
Subject Alternative Name(Email) Email address of the user who is planning to send signed messages,
for example, [email protected] . For multiple entries, use a
comma-separated list.
Private Key Size Size of the private key to generate for the CSR.
Key Usage Key usage is a restriction method that determines what a certificate
can be used for. If the key usage extension is specified, the following
bits: digitalSignature and nonRepudiation must be set.
If the key usage extension is not specified, receiving clients must
presume that the digitalSignature and nonRepudiation bits are set.
For detailed information about S/MIME certificates, see RFC 5750: Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.2 - Certificate Handling.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
573
S/MIME Security Services
Certificate Requirements for Encryption
Certificate Requirements for Encryption
The S/MIME certificate for encryption must contain the following information:
Common Name The fully qualified domain name.
Organization The exact legal name of the organization.
Organizational Unit Section of the organization.
City (Locality) The city where the organization is legally located.
State (Province) The state, county, or region where the organization is legally located.
Country The two letter ISO abbreviation of the country where the
organization is legally located.
Duration before expiration The number of days before the certificate expires.
Subject Alternative Name(Domains) Name of the domain to which you plan to send encrypted messages.
Examples include domain.com and *.domain.net . For multiple
entries, use a comma-separated list.
If you plan to send encrypted messages to all the users in a domain,
the public key should include a SAN Domain.
Subject Alternative Name(Email) Email address of the user to whom you plan to send encrypted
messages, for example, [email protected] . For multiple
entries, use a comma-separated list.
Private Key Size Size of the private key to generate for the CSR.
Key Usage Key usage is a restriction method that determines what a certificate
can be used for. The key usage extension must be specified and the
following bit must be set: keyEncipherment .
For detailed information about S/MIME certificates, see RFC 5750: Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.2 - Certificate Handling.
Managing Public Keys
the email gateway requires:
• The public key of the recipient’s S/MIME encryption certificate for encrypting the outgoing messages.
• The public key of the sender’s S/MIME signing certificate for verifying incoming signed messages.
You can add public keys to your email gateway in one of the following ways:
• If you have the intended public key in PEM format, you can add it using the web interface or CLI. See
Adding a Public Key, on page 575.
• If you have an export file that contains the intended public keys, you can copy the export file to the
/configuration directory and import it using the web interface or CLI. See Importing Public Keys from
an Existing Export File, on page 575.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
574
S/MIME Security Services
Adding a Public Key
The email gateway also supports key harvesting (automatically retrieving public keys from incoming signed
messages). For more information, see S/MIME Harvested Public Keys, on page 562.
Adding a Public Key
Before You Begin
• Make sure that the public key meets the requirements described in S/MIME Certificate Requirements,
on page 573.
• Make sure that the public key is in PEM format.
Procedure
Step 1 Click Mail Policies > Public Keys.
Step 2 Click Add Public Key.
Step 3 Enter the name of the public key.
Step 4 Enter the public key.
Step 5 Submit and commit your changes.
What to do next
Note Use the smimeconfig command to add public keys using CLI.
Importing Public Keys from an Existing Export File
Before You Begin
Copy the export file to the /configuration directory of the email gateway. For instructions to create an export
file, see Exporting Public Keys, on page 576.
Procedure
Step 1 Click Mail Policies > Public Keys.
Step 2 Click Import Public Keys.
Step 3 Select the export file and click Submit.
Note The import process may take longer if you are importing a file with large number of public keys.
Make sure that you adjust the web interface or CLI inactivity timeout accordingly.
Step 4 Commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
575
S/MIME Security Services
Exporting Public Keys
Exporting Public Keys
All public keys on the email gateway are exported together in a single text file and stored in the /configuration
directory.
Procedure
Step 1 Choose Mail Policies > Public Keys.
Step 2 Click Export Public Keys.
Step 3 Enter a name for the file and click Submit.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
576
CHAPTER 25
Remediating Messages in Mailboxes
This chapter contains the following sections:
• Overview, on page 577
• Workflow, on page 578
• Performing Remedial Actions on Messages in Mailboxes , on page 580
• Configuring Mailbox Remediation on Email Gateway, on page 586
• Upgrading to AsyncOS 13.0 and Later Releases, on page 596
• Monitoring Mailbox Remediation Results, on page 596
• Viewing Mailbox Remediation Details in Message Tracking, on page 596
• Troubleshooting Mailbox Remediation, on page 596
Overview
The email gateway provides the capability to remediate the malicious messages that are already delivered to
the user mailbox. You can configure your email gateway to remediate the messages in the following ways:
• automatically remediate the messages when the AMP sends the retrospective alert to your email gateway
• manually search and remediate the messages using the Message Tracking filter
A file can turn malicious anytime, even after it has reached user’s mailbox. AMP can identify this as new
information emerges and push retrospective alerts to your email gateway. You can configure your email
gateway to perform auto-remedial actions on the messages in user mailbox when the threat verdict changes.
For example, you can configure your email gateway to delete the message from the recipient’s mailbox when
the verdict of the attachment changes from clean to malicious.
You can also use the Message Tracking page to search and remediate the messages that are delivered to the
user mailbox. The Message Tracking page is a unified place to search for all messages delivered to the
mailboxes. From the search result, you can choose the messages you want to remediate and apply the action
you want to perform on the messages.
The email gateway can perform remedial actions(manually or automatically) on the messages in the following
mailbox deployments:
• Microsoft Exchange online – mailbox hosted on Microsoft Office 365
• Microsoft Exchange on-premise – a local Microsoft Exchange server
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
577
Remediating Messages in Mailboxes
Workflow
• Hybrid/Multiple tenant configuration – a combination of mailboxes configured across Microsoft Exchange
online and Microsoft Exchange on-premise deployments
Workflow
Mailbox Auto Remediation Workflow
1. Message with an attachment reaches the email gateway.
2. The email gateway queries the public file reputation cloud server to evaluate the reputation of the
attachment.
3. The public file reputation cloud server sends the verdict to the email gateway. The verdict is clean or
unknown.
4. The email gateway releases the message to the recipient.
5. After a certain period, the email gateway receives a verdict update from the public file reputation cloud
server. The new verdict is malicious.
6. The email gateway performs the configured remedial action on the message (with malicious attachment)
residing in the recipient’s mailbox.
Search and Remediate Messages Workflow
1. Message reaches the email gateway.
2. Message is delivered to the recipient.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
578
Remediating Messages in Mailboxes
How the Email Gateway Performs Auto-Remedial Actions
3. The administrator searches for the message delivered to the recipient using the Message Tracking filter.
4. The user selects the message to be remediated from the recipient's mailbox and applies the remedial action
on the message.
5. The email gateway performs the configured remedial action on the message residing in the recipient’s
mailbox.
How the Email Gateway Performs Auto-Remedial Actions
1. [Only to search and remediate messages] The user searches for the messages delivered to the user mailbox
using the Message Tracking filter.
2. [Only to search and remediate messages] The user selects the messages to be remediated and applies
remedial action on the messages.
3. [Only to automatically remediate messages] When the email gateway receives a retrospective verdict
from the public file reputation cloud server, the email gateway initiates the mailbox remediation process.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
579
Remediating Messages in Mailboxes
Performing Remedial Actions on Messages in Mailboxes
4. [Only to automatically remediate messages] The email gateway determines the email addresses to which
the malicious message was delivered.
5. The appliance identifies the recipient domains to which the email addresses belong.
6. Based on the recipient domains, the email gateway collects the account profile that is mapped to the
domains.
An account profile defines the mailbox settings that are used by the appliance to connect to the mailbox
and perform the auto-remedial actions. You must create an account profile and map it to the recipient
domains to successfully remediate the message from the mailbox.
7. The email gateway checks for the profile mapped to the domains:
• [Only for hybrid or multi-tenant deployment] If it is a chained profile, the email gateway attempts
to perform remedial actions using all the account profiles in the chained profile.
A chained profile is a combination of multiple account profiles. In case of a hybrid or multi-tenant
deployment, where there are mailboxes present across multiple deployments, you must create a
chained profile to combine all the profiles defined for mailboxes in the deployment. The email
gateway attempts to perform remedial actions based on the order in which the account profiles are
added in the chained profile.
• If it is not a chained profile, the email gateway checks the profile type to know if it is an Microsoft
Exchange online profile or an Microsoft Exchange on-premise profile.
8. The email gateway performs remedial actions using the identified profile and remediates the message.
Note Mailbox remediation may fail for various reasons. For more information, see Troubleshooting Mailbox
Remediation, on page 596.
Contents
• Performing Remedial Actions on Messages in Microsoft Exchange Online Mailboxes, on page 581
• Performing Remedial Actions on Messages in Microsoft Exchange On-Premise Mailboxes , on page 583
• Performing Remedial Actions on Messages in Mailboxes on Hybrid Deployment, on page 584
Performing Remedial Actions on Messages in Mailboxes
You can perform remedial actions on messages in the following mailbox deployments:
• Microsoft Exchange Online (Office 365) - Performing Remedial Actions on Messages in Microsoft
Exchange Online Mailboxes, on page 581
• Microsoft Exchange On-Premise - Performing Remedial Actions on Messages in Microsoft Exchange
On-Premise Mailboxes , on page 583
• Hybrid/Multi-tenant Deployment - Performing Remedial Actions on Messages in Mailboxes on Hybrid
Deployment, on page 584
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
580
Remediating Messages in Mailboxes
Performing Remedial Actions on Messages in Microsoft Exchange Online Mailboxes
Performing Remedial Actions on Messages in Microsoft Exchange Online
Mailboxes
You can configure your email gateway to perform remediation of messages from user mailbox.
If your organization is using Microsoft Exchange online to manage mailboxes, you can configure your email
gateway to perform auto-remedial actions on the messages in user mailbox when the threat verdict changes.
For example, you can configure your email gateway to delete the message from the recipient’s mailbox when
the verdict of the attachment changes from clean to malicious.
You can perform remedial actions manually on messages that are already delivered to the user mailbox. For
example, an administrator monitoring the incoming messages can perform remedial actions on messages in
the user mailbox using the Message Tracking filter.
Contents
• How to Configure Remedial Action on Messages in Microsoft Exchange Online Mailboxes, on page 581
How to Configure Remedial Action on Messages in Microsoft Exchange Online Mailboxes
Do This More Info
Step 1 Review the prerequisites. Prerequisites for Remediating Messages in
Microsoft Exchange Online Mailboxes, on page
586
Step 2 Register email gateway as an application on Registering Your Email Gateway as an
Azure AD (Azure Management Portal). Application on Azure AD, on page 588
Step 3 Enable the account settings on your email Enable mailbox remediation on your email
gateway. gateway.
Enabling Account Settings on Email Gateway ,
on page 590
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
581
Remediating Messages in Mailboxes
How to Configure Remedial Action on Messages in Microsoft Exchange Online Mailboxes
Do This More Info
Step 4 Create an account profile of type Office Create an Office 365 profile for the user mailbox
365/Hybrid (Graph API) on your email and define the mailbox settings on the email
gateway. gateway.
Before you begin, make sure that you have:
• The values of the following parameters -
Client ID and Tenant ID of the application
that you registered on the Azure
Management Portal. See Step 9 of
Registering Your Email Gateway as an
Application on Azure AD, on page 588.
• For Client Certificate based communication,
obtain the values of the following
parameters:
• Private key of the certificate in .pem
format. See Certificate for Secure
Communication
• Certificate thumbprint
($base64Thumbprint). See Step 8 of
Registering Your Email Gateway as an
Application on Azure AD, on page 588.
• For Client Secret based communication,
obtain the value of the generated client
secret of the application that you created on
the Azure Management Portal. See Step 8
of Registering Your Email Gateway as an
Application on Azure AD, on page 588.
See Creating an Account Profile , on page 591.
Step 5 Add the recipient domain and map the Add the domain that the recipient mailbox
domain to the Office 365 profile. belongs and map the domain to the Office 365
account profile.
See Mapping Domains to the Account Profile ,
on page 593.
Step 6 [Only to automatically remediate messages] Configure Auto-Remedial Actions on Messages
Configure your email gateway to perform in the Mailboxes, on page 594
remedial actions on messages delivered to
end users when the threat verdict changes
to malicious.
Step 7 [Only to search and remediate messages] Search and Remediate Messages in the
Configure your email gateway to perform Mailboxes, on page 594
remedial actions manually on messages
delivered to end users.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
582
Remediating Messages in Mailboxes
Performing Remedial Actions on Messages in Microsoft Exchange On-Premise Mailboxes
Performing Remedial Actions onMessages inMicrosoft Exchange On-Premise
Mailboxes
You can configure the email gateway to remediate messages from a mailbox on an Exchange on-premise
server. The messages can be remediated automatically by the email gateway or manually by the user using
the Message Tracking filter.
The email gateway uses a user account with impersonator privileges to access the Exchange on-premise
mailbox and perform remedial actions on the message. You must create this user account with impersonator
privileges on the mail exchange server to which the email gateway has to connect and remediate the message.
Note Cisco has validated Mailbox Auto Remediation only on Microsoft Exchange 2013, 2016, and 2019.
Contents
• How to Configure Remedial Actions on Messages in Microsoft Exchange On-Premise Mailboxes, on
page 583
How to Configure Remedial Actions on Messages in Microsoft Exchange On-Premise Mailboxes
Do This More Info
Step 1 Review the prerequisites. Prerequisites for Remediating Messages in an
On-Premise Account, on page 587
Step 2 Enable the account settings on your email Enable mailbox remediation on your email
gateway. gateway.
Enabling Account Settings on Email Gateway ,
on page 590
Step 3 Create an account profile of type Create an On-Premise profile for the user mailbox
On-Premise on your email gateway. and define the mailbox settings on your email
gateway.
Before you begin, make sure that you have:
• The impersonator user account details
• The host name of the local mail exchange
server
Creating an Account Profile , on page 591.
Step 4 Add the recipient domain and map the Add the domain that the recipient mailbox
domain to the On-premise account profile. belongs and map the domain to the On-premise
account profile.
See Mapping Domains to the Account Profile ,
on page 593.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
583
Remediating Messages in Mailboxes
Performing Remedial Actions on Messages in Mailboxes on Hybrid Deployment
Do This More Info
Step 5 [Only to automatically remediate messages] Configure Auto-Remedial Actions on Messages
Configure your email gateway to perform in the Mailboxes, on page 594
remedial actions on messages delivered to
end users when the threat verdict changes
to malicious.
Step 6 [Only to search and remediate messages] Search and Remediate Messages in the
Configure remedial actions on messages in Mailboxes, on page 594
the on premise mailbox.
PerformingRemedialActionsonMessagesinMailboxesonHybridDeployment
You can configure a single email gateway to remediate messages from a hybrid exchange deployment or
multiple exchange tenants. For example, if your organization is in a process of moving the mailbox from
Microsoft Exchange on-premise to Microsoft Exchange online, there will be mailboxes deployed on Microsoft
Exchange online and Microsoft Exchange on-premise until the migration is complete. The messages can be
remediated automatically by the email gateway or manually by the user using the Message Tracking filter.
To automatically remediate messages from multiple mailboxes configured across different deployments, create
a chained profile. A chained profile combines all the account profiles of a hybrid or multi-tenant deployment.
The order in which the profiles are added to the chained profile defines the priority in which the email gateway
checks the profile to remediate messages.
When the email gateway receives a retrospective verdict from the AMP server, the appliance attempts to
perform the remediation action using each profile present in the chained profile in the order of priority defined
in the chained profile.
To manually search and remediate the messages that are delivered to the user mailbox, use the Message
Tracking filter. You can use this filter to select the messages you want to remediate, configure the remedial
action, and apply the remedial action on the messages.
Contents
• How to Perform Remedial Actions on Messages in Mailboxes on Hybrid Deployment, on page 584
How to Perform Remedial Actions on Messages in Mailboxes on Hybrid Deployment
Do This More Info
Step 1 Review the prerequisites. Ensure that all the prerequisites for performing
auto-remedial actions on Microsoft Exchange
online and Microsoft Exchange on-premise
mailboxes are met for a hybrid or multi-tenant
deployment.
See Prerequisites, on page 586.
Step 2 Register email gateway as an application on Registering Your Email Gateway as an
Azure AD (Azure Management Portal). Application on Azure AD, on page 588
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
584
Remediating Messages in Mailboxes
How to Perform Remedial Actions on Messages in Mailboxes on Hybrid Deployment
Do This More Info
Step 3 Enable the account settings on your email Enable mailbox remediation on your email
gateway. gateway.
See Enabling Account Settings on Email Gateway
, on page 590.
Step 4 Create account profiles for all the mailboxes Create account profiles for the user mailboxes
in the hybrid/multi-tenant deployment. and define mailbox settings on the email gateway.
Before you begin, make sure that you have:
• The values of the following parameters -
Client ID and Tenant ID of the application
that you registered on the Azure
Management Portal. See Step 9 of
Registering Your Email Gateway as an
Application on Azure AD, on page 588.
• For Client Certificate based communication,
obtain the values of the following
parameters:
• Private key of the certificate in .pem
format. See Certificate for Secure
Communication
• Certificate thumbprint
($base64Thumbprint). See Step 8 of
Registering Your Email Gateway as an
Application on Azure AD, on page 588.
• For Client Secret based communication,
obtain the value of the generated client
secret of the application that you created on
the Azure Management Portal. See Step 8
of Registering Your Email Gateway as an
Application on Azure AD, on page 588.
• The impersonator user account details.
• The host name of the local mail exchange
server.
See Creating an Account Profile , on page 591.
Step 5 Create a chained profile. Create a chained profile and add all the profiles
of a hybrid/multi- tenant deployment.
See Creating a Chained Profile , on page 592.
Step 6 Add the recipients’ domains and map them Add the domains that the recipients’ mailboxes
to the chained profile. belong and map the domains to the chained
profile.
See Mapping Domains to the Account Profile ,
on page 593.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
585
Remediating Messages in Mailboxes
Configuring Mailbox Remediation on Email Gateway
Do This More Info
Step 7 [Only to automatically remediate messages] Configure Auto-Remedial Actions on Messages
Configure your email gateway to perform in the Mailboxes, on page 594
remedial actions on messages delivered to
end users when the threat verdict changes
to malicious.
Step 8 [Only to search and remediate messages] Search and Remediate Messages in the
Apply the remedial actions on the messages. Mailboxes, on page 594
Configuring Mailbox Remediation on Email Gateway
• Prerequisites, on page 586
• Registering Your Email Gateway as an Application on Azure AD, on page 588
• Enabling Account Settings on Email Gateway , on page 590
• Creating an Account Profile , on page 591
• Creating a Chained Profile , on page 592
• Mapping Domains to the Account Profile , on page 593
• Configure Auto-Remedial Actions on Messages in the Mailboxes, on page 594
• Search and Remediate Messages in the Mailboxes, on page 594
Prerequisites
• Prerequisites for Remediating Messages in Microsoft Exchange Online Mailboxes, on page 586
• Prerequisites for Remediating Messages in an On-Premise Account, on page 587
Prerequisites for Remediating Messages in Microsoft Exchange Online Mailboxes
• [Only for Mailbox Auto Remediation] - Feature Keys for File Reputation Service and the File Analysis
Service, on page 586
• Office 365 Accounts, on page 587
• Client Secret or Certificate for Secure Communication, on page 587
Feature Keys for File Reputation Service and the File Analysis Service
Note The File Reputation Service and the File Analysis Service feature keys are not required for performing Search
and Remediate actions on messages in the user mailbox.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
586
Remediating Messages in Mailboxes
Office 365 Accounts
To configure remedial actions for Mailbox Auto Remediation on messages in the user mailbox, make sure
that you have:
• Added the feature keys for the file reputation service and the file analysis service to you email gateway.
• Enabled File Reputation and Analysis feature on your email gateway. See File Reputation Filtering and
File Analysis, on page 481.
Office 365 Accounts
Make sure that you have the following accounts that are required to register your email gateway with Azure
AD:
• An Office 365 business account
• An Azure AD subscription associated with your Office 365 business account
For more information, contact your Office 365 administrator.
Client Secret or Certificate for Secure Communication
To secure the communication between Office 365 services and your email gateway, you must perform any
one of the following tasks:
• Generate a Client Secret of the application that you created on the Azure Management Portal.
• Set up a certificate in one of the following ways: create a self-signed certificate or obtain a certificate
from a trusted CA.
You must have:
• A public key in .crt or .p12 format. Make sure that the emailAddress is set to the email address of
the Office 365 administrator ( <admin_username>@<domain>.com )
• An associated private key in .pem format, with keysize at least 2048 bit.
Note Private keys with passphrase are not supported in this release.
For more information, see https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/
211404-How-to-configure-Azure-AD-and-Office-365.html.
Prerequisites for Remediating Messages in an On-Premise Account
• [Only for Mailbox Auto Remediation] - Feature Keys for File Reputation Service and the File Analysis
Service, on page 586
• (Optional) Import Microsoft Exchange Web Service (EWS) Certificate, on page 588
• Add a User to the Impersonator Role, on page 588
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
587
Remediating Messages in Mailboxes
Feature Keys for File Reputation Service and the File Analysis Service
Feature Keys for File Reputation Service and the File Analysis Service
Note The File Reputation Service and the File Analysis Service feature keys are not required for performing Search
and Remediate actions on messages in the user mailbox.
To configure remedial actions for Mailbox Auto Remediation on messages in the user mailbox, make sure
that you have:
• Added the feature keys for the file reputation service and the file analysis service to you email gateway.
• Enabled File Reputation and Analysis feature on your email gateway. See File Reputation Filtering and
File Analysis, on page 481.
(Optional) Import Microsoft Exchange Web Service (EWS) Certificate
If you are using a self-signed certificate on an Microsoft Exchange on-premise server for the EWS service,
you must import the certificate from the Microsoft Exchange on-premise server into the email gateway. To
import a certificate, see Importing a Certificate , on page 680.
Add a User to the Impersonator Role
The email gateway uses a user account that has impersonator privileges to access the Microsoft Exchange
on-premise mailbox. The mail exchange administrator must create a user account with impersonator privileges
on the local exchange server. The email gateway used this user account to remediate messages from the
mailbox.
Procedure
Step 1 Create a user account for which impersonator privileges must be assigned. This user account is used by the
email gateway to access and operate the mailbox to remediate the messages.
Step 2 Log in to the Microsoft Exchange Control Panel interface using administrator credentials.
Step 3 Navigate to Permissions -> Admin Roles.
Step 4 Create a role and assign the ‘ApplicationImpersonation’ privileges for the role.
Step 5 Add the user account for which the impersonator privileges must be assigned as a member of this new role.
Registering Your Email Gateway as an Application on Azure AD
Office 365 services use Azure Active Directory (Azure AD) to provide secure access to users' mailboxes. For
your email gateway to access the Office 365 mailboxes, you must register your email gateway with Azure
AD. The following are the high level steps you need to perform to register your email gateway with Azure
AD. For detailed instructions, see Microsoft documentation ( https://docs.microsoft.com/en-us/azure/
active-directory/develop/quickstart-register-app ).
Before You Begin
Perform the tasks described in Prerequisites for Remediating Messages in Microsoft Exchange Online
Mailboxes, on page 586.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
588
Remediating Messages in Mailboxes
Registering Your Email Gateway as an Application on Azure AD
Procedure
Step 1 Sign into the Azure Management Portal using your Office 365 business account credentials.
Step 2 Add a new application to the directory linked to your Office 365 subscription.
Step 3 Navigate to App Registrations > New Registration to add a new application.
Step 4 While adding a new application, make sure that you:
• Specify the application name and the account types the application must support.
• (Optional) Select the application type as Web and provide the URL where users can sign-in and use your
email gateway.
Step 5 Assign the permissions that the application requires. Click API permissions on the navigation pane and click
Add a permission.
Step 6 Select Microsoft Graph >Application permissions and assign the following permissions:
• Mail.Read – Read mail in all mailboxes
• Mail. ReadWrite - Read and write mail in all mailboxes
• Mail.Send - Send mail as any user
Step 7 Grant admin consent for all the requested permissions for all accounts in the organization.
Step 8 Secure the communication between the Office 365 services and the email gateway by performing any one of
the following tasks:
• Generate a Client Secret of the application that you created on the Azure Management Portal.
Note Make sure that you copy the client secret value because it is not displayed during a subsequent
login to the Azure Management portal.
• Update the application manifest with the key credentials from the public key certificate. Perform the
following steps:
a. Using a Windows PowerShell prompt, get the values for $base64Thumbprint , $base64Value , and
$keyid from the public key certificate. See the example below. From the Windows PowerShell
prompt, navigate to the directory containing the public key certificate and run the following:
Example
$cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cer.Import(".\mycer.cer")
$bin = $cer.GetRawCertData()
$base64Value = [System.Convert]::ToBase64String($bin)
$bin = $cer.GetCertHash()
$base64Thumbprint = [System.Convert]::ToBase64String($bin)
$keyid = [System.Guid]::NewGuid().ToString()
After running the above commands, run the following commands to extract their values:
$keyid
$base64Value
$base64Thumbprint
b. Click Manifest on left pane of the registered application pane to open the manifest of the application.
c. In the manifest text editor, replace the empty KeyCredentials property with the following JSON:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
589
Remediating Messages in Mailboxes
Enabling Account Settings on Email Gateway
Example
"keyCredentials": [
{
"customKeyIdentifier": "$base64Thumbprint_from_step_1",
"keyId": "$keyid_from_step1",
"type": "AsymmetricX509Cert",
"usage": "Verify",
"value": "$base64Value_from_step1"
}
],
Example:
In the above JSON snippet, make sure that you replace the values of $base64Thumbprint , $base64Value,
and $keyid with the values you obtained in step a. Each value must be entered in a single line
Step 9 After registering your appliance with Azure AD, note down the following details from the Azure Management
Portal from the Overview pane of the registered application:
• Client ID
• Tenant ID. The Tenant ID is the unique value that will available on all the URLs listed on this page. For
instance, the URLs listed on this page are:
• https://login.microsoftonline.com/abcd1234-bcdd-469d-8545-a0662708cbc3/
federationmetadata/2007-06/federationmetadata.xml
• https://login.microsoftonline.com/abcd1234-bcdd-469d-8545-a0662708cbc3/wsfed
• https://login.microsoftonline.com/abcd1234-bcdd-469d-8545-a0662708cbc3/saml2
In this case, the Tenant ID is abcd1234-bcdd-469d-8545-a0662708cbc3 .
What to do next
Enabling Account Settings on Email Gateway , on page 590
Enabling Account Settings on Email Gateway
Before You Begin
Make sure that you have:
• [Required only for Mailbox Auto Remediation] Enabled File Reputation and Analysis feature on your
email gateway. See File Reputation Filtering and File Analysis, on page 481.
Procedure
Step 1 Log in to the email gateway.
Step 2 Click System Administration > Account Settings.
Step 3 Click Enable.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
590
Remediating Messages in Mailboxes
Creating an Account Profile
Step 4 Select Enable Account Settings.
Step 5 (Optional) Enter the maximum number of attempts the email gateway makes to connect to the mailbox to
remediate the message. The value must be an integer from 1 to 5.
Step 6 (Optional) Enter the number of seconds the email gateway must wait before the connection times out to the
hybrid mail exchange server. The value must be an integer from 15 to 90.
Step 7 (Optional) Enter the number of seconds the email gateway must wait before the connection times out to the
local mail exchange server. The value must be an integer from 15 to 90.
Step 8 Submit and commit your changes.
What to do next
Creating an Account Profile , on page 591
Creating an Account Profile
An account profile defines the mailbox parameters that are required for the email gateway to connect to the
mailbox and perform remedial actions when the threat verdict of the message in the mailbox turns malicious.
Each profile credentials are related to one single tenant. If you want to perform remediation across multiple
tenants, then you have to configure one profile for each tenant and chain them together using a chained profile.
However, if you are using a load balancer for a multi-tenant deployment, you can still configure a single
profile and use the hostname of the load balancer while creating a profile.
Before You Begin
Make sure that you have:
• Enabled the account settings. See Enabling Account Settings on Email Gateway , on page 590.
• A valid email address in the Microsoft Exchange online or Microsoft Exchange on-premise server.
• The parameters required to configure the Microsoft Exchange online or Microsoft Exchange on-premise
account.
Procedure
Step 1 Log in to the email gateway.
Step 2 Click System Administration > Account Settings.
Step 3 Click Create Account Profile.
Step 4 Enter a name and description for the profile.
Step 5 Select the profile type based on the mailbox deployment:
• Office 365/Hybrid (Graph API) – Select this to configure a mailbox deployed on Microsoft Exchange
online and enter the following details:.
• Client ID and Tenant ID of the application that you registered on the Azure Management Portal.
• Select any one of the following methods to validate the client credentials:
• Client Secret: Select this option and enter the Client Secret of the application that you generated
on the Azure Management Portal.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
591
Remediating Messages in Mailboxes
Creating a Chained Profile
• Client Certificate: Select this option, enter the Thumbprint of the certificate (value of
$base64Thumbprint ), and click Choose File to upload the private key of the certificate in the
.pem format.
• Exchange On-premise - Select this to configure a mailbox deployed on Microsoft Exchange on-premise
and enter the following details:
• Enter the username and password of the user account with impersonator privileges. For more
information, see Add a User to the Impersonator Role, on page 588.
• Enter the hostname of the Microsoft Exchange on-premise server.
Note If you are using a load balancer for a multi-tenant deployment, you must configure the
hostname of your load balancer.
Step 6 Verify whether the email gateway can connect to the Microsoft Exchange online or Exchange on-premsie
server.
a) Click Test Connection.
b) Enter an email address. This must be a valid email address in the Microsoft Exchange online or Microsoft
Exchange on-premise.
c) Click Test Connection.
The status is displayed confirming whether your appli email gatewayance can connect to the mailbox
server.
d) 4. Click Done. For troubleshooting the errors, see Troubleshooting Mailbox Remediation, on page 596.
Step 7 Submit and commit your changes.
What to do next
• Creating a Chained Profile , on page 592
• Mapping Domains to the Account Profile , on page 593
Creating a Chained Profile
This task is mandatory only if you want to remediate messages in a mailbox on a hybrid or multi-tenant
deployments.
Before You Begin
Make sure that you have at least one account profile added on your email gateway:
Procedure
Step 1 Log in to the email gateway.
Step 2 Click System Administration > Account Settings.
Step 3 Click Create Chained Profile.
Step 4 Enter a name and description for the chained profile.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
592
Remediating Messages in Mailboxes
Mapping Domains to the Account Profile
Step 5 Select the account profile you want to add to the chained profile from the drop-down menu. To add more
profiles, click Add Account Profile.
Note • You must add the profiles in the order of priority in which you want the email gateway to check
the profile for remediating the message.
• You can create a maximum of five chained profiles at a time on your email gateway.
• You can add a maximum of 10 account profiles per chained profile.
Step 6 Submit and commit your changes.
What to do next
Mapping Domains to the Account Profile , on page 593
Mapping Domains to the Account Profile
You must define the domain to which the recipient’s mailbox belongs. The domain is then mapped to the
account profile which is used by the email gateway to remediate message in the mailbox.
Note • You can edit the domain mapping to add new domains to the existing domain mapped to the profile.
• The domain mapping is unique to a profile. Domains mapped to one profile cannot be mapped to another.
Before You Begin
Make sure that you have at least one account profile added on your email gateway.
Procedure
Step 1 Log in to the email gateway.
Step 2 Click System Administration > Account Settings.
Step 3 Click Create Domain Mapping.
Step 4 Enter the domain names separated my commas. If you want to map the profile to all the domains, type the
string ‘ALL’.
Step 5 Select the profile to be mapped to the domain(s). You can also map a chained profile to the domain(s).
Step 6 Submit and commit your changes.
What to do next
• Configure Auto-Remedial Actions on Messages in the Mailboxes, on page 594
• Search and Remediate Messages in the Mailboxes, on page 594
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
593
Remediating Messages in Mailboxes
Configure Auto-Remedial Actions on Messages in the Mailboxes
Configure Auto-Remedial Actions on Messages in the Mailboxes
Note Perform the following steps if you want to configure remedial actions for Mailbox Auto Remediation on
messages in the mailboxes.
Before You Begin
Make sure that you have enabled Mailbox Auto Remediation and configured the account settings on your
appliance. See Enabling Account Settings on Email Gateway , on page 590.
Procedure
Step 1 Select Mail Policies > Incoming Mail Policies.
Step 2 Click the link in the Advanced Malware Protection column of the mail policy to modify.
Step 3 Select Enable Mailbox Auto Remediation.
Step 4 Specify the action to be taken on messages delivered to end users when the threat verdict changes to malicious.
Depending on your requirements, choose one of the following remedial actions:
• Forward to an email address. Select this option to forward the message with malicious attachment to a
specified user, for example, an email administrator.
• Delete the message. Select this option to permanently delete the message with malicious attachment from
the end user’s mailbox.
• Forward to an email address and delete the message. Select this option to forward the message with
malicious attachment to a specified user, for example, an email administrator and permanently delete
that message from the end user’s mailbox.
Step 5 Submit and commit your changes.
What to do next
Related Topics
• Monitoring Mailbox Remediation Results, on page 596
• Viewing Mailbox Remediation Details in Message Tracking, on page 596
• Troubleshooting Mailbox Remediation, on page 596
Search and Remediate Messages in the Mailboxes
Before You Begin
• Make sure that you have enabled mailbox remediation and configured the account settings on your email
gateway. See Enabling Account Settings on Email Gateway , on page 590.
• Enable Message Tracking on your email gateway. See Enabling Message Tracking, on page 915.
• If you are using the Centralized Message Tracking service, make sure that you have enabled the trailblazer
port and AsyncOS API HTTP port on the managed email gateway and the Cisco Secure Email and Web
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
594
Remediating Messages in Mailboxes
Search and Remediate Messages in the Mailboxes
Manager can access the trailblazer port. If the trailblazer port is disabled, ensure that the Cisco Secure
Email and Web Manager can access the AsyncOS API HTTP port on the managed email gateway.
Note You can perform the following steps only in the new web interface of the email gateway.
Procedure
Step 1 Click the Email Security Appliance is getting a new look. Try it!! link on the legacy web interface. See
Accessing the Web-Based Graphical User Interface (GUI), on page 38.
Step 2 Click the Tracking tab.
Step 3 Click the Messages tab to narrow your search results. For more information, see Searching for Email Messages
on the New Web Interface, on page 919.
Step 4 Select the messages you want to remediate. You can select a maximum of 1000 messages at a time. You can
remediate the messages that are only in the delivered state.
Step 5 Click Remediate.
Step 6 Enter the following details:
• Enter a batch name for the remediation.
• Select anyone of the following remediation action:
• Delete the messages. Select this option to permanently delete the malicious messages from the end
user’s mailbox.
• Forward to an email address or multiple email addresses separated by a semicolon(;). Select this
option to forward the malicious messages to a specified user, for example, an email administrator.
• Forward to an email address or multiple email addresses separated by a semicolon(;) and delete the
messages. Select this option to forward the malicious messages to a specified user, for example, an
email administrator and permanently delete that messages from the end user’s mailbox.
Step 7 Click Apply.
After you click Apply, you can view the Remediation Report Status widget at the bottom-right corner of
the Message Tracking page. Use this widget to check the status of the Remediation Report generation. After
the Remediation Report generation is complete, click View Details on the widget to go to the Remediation
Report to view the remediation results.
Note You can also view Remediation Report directly by navigating to Reports > User Reports> Remediation Report
and click the Mailbox Search And Remediate tab.
What to do next
Related Topics
• Monitoring Mailbox Remediation Results, on page 596
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
595
Remediating Messages in Mailboxes
Upgrading to AsyncOS 13.0 and Later Releases
• Viewing Mailbox Remediation Details in Message Tracking, on page 596
• Troubleshooting Mailbox Remediation, on page 596
Upgrading to AsyncOS 13.0 and Later Releases
The mailbox settings defined in the previous AsyncOS versions are migrated seamlessly during the upgrade.
This mailbox is created with the profile name as ‘Default’ and mapped to ‘ALL’ domains. This profile can
be edited as required after the upgrade. Ensure that your application has access to Microsoft Graph API on
Azure Active Directory to remediate messages from Microsoft Exchange online mailboxes. For more
information, see Registering Your Email Gateway as an Application on Azure AD, on page 588.
Monitoring Mailbox Remediation Results
You can view the details of the mailbox remediation results using the Remediation report page. To view the
report:
1. Click the Email Security Appliance is getting a new look. Try it!! link on the legacy web interface.
2. Click the Monitoring tab.
3. Click the Reports drop-down menu and select Remediation Report.
Use this report to view the following details:
• Total number of messages attempted for remediation using Mailbox Auto Remediation and Mailbox
Search and Remediate.
• Number of messages successfully remediated for a configured remedial action.
• Number of messages for which the remediation failed.
• Details about the messages for which the remediation was attempted.
For more information, refer to the section Remediation Report Page, on page 904.
Viewing Mailbox Remediation Details in Message Tracking
You can view the details of messages remediated using Mailbox Search and Remediate in Message Tracking
page. Before you begin the remediation, ensure that the Message Tracking is enabled.
Note Messages attempted for remediation using Mailbox Auto Remediation are not included in the tracking search
results.
For more information about the data displayed, see Message Tracking Details , on page 922.
Troubleshooting Mailbox Remediation
• Connection Errors, on page 597
• Viewing Logs, on page 598
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
596
Remediating Messages in Mailboxes
Connection Errors
• Alerts, on page 599
• Configured Remedial Actions Are Not Performed, on page 599
Connection Errors
Problem
While trying to check the connection between your email gateway and recipent mailbox on the Account
Settings page (System Administration > Account Settings), you receive an error message: Connection
Unsuccessful.
Solution
Depending on the response from the server, do one of the following:
Error Message Reason and Solution
You have entered an email address that is not part of the associated
The SMTP address has no mailbox
mail domain.
associated with it Enter a valid email address and check the connection again.
The mailbox cannot be accessed Verify that:
using this profile or the
• You have the required permission to access the user mailbox. The
required permissions may be
Micrsoft Exchange online account can be accessed only using the
missing
Microsoft Graph API and the Microsoft Exchange on-premise
account using an user account with impersonator privileges.
• You have selected the incorrect profile type. Modify the profile
details on the Edit Account Profile page and check the connection
again.
Access is denied. Check The Office 365 application configured in Microsoft Azure does not
credentials and try again have the required permission to access the Microsoft Exchange online
mailbox.
You have entered an invalid Client ID.
Application with identifier
'<client_id>' was not found in Modify the Client ID on the Account Profile page and check the
the connection again.
directory <tenant_id>
You have entered an invalid Tenant ID.
No service namespace named
'<tenant_id>' was found in the Modify the Tenant ID on the Account Profile page and check the
connection again.
data store.
You have entered an invalid certificate thumbprint.
Error validating credentials.
Credential Modify the certificate thumbprint on the Account Profile page and
validation failed check the connection again.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
597
Remediating Messages in Mailboxes
Viewing Logs
Error Message Reason and Solution
You have entered an incorrect certificate thumbprint or you have
Error validating credentials.
uploaded an invalid or incorrect certificate private key.
Client assertion
contains an invalid signature. Verify that:
• You have entered the correct thumbprint.
• You have uploaded the correct certificate private key.
• The certificate private key is not expired.
• The time zone of your email gateway matches the time zone in
the certificate private key.
The requested user <email The email address entered does not match with the profile type of the
address> is invalid account profile. Enter a valid email address or modify the account
profile on the Account Profile page and check the connection again.
Failed to verify exchange • You have entered an invalid CA or self-signed certificate on the
server(‘<host name>’) Microsoft Exchange on-premise server. Verify the certificate and
certificate. If self-signed check the connection again.
certificate is used on exchange
Note Ensure that the certificate you are using corresponds
server install its custom CA
to the hostname provided in the profile. For example,
certificate
if you have provided the IP address of the exchange
server in your profile setting and the certificate is based
on the hostname, then the connection will fail.
• You have not imported the self-signed certificate from the
Microsoft Exchange on-premise server to your email gateway.
For more information, see Importing a Certificate , on page 680.
Invalid username or password You have entered an invalid user name or password for the
entered for exchange server impersonator user account that is used to connect to the Microsoft
(‘<email address>’) Exchange on-premise mailbox.)
The account does not have The user account used to connect to the Microsoft Exchange on-premise
permission to impersonate the mailbox is not a member of the impersonator role (does not have
requested user impersonator privileges).
Please check host <hostname> You have entered an incorrect hostname of the Microsoft Exchange
is valid exchange server on-premise server. Modify the hostname on the Account Profile page
address. and check the connection again.
Viewing Logs
Mailbox remediation information is posted to the following logs:
• Mail Logs ( mail_logs ). The time at which the mailbox remediation process started is posted to this log.
Information about Mailbox Auto Remediation or Mailbox Search and Remediate action:
• The time at which the mailbox remediation process started is posted to this log.
• The remediation status.
• The reason for the unsuccessful remediation.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
598
Remediating Messages in Mailboxes
Alerts
• The recipients for whom the remediation was successful and unsuccessful.
• The source from which the Search and Remediate action is initiated.
• The user who initiated the Search and Remediate action.
• The remedial action attempted on the messages.
• Remediation Logs. Information related to remediation status, actions performed, errors and so on are
posted to this log.
Alerts
Alert: Connectivity Issues Between Email Gateway and Microsoft Exchange Services Detected
Problem
You receive an info-level alert indicating that there are connectivity issues between your email gateway and
Microsoft Exchange online or Microsoft Exchange on-premise services and the email gateway is unable to
perform the configured remedial action.
Solution
Do the following:
• Check for network issues that might prevent the communication between your email gateway and
Microsoft Exchange online or Microsoft Exchange on-premise services.
Review the network settings of your email gateway. See Changing Network Settings, on page 1066.
• Ensure that your application has access to Microsoft Graph API on Azure Active Directory.
• Ensure that the user account used to access the Exchange on-premise mailbox has impersonator privileges.
• Verify that the parameters configured in the corresponding profiles are valid and test the connection.
• Check for firewall issues. See Firewall Information, on page 1325.
• Check whether the Microsoft Exchange online or Microsoft Exchange on-premise services are operational.
Configured Remedial Actions Are Not Performed
Problem
After receiving a retrospective alert from the AMP server, configured remedial actions are not performed on
the malicious messages in Exchange online and Exchange on-premise mailboxes.
Or
The user is unable to remediate the messages manually using the Remediate option on the Message Tracking
page.
Solution
Do the following:
• Test the connection between your email gateway and Exchange online and Exchange on-premise services.
See Creating an Account Profile , on page 591.
• [Only for Mailbox Auto Remediation] Check whether you have received the following alert: Connectivity
Issues Between Email Gateway and Exchange online and Exchange on-premise Services Detected. See
Alerts, on page 599.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
599
Remediating Messages in Mailboxes
Configured Remedial Actions Are Not Performed
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
600
CHAPTER 26
Email Authentication
This chapter contains the following sections:
• Email Authentication Overview, on page 601
• Configuring DomainKeys and DKIM Signing, on page 603
• How to Verify Incoming Messages Using DKIM, on page 616
• Overview of SPF and SIDF Verification, on page 622
• How to Verify Incoming Messages Using SPF/SIDF, on page 623
• Enabling SPF and SIDF, on page 624
• Determining the Action to Take for SPF/SIDF Verified Mail, on page 628
• Testing the SPF/SIDF Results, on page 631
• DMARC Verification, on page 632
• Forged Email Detection, on page 640
Email Authentication Overview
AsyncOS supports email verification and signing to prevent email forgery. To verify incoming mail, AsyncOS
supports Sender Policy Framework (SPF), Sender ID Framework (SIDF), DomainKeys Identified Mail
(DKIM), Domain-based Message Authentication, Reporting and Conformance (DMARC), and Forged Email
Detection. To authenticate outbound mail, AsyncOS supports DomainKeys and DKIM signing.
Related Topics
• DomainKeys and DKIM Authentication, on page 601
• Overview of SPF and SIDF Verification, on page 622
• DMARC Verification, on page 632
• Forged Email Detection, on page 640
DomainKeys and DKIM Authentication
With DomainKeys or DKIM email authentication, the sender signs the email using public key cryptography.
The verified domain can then be used to detect forgeries by comparing it with the domain in the From: (or
Sender:) header of the email.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
601
Email Authentication
DomainKeys and DKIM Authentication Workflow
DomainKeys and DKIM consist of two main parts: signing and verification. AsyncOS supports the “signing”
half of the process for DomainKeys, and it supports both signing and verification for DKIM. You can also
enable bounce and delay messages to use DomainKeys and DKIM signing.
Related Topics
• DomainKeys and DKIM Authentication Workflow, on page 602
• DomainKeys and DKIM Signing in AsyncOS, on page 602
DomainKeys and DKIM Authentication Workflow
Figure 36: Authentication Work Flow
1. Administrator (domain owner) publishes a public key into the DNS name space.
2. Administrator loads a private key in the outbound Mail Transfer Agent (MTA).
3. Email submitted by an authorized user of that domain is digitally signed with the respective private key.
The signature is inserted in the email as a DomainKey or DKIM signature header and the email is
transmitted.
4. Receiving MTA extracts the DomainKeys or DKIM signature from the header and the claimed sending
domain (via the Sender: or From: header) from the email. The public key is retrieved from the claimed
signing domain which is extracted from DomainKeys or DKIM signature header fields.
5. The public key is used to determine whether the DomainKeys or DKIM signature was generated with the
appropriate private key.
To test your outgoing DomainKeys signatures, you can use a Yahoo! or Gmail address, as these services are
free and provide validation on incoming messages that are DomainKeys signed.
DomainKeys and DKIM Signing in AsyncOS
DomainKeys and DKIM signing in AsyncOS is implemented via domain profiles and enabled via a mail flow
policy (typically, the outgoing “relay” policy). For more information, see the “Configuring the Gateway to
Receive Mail” chapter. Signing the message is the last action performed by the email gateway before the
message is sent.
Domain profiles associate a domain with domain key information (signing key and related information). As
email is sent via a mail flow policy on the email gateway, sender email addresses that match any domain
profile are DomainKeys signed with the signing key specified in the domain profile. If you enable both DKIM
and DomainKeys signing, the DKIM signature is used. You implement DomainKeys and DKIM profiles via
the domainkeysconfig CLI command or via the Mail Policies > Domain Profiles and the Mail Policies >
Signing Keys pages in the GUI.
DomainKeys and DKIM signing works like this: a domain owner generates two keys — a public key stored
in the public DNS (a DNS TXT record associated with that domain) and a private key that is stored on the
email gateway is used to sign mail that is sent (mail that originates) from that domain.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
602
Email Authentication
Configuring DomainKeys and DKIM Signing
As messages are received on a listener used to send messages (outbound), the email gateway checks to see if
any domain profiles exist. If there are domain profiles created on the email gateway (and implemented for
the mail flow policy), the message is scanned for a valid Sender: or From: address. If both are present, the
Sender: header is always used for Domain Keys and DKIM Signing, but the From: header is also required
even though it is not used for DKIM signing. When only the Sender: header is present, the DomainKeys or
DKIM Signing profiles are not matched. The From: header is only used when:
• There is no Sender: header.
• You select the Use From Header for DKIM Signing option in the DKIM Global Setting page in the web
interface.
Note From Async0S 10.0 and later, you can select whether you want to use the From: header for DKIM Signing
option in the DKIM Global Settings page of the web interface. It is mainly important to use the From: header
with DKIM Signing for proper DMARC verification.
If a valid address is not found, the message is not signed and the event is logged in the mail_logs.
Note If you create both a DomainKey and DKIM profile (and enable signing on a mail flow policy), AsyncOS
signs outgoing messages with both a DomainKeys and DKIM signature.
If a valid sending address is found, the sending address is matched against the existing domain profiles. If a
match is found, the message is signed. If not, the message is sent without signing. If the message has an
existing DomainKeys (a “DomainKey-Signature:” header) the message is only signed if a new sender address
has been added after the original signing. If a message has an existing DKIM signature, a new DKIM signature
is added to the message.
AsyncOS provides a mechanism for signing email based on domain as well as a way to manage (create new
or input existing) signing keys.
The configuration descriptions in this document represent the most common uses for signing and verification.
You can also enable DomainKeys and DKIM signing on a mail flow policy for inbound email, or enable
DKIM verification on a mail flow policy for outbound email.
Note When you configure domain profiles and signing keys in a clustered environment, note that the Domain Key
Profile settings and Signing Key settings are linked. Therefore, if you copy, move or delete a signing key, the
same action is taken on the related profile.
Configuring DomainKeys and DKIM Signing
Related Topics
• Signing Keys, on page 604
• Public Keys, on page 604
• Domain Profiles, on page 605
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
603
Email Authentication
Signing Keys
• Enabling Signing for Bounce and Delay Messages, on page 606
• Enabling Signing for Outgoing Mail, on page 606
• Configuring DomainKeys/DKIM Signing (GUI), on page 607
• Domain Keys and Logging, on page 616
Signing Keys
A signing key is the private key stored on the email gateway. When creating a signing key, you specify a key
size. Larger key sizes are more secure; however, larger keys also can impact performance. The email gateway
supports keys from 512 bits up to 2048 bits. The 768 - 1024 bit key sizes are considered secure and used by
most senders today. Keys based on larger key sizes can impact performance and are not supported above 2048
bits. For more information about creating signing keys, see Creating or Editing a Signing Key, on page 610.
If you are entering an existing key, simply paste it into the form. Another way to use existing signing keys is
to import the key as a text file. For more information about adding existing signing keys, see Importing or
Entering Existing Signing Keys , on page 611.
Once a key is entered, it is available for use in domain profiles, and will appear in the Signing Key drop-down
list in the domain profile.
Related Topics
• Exporting and Importing Signing Keys, on page 604
Exporting and Importing Signing Keys
You can export your signing keys to a text file on the email gateway. When you export keys, all of the keys
currently existing on the email gateway are put into a text file. For more information about exporting keys,
see Exporting Signing Keys, on page 611.
You can import keys that have been exported as well.
Note Importing keys causes all of the current keys on the email gateway to be replaced.
For more information, see Importing or Entering Existing Signing Keys , on page 611.
Public Keys
Once you have associated a signing key with a domain profile, you can create DNS text record which contains
your public key. You do this via the Generate link in the DNS Text Record column in the domain profile
listing (or via domainkeysconfig -> profiles -> dnstxt in the CLI):
For more information about generating a DNS Text Record, see Generating a DNS Text Record , on page
613.
You can also view the public key via the View link on the Signing Keys page:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
604
Email Authentication
Domain Profiles
Figure 37: View Public Key Link on Signing Keys Page
Domain Profiles
A domain profile associates a sender domain with a signing key, along with some other information needed
for signing.
• A name for the domain profile.
• A domain name (the domain to be included in the “d=” header).
• A selector (a selector is used to form the query for the public key. In the DNS query type, this value is
prepended to the “_domainkey.” namespace of the sending domain).
• A canonicalization method (the method by which the headers and content are prepared for presentation
to the signing algorithm). AsyncOS supports both “simple” and “nofws” for DomainKeys and “relaxed”
and “simple” for DKIM.
• A signing key (see Signing Keys, on page 604 for more information).
• A list of headers and the body length to sign (DKIM only).
• A list of tags you want to include in the signature’s header (DKIM only). These tags store the following
information:
• The identity of the user or agent (e.g., a mailing list manager) on whose behalf the message is signed.
• A comma-separated list of query methods used to retrieve the public key.
• The timestamp of when the signature was created.
• The expiration time of the signature, in seconds.
• A vertical bar-separated (i.e., | ) list of header fields present when the message was signed.
• The tags you want to include in the signature (DKIM only).
• A list of Profile Users (addresses allowed to use the domain profile for signing).
Note The domain in the addresses specified in the profile users must match the domain specified in the Domain
field.
You can search through all of your existing domain profiles for a specific term. See Searching Domain Profiles,
on page 615 for more information.
Additionally, you can choose whether to:
• Sign system-generated messages with DKIM signatures
• Use From header for DKIM signing
For instructions, see Editing DKIM Global Settings, on page 615.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
605
Email Authentication
Exporting and Importing Domain Profiles
Related Topics
• Exporting and Importing Domain Profiles, on page 606
Exporting and Importing Domain Profiles
You can export your existing domain profiles to a text file on the email gateway. When you export the domain
profiles, all of the profiles existing on the email gateway are put into a single text file. See Exporting Domain
Profiles, on page 614.
You can import domain profiles that you have previously exported. Importing domain profiles causes all of
the current domain profiles on the machine to be replaced. See Importing Domain Profiles, on page 614.
Enabling Signing for Outgoing Mail
DomainKeys and DKIM signing is enabled on mail flow policies for outbound mail. For more information,
see the “Configuring the Gateway to Receive Mail” chapter.
Procedure
Step 1 On the Mail Flow Policies page (from the Mail Policies menu), click on the RELAYED mail flow policy
(outgoing).
Step 2 From the Security Features section, enable DomainKeys/DKIM Signing by selecting On.
Step 3 Submit and commit your changes.
Enabling Signing for Bounce and Delay Messages
In addition to signing outbound messages, you may want to sign bounce and delay messages. You may want
to do this to alert recipients that the bounce and delay messages they receive from your company are legitimate.
To enable DomainKeys and DKIM signing for bounce and delay messages, you enable DomainKeys/DKIM
signing for the bounce profile associated with the public listener.
Procedure
Step 1 On the bounce profile associated with the public listener where you will send signed outbound messages, go
to Hard Bounce and Delay Warning Messages.
Step 2 Enable “Use Domain Key Signing for Bounce and Delay Messages”:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
606
Email Authentication
Configuring DomainKeys/DKIM Signing (GUI)
Note You must have completed all steps listed in Configuring DomainKeys/DKIM Signing (GUI), on
page 607 to sign bounced and delay messages.
The From: address in the domain profile must match the address used for the bounce return address.
To ensure these addresses match, you can configure a return address for the bounce profile (System
Administration > Return Addresses), and then use the same name in the Profile Users list in the
domain profile. For example, you would configure a return address of
[email protected] for the bounce return address, and add
[email protected] as a profile user in the domain profile.
Configuring DomainKeys/DKIM Signing (GUI)
Procedure
Step 1 Create a new or import an existing private key. For information on creating or importing signing keys, see
Signing Keys, on page 604.
Step 2 Create a domain profile and associate the key with the domain profile. For information on creating a domain
profile, see Domain Profiles, on page 605.
Step 3 Create the DNS text record. For information about creating the DNS text record, see Generating a DNS Text
Record , on page 613.
Step 4 If you have not already done so, enable DomainKeys/DKIM signing on a mail flow policy for outbound mail
(see Enabling Signing for Outgoing Mail, on page 606).
Step 5 Optionally, enable DomainKeys/DKIM signing for bounced and delay messages. For information about
enabling signing for bounce and delay messages, see Enabling Signing for Bounce and Delay Messages, on
page 606.
Step 6 Send email. Mail sent from a domain that matches a domain profile will be DomainKeys/DKIM signed. In
addition, bounce or delay messages will be signed if you configured signing for bounce and delay messages.
Note If you create both a DomainKey and DKIM profile (and enable signing on a mail flow policy),
AsyncOS signs outgoing messages with both a DomainKeys and DKIM signature.
What to do next
Related Topics
• Creating Domain Profiles for DomainKeys Signing, on page 608
• Creating a New Domain Profile for DKIM Signing, on page 608
• Creating or Editing a Signing Key, on page 610
• Importing or Entering Existing Signing Keys , on page 611
• Testing Domain Profiles, on page 613
• Editing DKIM Global Settings, on page 615
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
607
Email Authentication
Creating Domain Profiles for DomainKeys Signing
Creating Domain Profiles for DomainKeys Signing
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 In the Domain Signing Profiles section, click Add Profile.
Step 3 Enter a name for the profile.
Step 4 For the Domain Key Type, choose Domain Keys.
Additional options appear on the page.
Step 5 Enter the domain name.
Step 6 Enter a selector. Selectors are arbitrary names prepended to the "_domainkey" namespace, used to help support
multiple concurrent public keys per sending domain. A selector value and length must be legal in the DNS
namespace and in email headers with the additional provision that they cannot contain a semicolon.
Step 7 Select the canonicalization (no forwarding whitespaces or simple).
Step 8 If you have already created a signing key, select a signing key. Otherwise, skip to the next step. You must
create (or import) at least one signing key in order to have signing keys to choose from in the list. See Creating
or Editing a Signing Key, on page 610.
Step 9 Enter users (email addresses, hosts, etc.) that will use the domain profile for signing.
Step 10 Submit and commit your changes.
Step 11 At this point (if you have not already) you should enable DomainKeys/DKIM signing on an outgoing mail
flow policy (see Enabling Signing for Outgoing Mail, on page 606).
Note If you create both a DomainKeys and DKIM profile, AsyncOS performs both DomainKeys and
DKIM signing on outgoing mail.
Creating a New Domain Profile for DKIM Signing
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 In the Domain Signing Profiles section, click Add Profile.
Step 3 Enter a name for the profile.
Step 4 For the Domain Key Type, choose DKIM.
Additional options appear on the page.
Step 5 Enter the domain name.
Step 6 Enter a selector. Selectors are arbitrary names prepended to the "_domainkey." namespace, used to help
support multiple concurrent public keys per sending domain. A selector value and length must be legal in the
DNS namespace and in email headers with the additional provision that they cannot contain a semicolon.
Step 7 Select the canonicalization for the header. Choose from the following options:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
608
Email Authentication
Creating a New Domain Profile for DKIM Signing
• Relaxed. The “relaxed” header canonicalization algorithm performs the following: header names are
changed to lowercase, headers are unfolded, linear white spaces are reduced to a single space, leading
and trailing spaces are stripped.
• Simple. No changes to headers are made.
Step 8 Select the canonicalization for the body. Choose from the following options:
• Relaxed. The “relaxed” header canonicalization algorithm performs the following: empty lines are
stripped at the end of the body, white spaces are reduced to a single space within lines, and trailing white
spaces are stripped in lines.
• Simple. Empty lines at the end of the body are stripped.
Step 9 If you have already created a signing key, select a signing key. Otherwise, skip to the next step. You must
create (or import) at least one signing key in order to have signing keys to choose from in the list. See Creating
or Editing a Signing Key, on page 610.
Step 10 Select the list of headers to sign. You can select from the following headers:
• All. AsyncOS signs all the headers present at the time of signature. You may want to sign all headers if
you do not expect headers to be added or removed in transit.
• Standard. You may want to select the standard headers if you expect that headers may be added or
removed in transit. AsyncOS signs only the following standard headers (if the header is not present in
the message, the DKIM signature indicates a null value for the header):
• From
• Sender, Reply To-
• Subject
• Date, Message-ID
• To, Cc
• MIME-Version
• Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description
• Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-cc, Resent-Message-ID
• In-Reply-To, References
• List-Id, List-Help, List-Unsubscribe, LIst-Subscribe, List-Post, List-Owner, List-Archive
Note When you select “Standard”, you can add additional headers to sign.
Step 11 Specify how to sign the message body. You can choose to sign the message body, and/or how many bytes to
sign. Select one of the following options:
• Whole Body Implied. Do not use the “l=” tag to determine body length. The entire message is signed
and no changes are allowed.
• Whole Body Auto-determined. The entire message body is signed, and appending some additional data
to the end of body is allowed during transit.
• Sign first _ bytes. Sign the message body up to the specified number of bytes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
609
Email Authentication
Creating or Editing a Signing Key
Step 12 Select the tags you want to include in the message signature’s header field. The information stored in these
tags are used for message signature verification. Select one or more of the following options:
• “i” Tag. The identity of the user or agent (e.g., a mailing list manager) on behalf of which this message
is signed. Enter the domain name prepended with the @ symbol, such as the domain @example.com .
• “q” Tag. A colon-separated list of query methods used to retrieve the public key. Currently, the only
valid value is dns/txt.
• “t” Tag. A timestamp for when the signature was created.
• “x” Tag. The absolute date and time when the signature expires. Specify an expiration time (in seconds)
for the signature. The default is 31536000 seconds.
• “z” Tag. A vertical bar-separated (i.e., | ) list of header fields present when the message was signed. This
includes the names of the header fields and their values. For example:
z=From:[email protected]|To:[email protected]|
Subject:test%20message|Date:Date:August%2026,%202011%205:30:02%20PM%20-0700
Step 13 Enter users (email addresses, hosts, etc.) that will use the domain profile for signing.
Note When you create domain profiles, be aware that a hierarchy is used in determining the profile to
associate with a particular user. For example, you create a profile for example.com and another
profile for [email protected]. When mail is sent from [email protected], the profile for
[email protected] is used. However, when mail is sent from [email protected], the profile for
example.com is used.
Step 14 Submit and commit your changes.
Step 15 At this point (if you have not already) you should enable DomainKeys/DKIM signing on an outgoing mail
flow policy (see Enabling Signing for Outgoing Mail, on page 606).
Note If you create both a DomainKeys and DKIM profile, AsyncOS performs both DomainKeys and
DKIM signing on outgoing mail.
Creating or Editing a Signing Key
• Create a New Signing Key, on page 610
• Edit an Existing Signing Key, on page 611
Create a New Signing Key
Signing keys are required for domain profiles for DomainKeys and DKIM signing.
Procedure
Step 1 Choose Mail Policies > Signing Keys.
Step 2 Click Add Key.
Step 3 Enter a name for the key.
Step 4 Click Generate and select a key size.
Step 5 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
610
Email Authentication
Edit an Existing Signing Key
Note If you have not done so already, you may need to edit your domain profile to assign the key.
Edit an Existing Signing Key
Procedure
Step 1 Choose Mail Policies > Signing Keys.
Step 2 Click the intended signing key.
Step 3 Edit the intended fields as described in Create a New Signing Key, on page 610.
Step 4 Submit and commit your changes.
Exporting Signing Keys
All keys on the email gateway are exported together in a single text file.
Procedure
Step 1 Choose Mail Policies > Signing Keys.
Step 2 Click Export Keys.
Step 3 Enter a name for the file and click Submit.
Importing or Entering Existing Signing Keys
Related Topics
• Pasting a Key , on page 611
• Importing Keys from an Existing Export File , on page 612
Pasting a Key
Procedure
Step 1 Choose Mail Policies > Signing Keys.
Step 2 Click Add Key.
Step 3 Paste the key into the Paste Key field (must be PEM-formatted and must be RSA keys only).
Step 4 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
611
Email Authentication
Importing Keys from an Existing Export File
Importing Keys from an Existing Export File
Note To obtain a key file, see Exporting Signing Keys, on page 611.
Procedure
Step 1 Choose Mail Policies > Signing Keys.
Step 2 Click Import Keys.
Step 3 Select the file that contains the exported signing keys.
Step 4 Click Submit. You are warned that importing will replace all existing signing keys. All of the keys in the text
file are imported.
Step 5 Click Import.
Deleting Signing Keys
Related Topics
• Removing Selected Signing Keys , on page 612
• Removing All Signing Keys , on page 612
Removing Selected Signing Keys
Procedure
Step 1 Choose Mail Policies > Signing Keys.
Step 2 Mark the checkbox to the right of each signing key to remove.
Step 3 Click Delete.
Step 4 Confirm the deletion.
Removing All Signing Keys
Procedure
Step 1 Choose Mail Policies > Signing Keys.
Step 2 Click Clear All Keys on the Signing Keys page.
Step 3 Confirm the deletion.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
612
Email Authentication
Generating a DNS Text Record
Generating a DNS Text Record
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 In the Domain Signing Profiles section, in the DNS Text Record column, click the Generate link for the
corresponding domain profile.
Step 3 Mark the checkbox for the attributes you wish to include in the DNS text record.
Step 4 Click Generate Again to re-generate the key with any changes you have made.
Step 5 The DNS text record is displayed in the text field at the bottom of the window (where you can now copy it).
In some cases, multi-string DNS text records are generated. See Multi-string DNS Text Records, on page 613.
Step 6 Click Done.
What to do next
Related Topics
• Multi-string DNS Text Records, on page 613
Multi-string DNS Text Records
Multi-string DNS text records may be generated if the key size of the signing key used to generate the DNS
text records are larger than 1024 bits. This is because not more than 255 characters are allowed in a single
string of a DNS text record. The DKIM authentication may fail as some of the DNS servers do not accept or
serve multi-string DNS text records.
To avoid this scenario, it is recommended that you use double quotes to break up the multi-string DNS text
record into smaller strings not exceeding 255 bytes. The following is an example.
s._domainkey.domain.com. IN TXT "v=DKIM1;"
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE"
"A4Vbhjq2n/3DbEk6EHdeVXlIXFT7OEl81amoZLbvwMX+bej"
"CdxcsFV3uS7G8oOJSWBP0z++nTQmy9ZDWfaiopU6k7tzoi"
"+oRDlKkhCQrM4oP2B2F5sTDkYwPY3Pen2jgC2OgbPnbo3o"
"m3c1wMWgSoZxoZUE4ly5kPuK9fTtpeJHNiZAqkFICiev4yrkL"
"R+SmFsJn9MYH5+lchyZ74BVm+16Xq2mptWXEwpiwOxWI"
"YHXsZo2zRjedrQ45vmgb8xUx5ioYY9/yBLHudGc+GUKTj1i4"
"mQg48yCD/HVNfsSRXaPinliEkypH9cSnvgvWuIYUQz0dHU;"
DKIM implementations reassemble DNS text records broken down this way into the full original single string
before processing them.
Testing Domain Profiles
Once you have created a signing key, associated it with a domain profile, and generated and inserted the DNS
text into your authorized DNS, you can test your domain profile.
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
613
Email Authentication
Exporting Domain Profiles
Step 2 In the Domain Signing Profiles section, in the Test Profile column, click the Test link for the domain profile.
Step 3 A message is displayed at the top of the page, indicating success or failure. If the test fails, a warning message
is displayed, including the error text.
Exporting Domain Profiles
All domain profiles on the email gateway are exported together in a single text file.
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 Click Export Domain Profiles.
Step 3 Enter a name for the file and click Submit.
Importing Domain Profiles
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 Click Import Domain Profiles.
Step 3 Select the file that contains the exported domain profiles.
Step 4 Click Submit. You are warned that importing will replace all existing domain profiles. All of the domain
profiles in the text file are imported.
Step 5 Click Import.
Deleting Domain Profiles
Related Topics
• Removing Selected Domain Profiles , on page 614
• Removing All Domain Profiles , on page 615
Removing Selected Domain Profiles
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 Mark the checkbox to the right of each domain profile to remove.
Step 3 Click Delete.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
614
Email Authentication
Removing All Domain Profiles
Step 4 Confirm the deletion.
Removing All Domain Profiles
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 Click Clear All Profiles.
Step 3 Confirm the deletion.
Searching Domain Profiles
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 In the Find Domain Profiles section, specify the search term.
Step 3 Click Find Profiles.
Step 4 The search scans the following fields for each domain profile: email, domain, selector, and signing key name.
Note If you do not enter search terms, the search engine returns all domain profiles.
Editing DKIM Global Settings
You can use the DKIM Global Settings to choose whether to:
• Sign system-generated messages with a DKIM signature. The email gateway will sign the following
messages:
• Cisco IronPort Spam Quarantine notifications
• Content filter-generated notifications
• Configuration messages
• Support requests
• Use From header for DKIM signing
Procedure
Step 1 Choose Mail Policies > Signing Profiles.
Step 2 Under DKIM Global Settings, click Edit Settings.
Step 3 Depending on your requirements, configure the following fields:
• DKIM Signing of System Generated Messages
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
615
Email Authentication
Domain Keys and Logging
• Use From header for DKIM Signing
Note If you are not using From header for DKIM signing or if a valid From header is missing, Sender
header will be used. For DMARC verification of DKIM signed messages, you must use the From
header during DKIM signing.
Step 4 Submit and commit your changes.
Domain Keys and Logging
Lines such as the following are added to the mail logs upon DomainKeys signing:
Tue Aug 28 15:29:30 2007 Info: MID 371 DomainKeys: signing with dk-profile - matches
[email protected]
Tue Aug 28 15:34:15 2007 Info: MID 373 DomainKeys: cannot sign - no profile matches
[email protected]
Lines such as these are added to the mail logs upon DKIM signing:
Tue Aug 28 15:29:54 2007 Info: MID 372 DKIM: signing with dkim-profile - matches
[email protected]
Tue Aug 28 15:34:15 2007 Info: MID 373 DKIM: cannot sign - no profile matches
[email protected]
How to Verify Incoming Messages Using DKIM
How to Verify Incoming Messages Using DKIM
Do This More Info
Step 1 Create a profile for verifying messages using DKIM. Creating a DKIM Verification Profile, on
page 618
Step 2 (Optional) Create a custom mail flow policy to use Defining Rules for Incoming Messages
for verifying incoming messages using DKIM. Using a Mail Flow Policy, on page 115
Step 3 Configure your mail flow policies to verify incoming Configuring DKIM Verification on the
messages using DKIM. Mail Flow Policy, on page 620
Step 4 Define the action that the email gateway takes on Configuring an Action for DKIM Verified
verified messages. Mail, on page 621
Step 5 Associate the action with groups of specific senders Configuring Mail Policies, on page 273
or recipients.
Related Topics
• DKIM Verification Checks Performed by AsyncOS, on page 617
• Managing DKIM Verification Profiles, on page 617
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
616
Email Authentication
DKIM Verification Checks Performed by AsyncOS
• Configuring DKIM Verification on the Mail Flow Policy, on page 620
• Configuring an Action for DKIM Verified Mail, on page 621
DKIM Verification Checks Performed by AsyncOS
When you configure an AsyncOS email gateway for DKIM verification, the following checks are performed:
Procedure
Step 1 AsyncOS checks for the DKIM-Signature field in incoming mail, the syntax of the signature header, valid
tag values, and required tags. If the signature fails any of these checks, AsyncOS returns a permfail .
Step 2 After the signature check is performed, the public key is retrieved from the public DNS record, and the TXT
record is validated. If errors are encountered during this process, AsyncOS returns a permfail . A tempfail
occurs if the DNS query for the public key fails to get a response.
Step 3 After retrieving the public key, AsyncOS checks the hashed values and verifies the signature. If any failures
occur during this step, AsyncOS returns a permfail .
Step 4 If the checks all pass, AsyncOS returns a pass .
Note When the message body is greater than the specified length, AsyncOS returns the following verdict:
dkim = pass (partially verified [x bytes])
where X represents the number of bytes verified.
The final verification result is entered as an Authentication-Results header. For example, you might get a
header that looks like one of the following:
Authentication-Results: example1.com
header.from=From:[email protected]; dkim=pass (signature verified)
Authentication-Results: example1.com
header.from=From:[email protected]; dkim=pass (partially verified [1000 bytes])
Authentication-Results: example1.com
header.from=From:[email protected]; dkim=permfail (body hash did not verify)
Note Current DKIM verification stops at the first valid signature. It is not possible to verify using the last
signature encountered. This functionality may be available in a later release.
When the domain has its DNS TXT record in DKIM Test Mode (t=y), the email gateway completely
skips any DKIM Verifications and Actions.
Managing DKIM Verification Profiles
A DKIM verification profile is a list of parameters that the email gateway's mail flow policies use for verifying
DKIM signatures. For example, you can create two verification profiles, one that allows 30 seconds before a
query times out and a second that allows only 3 seconds before a query times out. You can assign the second
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
617
Email Authentication
Creating a DKIM Verification Profile
verification profile to the Throttled mail flow policy to prevent connection starvation in case of a DDoS. A
verification profile consists of the following information:
• A name for the verification profile.
• The smallest and largest acceptable public key size. The default key sizes are 512 and 2048, respectively.
• The maximum number of signatures in the message to verify. If a message has more signatures than the
maximum amount you defined, the email gateway skips verification of the remaining signatures and
continues to process the message. The default is 5 signatures.
• The maximum allowed difference in time (in seconds) between the sender’s system time and verifier’s.
For example, if the message signature expires at 05:00:00 and the verifier’s system time is 05:00:30, the
message signature is still valid if the allowed difference in time is 60 seconds but it is invalid if the
allowed difference is 10 seconds. The default is 60 seconds.
• An option whether to use a body length parameter.
• The SMTP action to take in case of a temporary failure.
• The SMTP action to take in case of a permanent failure.
You can search through all of your existing verification profiles by the profile name.
You can export your DKIM verification profiles as a text file in your email gateway's configure directory.
When you export the verification profiles, all of the profiles existing on the email gateway are put into a single
text file. See Exporting DKIM Verification Profiles, on page 619 for more information.
You can import DKIM verification profiles that you previously exported. Importing DKIM verification profiles
causes all of the current DKIM verification profiles on the machine to be replaced. See Importing DKIM
Verification Profiles, on page 619 for more information.
Related Topics
• Creating a DKIM Verification Profile, on page 618
• Exporting DKIM Verification Profiles, on page 619
• Importing DKIM Verification Profiles, on page 619
• Deleting DKIM Verification Profiles, on page 619
• Searching DKIM Verification Profiles, on page 620
Creating a DKIM Verification Profile
Procedure
Step 1 Click Mail Policies > Verification Profiles.
Step 2 Click Add Profile.
Step 3 Enter the name of the profile.
Step 4 Select the minimum key size you want the email gateway to accept for signing keys.
Step 5 Select the maximum key size you want the email gateway to accept for signing keys.
Step 6 Select the maximum number of signatures to verify in a single message. The default is five signatures.
Step 7 Select the number of seconds before the key query times out. The default is 10 seconds.
Step 8 Select maximum allowed difference in time (in seconds) between the sender’s system time and verifier’s. The
default is 60 seconds.
Step 9 Select whether to use the body-length parameter in the signature to verify the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
618
Email Authentication
Exporting DKIM Verification Profiles
Step 10 Select whether the email gateway accepts or rejects the message if there is a temporary failure when verifying
its signature. If you want the email gateway to reject the message, you can choose to have it send the default
451 SMTP response code or another SMTP response code and text.
Step 11 Select whether the email gateway accepts or rejects the message if there is a permanent failure when verifying
its signature. If you want the email gateway to reject the message, you can choose to have it send the default
451 SMTP response code or another SMTP response code and text.
Step 12 Submit your changes.
The new profile appears in the DKIM Verification Profiles table.
Step 13 Commit your changes.
Step 14 At this point you should enable DKIM verification on an incoming mail flow policy and select the verification
profile you want to use.
Exporting DKIM Verification Profiles
All DKIM verification profiles on the email gateway are exported as a single text file and saved in the
configuration directory on the email gateway.
Procedure
Step 1 Choose Mail Policies > Verification Profiles.
Step 2 Click Export Profiles.
Step 3 Enter a name for the file and click Submit.
Importing DKIM Verification Profiles
Procedure
Step 1 Choose Mail Policies > Verification Profiles.
Step 2 Click Import Profiles.
Step 3 Select the file that contains the DKIM verification profiles.
Step 4 Click Submit. You are warned that importing will replace all existing DKIM verification profiles.
Step 5 Click Import.
Deleting DKIM Verification Profiles
Related Topics
• Removing Selected DKIM Verification Profiles , on page 620
• Removing All DKIM Verification Profiles, on page 620
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
619
Email Authentication
Removing Selected DKIM Verification Profiles
Removing Selected DKIM Verification Profiles
Procedure
Step 1 Choose Mail Policies > Verification Profiles.
Step 2 Mark the checkbox to the right of each DKIM verification profile you want to delete.
Step 3 Click Delete.
Step 4 Confirm the deletion.
Removing All DKIM Verification Profiles
Procedure
Step 1 Choose Mail Policies > Verification Profiles.
Step 2 Click Clear All Profiles.
Step 3 Confirm the deletion.
Searching DKIM Verification Profiles
To search all DKIM verification profiles for a specific term in the profile name:
Procedure
Step 1 Choose Mail Policies > Verification Profiles.
Step 2 In the Search DKIM Verification Profiles section, specify the search term.
Step 3 Click Find Profiles.
The search scans the profile name for each DKIM verification profile.
If you do not enter search terms, the search engine returns all DKIM verification profiles.
Configuring DKIM Verification on the Mail Flow Policy
DKIM verification is enabled on mail flow policies for incoming email.
Procedure
Step 1 Choose Mail Policies > Mail Flow Policies.
Step 2 Click the incoming mail policy for the listener where you want to perform verification.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
620
Email Authentication
DKIM Verification and Logging
Step 3 In the Security Features section of the mail flow policy, enable DKIM Verification by selecting On.
Step 4 Select the DKIM verification profile that you want to use for the policy.
Step 5 Commit your changes.
What to do next
Related Topics
• DKIM Verification and Logging, on page 621
DKIM Verification and Logging
Lines such as the following are added to the mail logs upon DKIM verification:
mail.current:Mon Aug 6 13:35:38 2007 Info: MID 17 DKIM: no signature
mail.current:Mon Aug 6 15:00:37 2007 Info: MID 18 DKIM: verified pass
Configuring an Action for DKIM Verified Mail
When you verify DKIM mail, an Authentication-Results header is added to the mail, but the mail is accepted
regardless of the authentication result. To configure actions based on these authentication results, you can
create a content filter to perform actions on the DKIM-verified mail. For example, if DKIM verification fails,
you may want configure the mail to be delivered, bounced, dropped, or sent to a quarantine. To do this, you
must configure an action using a content filter.
Procedure
Step 1 Choose Mail Policies > Incoming Content Filters.
Step 2 Click Add Filter.
Step 3 In the Conditions section, click Add Condition.
Step 4 Select DKIM Authentication from the list of conditions.
Step 5 Choose a DKIM condition. Select one of the following options:
• Pass. The message passed the authentication tests.
• Neutral. Authentication was not performed.
• Temperror. A recoverable error occurred.
• Permerror. An unrecoverable error occurred.
• Hardfail. The authentication tests failed.
• None. The message was not signed.
Step 6 Select an action to associate with the condition. For example, if the DKIM verification fails, you may want
to notify the recipient and bounce the message. Or, if DKIM verification passes, you may want to deliver the
message immediately without further processing.
Step 7 Submit the new content filter.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
621
Email Authentication
Overview of SPF and SIDF Verification
Step 8 Enable the content filter on the appropriate incoming mail policy.
Step 9 Commit your changes.
Overview of SPF and SIDF Verification
AsyncOS supports Sender Policy Framework (SPF) and Sender ID Framework (SIDF) verification. SPF and
SIDF are methods for verifying authenticity of email based on DNS records. SPF and SIDF allow the owner
of an Internet domain to use a special format of DNS TXT records to specify which machines are authorized
to transmit email for that domain. Compliant mail receivers then use the published SPF records to test the
authorization of the sending Mail Transfer Agent’s identity during a mail transaction.
When you use SPF/SIDF authentication, the senders publish SPF records specifying which hosts are permitted
to use their names, and compliant mail receivers use the published SPF records to test the authorization of the
sending Mail Transfer Agent’s identity during a mail transaction.
Note Because SPF checks require parsing and evaluation, AsyncOS performance may be impacted. In addition, be
aware that SPF checks increase the load on your DNS infrastructure.
When you work with SPF and SIDF, note that SIDF is similar to SPF, but it has some differences. To get a
full description of the differences between SIDF and SPF, see RFC 4406. For the purposes of this
documentation, the two terms are discussed together except in the cases where only one type of verification
applies.
Note AsyncOS does not support SPF for incoming relays.
Related Topics
• A Note About Valid SPF Records, on page 622
A Note About Valid SPF Records
To use SPF and SIDF with an email gateway, publish the SPF record according to the RFCs 4406, 4408, and
7208. Review RFC 4407 for a definition of how the PRA identity is determined. You may also want to refer
to the following website to view common mistakes made when creating SPF and SIDF records:
http://www.openspf.org/FAQ/Common_mistakes
Related Topics
• Valid SPF Records, on page 623
• Valid SIDF Records, on page 623
• Testing Your SPF Records, on page 623
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
622
Email Authentication
Valid SPF Records
Valid SPF Records
To pass the SPF HELO check, ensure that you include a “v=spf1 a –all” SPF record for each sending MTA
(separate from the domain). If you do not include this record, the HELO check will likely result in a None
verdict for the HELO identity. If you notice that SPF senders to your domain return a high number of None
verdicts, these senders may not have included a “v=spf1 a –all” SPF record for each sending MTA.
Valid SIDF Records
To support the SIDF framework, you need to publish both “v=spf1” and “spf2.0” records. For example, your
DNS record may look like the following example:
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com TXT "v=spf1 a -all"
example.com. TXT "spf2.0/mfrom,pra +mx a:colo.example.com/28 -all"
SIDF does not verify the HELO identity, so in this case, you do not need to publish SPF v2.0 records for each
sending MTA.
Note If you choose not to support SIDF, publish an “spf2.0/pra ~all” record.
Testing Your SPF Records
In addition to reviewing the RFCs, it is a good idea to test your SPF records before you implement SPF
verification on an email gateway. There are several testing tools available on the openspf.org website:
http://www.openspf.org/Tools
You can use the following tool to determine why an email failed an SPF record check:
http://www.openspf.org/Why
In addition, you can enable SPF on a test listener and use Cisco’s trace CLI command (or perform trace from
the GUI) to view the SPF results. Using trace, you can easily test different sending IPs.
How to Verify Incoming Messages Using SPF/SIDF
Do This More Info
Step 1 (Optional) Create a custom mail flow policy to use Defining Rules for Incoming Messages
for verifying incoming messages using SPF/SIDF. Using a Mail Flow Policy, on page 115
Step 2 Configure your mail flow policies to verify incoming Enabling SPF and SIDF, on page 624
messages using SPF/SIDF.
Step 3 Define the action that the email gateway takes on Determining the Action to Take for
verified messages. SPF/SIDF Verified Mail, on page 628
Step 4 Associate the action with groups of specific senders Configuring Mail Policies, on page 273
or recipients.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
623
Email Authentication
Enabling SPF and SIDF
Do This More Info
Step 5 (Optional) Test the results of message verification. Testing the SPF/SIDF Results, on page
631
Caution Although Cisco strongly endorses email authentication globally, at this point in the industry's adoption, Cisco
suggests a cautious disposition for SPF/SIDF authentication failures. Until more organizations gain greater
control of their authorized mail sending infrastructure, Cisco urges customers to avoid bouncing emails and
instead quarantine emails that fail SPF/SIDF verification.
Note The AsyncOS command line interface (CLI) provides more control settings for SPF level than the web
interface. Based on the SPF verdict, the email gateway can accept or reject a message, in SMTP conversation,
on a per listener basis. You can modify the SPF settings when editing the default settings for a listener’s Host
Access Table using the listenerconfig command. See the Enabling SPF and SIDF via the CLI, on page 625 for
more information on the settings.
Enabling SPF and SIDF
To use SPF/SIDF, you must enable SPF/SIDF for a mail flow policy on an incoming listener. You can enable
SPF/SIDF on the listener from the default mail flow policy, or you can enable it for particular incoming mail
flow policies.
Procedure
Step 1 Choose Mail Policies > Mail Flow Policy.
Step 2 Click Default Policy Parameters.
Step 3 In the default policy parameters, view the Security Features section.
Step 4 In the SPF/SIDF Verification section, click On.
Step 5 Set the level of conformance (the default is SIDF-compatible). This option allows you to determine which
standard of SPF or SIDF verification to use. In addition to SIDF conformance, you can choose SIDF-compatible,
which combines SPF and SIDF
SPF/SIDF Conformance Levels
Conformance Level Description
SPF The SPF/SIDF verification behaves according to RFC4408 and RFC7208.
- No purported responsible address (PRA) identity verification takes place.
NOTE: Select this conformance option to test against the HELO identity.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
624
Email Authentication
Enabling SPF and SIDF via the CLI
Conformance Level Description
SIDF The SPF/SIDF verification behaves according to RFC4406.
-The PRA Identity is determined with full conformance to the standard.
- SPF v1.0 records are treated as spf2.0/mfrom,pra.
- For a nonexistent domain or a malformed identity, a verdict of Fail is returned.
SIDF Compatible The SPF/SIDF verification behaves according to RFC4406 except for the following
differences:
- SPF v1.0 records are treated as spf2.0/mfrom.
- For a nonexistent domain or a malformed identity, a verdict of None is returned.
NOTE: This conformance option was introduced at the request of the OpenSPF
community (www.openspf.org).
Note More settings are available via the CLI. See Enabling SPF and SIDF via the CLI, on page 625 for
more information.
Step 6 If you choose a conformance level of SIDF-compatible, configure whether the verification downgrades a Pass
result of the PRA identity to None if there are Resent-Sender: or Resent-From: headers present in the message.
You might choose this option for security purposes.
Step 7 If you choose a conformance level of SPF, configure whether to perform a test against the HELO identity.
You might use this option to improve performance by disabling the HELO check. This can be useful because
the spf-passed filter rule checks the PRA or the MAIL FROM Identities first. The email gateway only performs
the HELO check for the SPF conformance level.
What to do next
Related Topics
• The Received-SPF Header, on page 627
• Enabling SPF and SIDF via the CLI, on page 625
Enabling SPF and SIDF via the CLI
The AsyncOS CLI supports more control settings for each SPF/SIDF conformance level. When configuring
the default settings for a listener’s Host Access Table, you can choose the listener’s SPF/SIDF conformance
level and the SMTP actions (ACCEPT or REJECT) that the email gateway performs, based on the SPF/SIDF
verification results. You can also define the SMTP response that the email gateway sends when it rejects a
message.
Depending on the conformance level, the email gateway performs a check against the HELO identity, MAIL
FROM identity, or PRA identity. You can specify whether the email gateway proceeds with the session
(ACCEPT) or terminates the session (REJECT) for each of the following SPF/SIDF verification results for
each identity check:
• None. No verification can be performed due to the lack of information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
625
Email Authentication
Enabling SPF and SIDF via the CLI
• Neutral. The domain owner does not assert whether the client is authorized to use the given identity.
• SoftFail. The domain owner believes the host is not authorized to use the given identity but is not willing
to make a definitive statement.
• Fail. The client is not authorized to send mail with the given identity.
• TempError. A transient error occurred during verification.
• PermError. A permanent error occurred during verification.
The email gateway accepts the message for a Pass result unless you configure the SIDF Compatible conformance
level to downgrade a Pass result of the PRA identity to None if there are Resent-Sender: or Resent-From:
headers present in the message. The email gateway then takes the SMTP action specified for when the PRA
check returns None.
If you choose not to define the SMTP actions for an identity check, the email gateway automatically accepts
all verification results, including Fail.
The email gateway terminates the session if the identity verification result matches a REJECT action for any
of the enabled identity checks. For example, an administrator configures a listener to accept messages based
on all HELO identity check results, including Fail, but also configures it to reject messages for a Fail result
from the MAIL FROM identity check. If a message fails the HELO identity check, the session proceeds
because the email gateway accepts that result. If the message then fails the MAIL FROM identity check, the
listener terminates the session and then returns the STMP response for the REJECT action.
The SMTP response is a code number and message that the email gateway returns when it rejects a message
based on the SPF/SIDF verification result. The TempError result returns a different SMTP response from the
other verification results. For TempError, the default response code is 451 and the default message text is
#4.4.3 Temporary error occurred during SPF verification . For all other verification results, the default
response code is 550 and the default message text is #5.7.1 SPF unauthorized mail is prohibited . You
can specify your own response code and message text for TempError and the other verification results.
Optionally, you can configure the email gateway to return a third-party response from the SPF publisher
domain if the REJECT action is taken for Neutral, SoftFail, or Fail verification result. By default, the email
gateway returns the following response:
550-#5.7.1 SPF unauthorized mail is prohibited.
550-The domain example.com explains:
550 <Response text from SPF domain publisher>
To enable these SPF/SIDF settings, use the listenerconfig -> edit subcommand and select a listener.
Then use the hostaccess -> default subcommand to edit the Host Access Table’s default settings.
The following SPF control settings are available for the Host Access Table
SPF Control Settings via the CLI
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
626
Email Authentication
The Received-SPF Header
Conformance Level Available SPF Control Settings
SPF Only • Whether to perform HELO identity check
• SMTP actions taken based on the results of the following identity checks:
• HELO identity (if enabled)
• MAIL FROM Identity
• SMTP response code and text returned for the REJECT action
• Verification time out (in seconds)
SIDF Compatible • Whether to perform a HELO identity check
• Whether the verification downgrades a Pass result of the PRA identity to
None if the Resent-Sender: or Resent-From: headers are present in the
message.
• SMTP actions taken based on the results of the following identity checks:
• HELO identity (if enabled)
• MAIL FROM Identity
• PRA Identity
• SMTP response code and text returned for the REJECT action.
• Verification timeout (in seconds)
SIDF Strict • SMTP actions taken based on the results of the following identity checks:
• MAIL FROM Identity
• PRA Identity
• SMTP response code and text returned in case of SPF REJECT action.
• Verification timeout (in seconds)
The email gateway performs the HELO identity check and accepts the None and Neutral verification results
and rejects the others. The CLI prompts for the SMTP actions are the same for all identity types. The user
does not define the SMTP actions for the MAIL FROM identity. The email gateway automatically accepts
all verification results for the identity. The email gateway uses the default reject code and text for all REJECT
results.
You can also configure this in the command-line interface using the listenerconfig command.
The Received-SPF Header
When you configure AsyncOS for SPF/SIDF verification, it places an SPF/SIDF verification header (
Received-SPF ) in the email. The Received-SPF header contains the following information:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
627
Email Authentication
Determining the Action to Take for SPF/SIDF Verified Mail
• verification result - the SPF verification result (see Verification Results, on page 629).
• identity - the identity that SPF verification checked: HELO, MAIL FROM, or PRA.
• receiver - the verifying host name (which performs the check).
• client IP address - the IP address of the SMTP client.
• ENVELOPE FROM - the envelope sender mailbox. (Note that this may be different from the MAIL
FROM identity, as the MAIL FROM identity cannot be empty.)
• x-sender - the value of the HELO, MAIL FROM, or PRA identity.
• x-conformance - the level of conformance (see Table - SPF/SIDF Conformance Levels ) and whether
a downgrade of the PRA check was performed.
The following example shows a header added for a message that passed the SPF/SIDF check:
Received-SPF: Pass identity=pra; receiver=box.example.com;
client-ip=1.2.3.4; envelope-from="[email protected]";
x-sender="[email protected]"; x-conformance=sidf_compatible
Note The spf-status and spf-passed filter rules use the received-SPF header to determine the status of the
SPF/SIDF verification.
Determining the Action to Take for SPF/SIDF Verified Mail
When you receive SPF/SIDF verified mail, you may want to take different actions depending on the results
of the SPF/SIDF verification. You can use the following message and content filter rules to determine the
status of SPF/SIDF verified mail and perform actions on the messages based on the verification results:
• spf-status . This filter rule determines actions based on the SPF/SIDF status. You can enter a different
action for each valid SPF/SIDF return value.
• spf-passed . This filter rule generalizes the SPF/SIDF results as a Boolean value.
Note The spf-passed filter rule is only available in message filters.
You can use the spf-status rule when you want to address more granular results, and use the spf-passed rule
when you want to create a simple Boolean.
Related Topics
• Verification Results, on page 629
• Using the spf-status Filter Rule in the CLI, on page 629
• spf-status Content Filter Rule in the GUI, on page 630
• Using the spf-passed Filter Rule, on page 631
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
628
Email Authentication
Verification Results
Verification Results
If you use the spf-status filter rule, you can check against the SPF/SIDF verification results using the
following syntax:
if (spf-status == "Pass")
If you want a single condition to check against multiple status verdicts, you can use the following syntax:
if (spf-status == "PermError, TempError")
You can also check the verification results against the HELO, MAIL FROM, and PRA identities using the
following syntax:
if (spf-status("pra") == "Fail")
Note You can only use the spf-status message filter rule to check results against HELO, MAIL FROM, and PRA
identities. You cannot use the spf-status content filter rule to check against identities. The spf-status
content filter checks only the PRA identity.
You can receive any of the following verification results:
• None - no verification can be performed due to the lack of information.
• Pass - the client is authorized to send mail with the given identity.
• Neutral - the domain owner does not assert whether the client is authorized to use the given identity.
• SoftFail - the domain owner believes the host is not authorized to use the given identity but is not willing
to make a definitive statement.
• Fail - the client is not authorized to send mail with the given identity.
• TempError - a transient error occurred during verification.
• PermError - a permanent error occurred during verification.
Using the spf-status Filter Rule in the CLI
The following example shows the spf-status message filter in use:
skip-spam-check-for-verified-senders:
if (sendergroup == "TRUSTED" and spf-status == "Pass"){
skip-spamcheck();
quarantine-spf-failed-mail:
if (spf-status("pra") == "Fail") {
if (spf-status("mailfrom") == "Fail"){
# completely malicious mail
quarantine("Policy");
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
629
Email Authentication
spf-status Content Filter Rule in the GUI
} else {
if(spf-status("mailfrom") == "SoftFail") {
# malicious mail, but tempting
quarantine("Policy");
} else {
if(spf-status("pra") == "SoftFail"){
if (spf-status("mailfrom") == "Fail"
or spf-status("mailfrom") == "SoftFail"){
# malicious mail, but tempting
quarantine("Policy");
stamp-mail-with-spf-verification-error:
if (spf-status("pra") == "PermError, TempError"
or spf-status("mailfrom") == "PermError, TempError"
or spf-status("helo") == "PermError, TempError"){
# permanent error - stamp message subject
strip-header("Subject");
insert-header("Subject", "[POTENTIAL PHISHING] $Subject");
spf-status Content Filter Rule in the GUI
You can also enable the spf-status rule from the content filters in the GUI. However, you cannot check results
against HELO, MAIL FROM, and PRA identities when using the spf-status content filter rule.
To add the spf-status content filter rule from the GUI, click Mail Policies > Incoming Content Filters. Then
add the SPF Verification filter rule from the Add Condition dialog box. Specify one or more verification
results for the condition.
After you add the SPF Verification condition, specify an action to perform based on the SPF status. For
example, if the SPF status is SoftFail, you might quarantine the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
630
Email Authentication
Using the spf-passed Filter Rule
Using the spf-passed Filter Rule
The spf-passed rule shows the results of SPF verification as a Boolean value. The following example shows
an spf-passed rule used to quarantine emails that are not marked as spf-passed:
quarantine-spf-unauthorized-mail:
if (not spf-passed) {
quarantine("Policy");
Note Unlike the spf-status rule, the spf-passed rule reduces the SPF/SIDF verification values to a simple Boolean.
The following verification results are treated as not passed in the spf-passed rule: None, Neutral, Softfail,
TempError, PermError, and Fail. To perform actions on messages based on more granular results, use the
spf-status rule.
Testing the SPF/SIDF Results
Test the results of SPF/SIDF verification and use these results to determine how to treat SPF/SIDF failures
because different organizations implement SPF/SIDF in different ways. Use a combination of content filters,
message filters, and the Email Security Monitor - Content Filters report to test the results of the SPF/SIDF
verification.
Your degree of dependence on SPF/SIDF verification determines the level of granularity at which you test
SPF/SIDF results.
Related Topics
• Basic Granularity Test of SPF/SIDF Results, on page 631
• Greater Granularity Test of SPF/SIDF Results, on page 632
Basic Granularity Test of SPF/SIDF Results
To get a basic measure of the SPF/SIDF verification results for incoming mail, you can use content filters
and the Email Security Monitor - Content Filters page. This test provides a view of the number of messages
received for each type of SPF/SIDF verification result.
Procedure
Step 1 Enable SPF/SIDF verification for a mail flow policy on an incoming listener, and use a content filter to
configure an action to take. For information on enabling SPF/SIDF, see Enabling SPF and SIDF, on page 624.
Step 2 Create an spf-status content filter for each type of SPF/SIDF verification. Use a naming convention to
indicate the type of verification. For example, use “SPF-Passed” for messages that pass SPF/SIDF verification,
or “SPF-TempErr” for messages that weren’t passed due to a transient error during verification. For information
about creating an spf-status content filter, see spf-status Content Filter Rule in the GUI, on page 630.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
631
Email Authentication
Greater Granularity Test of SPF/SIDF Results
Step 3 After you have processed a number of SPF/SIDF verified messages, click Monitor > Content Filters to see
how many messages triggered each of the SPF/SIDF verified content filters.
Greater Granularity Test of SPF/SIDF Results
For more comprehensive information about SPF/SIDF verification results, only enable SPF/SIDF verification
for specific groups of senders, and review the results for those specific senders. Then, create a mail policy for
that particular group and enable SPF/SIDF verification on the mail policy. Create content filters and review
the Content Filters report as explained in Basic Granularity Test of SPF/SIDF Results, on page 631. If you
find that the verification is effective, then you can use SPF/SIDF verification as a basis for deciding whether
to drop or bounce emails for this specified group of senders.
Procedure
Step 1 Create a mail flow policy for SPF/SIDF verification. Enable SPF/SIDF verification for the mail flow policy
on an incoming listener. For information about enabling SPF/SIDF, see Enabling SPF and SIDF, on page 624.
Step 2 Create a sender group for SPF/SIDF verification and use a naming convention to indicate SPF/SIDF verification.
For information about creating sender groups, see the “Configuring the Gateway to Receive Mail” chapter.
Step 3 Create an spf-status content filter for each type of SPF/SIDF verification. Use a naming convention to
indicate the type of verification. For example, use “SPF-Passed” for messages that pass SPF/SIDF verification,
or “SPF-TempErr” for messages that weren’t passed due to a transient error during verification. For information
about creating an spf-status content filter, see spf-status Content Filter Rule in the GUI, on page 630.
Step 4 After you process a number of SPF/SIDF-verified messages, click Monitor > Content Filters to see how
many messages triggered each of the SPF/SIDF-verified content filters.
DMARC Verification
Domain-based Message Authentication, Reporting and Conformance (DMARC) is a technical specification
created to reduce the potential for email-based abuse. DMARC standardizes how email receivers perform
email authentication using SPF and DKIM mechanisms. To pass DMARC verification, an email must pass
at least one of these authentication mechanisms, and the Authentication Identifiers must comply with RFC
5322.
The email gateway allows you to:
• Verify incoming emails using DMARC.
• Define profiles to override (accept, quarantine, or reject) domain owners’ policies.
• Send feedback reports to domain owners, which helps to strengthen their authentication deployments.
• Send delivery error reports to the domain owners if the DMARC aggregate report size exceeds 10 MB
or the size specified in the RUA tag of the DMARC record.
AsyncOS can handle emails that are compliant with the DMARC specification as submitted to Internet
Engineering Task Force (IETF) on March 31, 2013. For more information, see
http://tools.ietf.org/html/draft-kucherawy-dmarc-base-02 .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
632
Email Authentication
DMARC Verification Workflow
Note The email gateway will not perform DMARC verification of messages from domains with malformed DMARC
records. However, the email gateway can receive and process such messages.
Related Topics
• DMARC Verification Workflow, on page 633
• How to Verify Incoming Messages Using DMARC, on page 633
DMARC Verification Workflow
The following describes how AsyncOS performs DMARC verification.
1. A listener configured on AsyncOS receives an SMTP connection.
2. AsyncOS performs SPF and DKIM verification on the message.
3. AsyncOS fetches the DMARC record for the sender’s domain from the DNS.
• If no record is found, AsyncOS skips the DMARC verification and continues processing.
• If the DNS lookup fails, AsyncOS takes action based on the specified DMARC verification profile.
4. Depending on DKIM and SPF verification results, AsyncOS performs DMARC verification on the
message.
Note If DKIM and SPF verification is enabled, DMARC verification reuses the DKIM and SPF verification results.
5. Depending on the DMARC verification result and the specified DMARC verification profile, AsyncOS
accepts, quarantines, or rejects the message. If the message is not rejected due to DMARC verification
failure, AsyncOS continues processing.
6. AsyncOS sends an appropriate SMTP response and continues processing.
7. If sending of aggregate reports is enabled, AsyncOS gathers DMARC verification data and includes it in
the daily report sent to the domain owners. For more information about the DMARC aggregate feedback
report, see DMARC Aggregate Reports, on page 639.
Note If the aggregate report size exceeds 10 MB or the size specified in the RUA tag of the DMARC record,
AsyncOS sends delivery error reports to the domain owners.
How to Verify Incoming Messages Using DMARC
How to Verify Incoming Messages Using DMARC
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
633
Email Authentication
Managing DMARC Verification Profiles
Do This More Information
Step 1 Create a new DMARC verification profile or Create a DMARC Verification Profile, on page
modify the default DMARC verification profile 635
to meet your requirements.
Edit a DMARC Verification Profile, on page
636
Step 2 (Optional) Configure global DMARC settings Configure Global DMARC Settings, on page
to meet your requirements. 637
Step 3 Configure your mail flow policies to verify Configuring DMARC Verification on the Mail
incoming messages using DMARC. Flow Policy, on page 638
Step 4 (Optional) Configure a return address for Configure a Return Address for DMARC
DMARC feedback reports. Feedback Reports, on page 638
Step 5 (Optional) Review the following: • DMARC Verification Page, on page 852
• DMARC Verification and Incoming Mail • Incoming Mail Page, on page 841
reports
• Messages that failed DMARC verification • Searching for Messages on the Legacy
using Message Tracking Interface , on page 916
Related Topics
• Managing DMARC Verification Profiles, on page 634
• DMARC Aggregate Reports, on page 639
• Configure Global DMARC Settings, on page 637
• Configuring DMARC Verification on the Mail Flow Policy, on page 638
• Configure a Return Address for DMARC Feedback Reports, on page 638
Managing DMARC Verification Profiles
A DMARC verification profile is a list of parameters that the mail flow policies of the email gateway use for
verifying DMARC. For example, you may want to create a stringent profile that rejects all non-compliant
messages from a particular domain and a less stringent profile that quarantines all non-compliant messages
from another domain.
A DMARC verification profile consists of the following information:
• A name for the verification profile.
• Message action to take when the policy in the DMARC record is reject.
• Message action to take when the policy in the DMARC record is quarantine.
• Message action in case of a temporary failure.
• Message action in case of a permanent failure.
Related Topics
• Create a DMARC Verification Profile, on page 635
• Edit a DMARC Verification Profile, on page 636
• Exporting DMARC Verification Profiles, on page 636
• Importing DMARC Verification Profiles, on page 636
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
634
Email Authentication
Create a DMARC Verification Profile
• Deleting DKIM Verification Profiles, on page 619
Create a DMARC Verification Profile
Use this procedure to create a new DMARC verification profile.
Note By default, AsyncOS provides a default DMARC verification profile. If you do not want to create a new
DMARC verification profile, you can use the default DMARC verification profile. The default DMARC
verification profile is available on Mail Policies > DMARC page. For instructions to edit the default DMARC
verification profile, see Edit a DMARC Verification Profile, on page 636.
Procedure
Step 1 Choose Mail Policies > DMARC.
Step 2 Click Add Profile.
Step 3 Enter the name of the profile.
Step 4 Set the message action that AsyncOS takes when the policy in the DMARC record is reject. Choose one of
the following:
• No Action. AsyncOS does not take any action on the messages that fail DMARC verification.
• Quarantine. AsyncOS quarantines the messages that fail DMARC verification to a specified quarantine.
• Reject. AsyncOS rejects all messages that fail DMARC verification and returns a specified SMTP code
and response. The default values are, respectively: 550 and #5.7.1 DMARC unauthenticated mail is
prohibited.
Step 5 Set the message action that AsyncOS takes when the policy in the DMARC record is quarantine. Choose one
of the following:
• No Action. AsyncOS does not take any action on the messages that fail DMARC verification.
• Quarantine. AsyncOS quarantines the messages that fail DMARC verification to a specified quarantine.
Step 6 Set the message action that AsyncOS takes on the messages that result in temporary failure during DMARC
verification. Choose one of the following:
• Accept. AsyncOS accepts messages that result in temporary failure during DMARC verification.
• Reject. AsyncOS rejects messages that result in temporary failure during DMARC verification and
returns a specified SMTP code and response. The default values are, respectively: 451 and #4.7.1
Unable to perform DMARC verification.
Step 7 Set the message action that AsyncOS takes on the messages that result in permanent failure during DMARC
verification. Choose one of the following:
• Accept. AsyncOS accepts messages that result in permanent failure during DMARC verification.
• Reject. AsyncOS rejects messages that result in permanent failure during DMARC verification, and
returns a specified SMTP code and response. The default values are, respectively: 550 and #5.7.1
DMARC verification failed.
Step 8 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
635
Email Authentication
Edit a DMARC Verification Profile
Edit a DMARC Verification Profile
Procedure
Step 1 Choose Mail Policies > DMARC.
Step 2 Click the intended verification profile name.
Step 3 Edit the intended fields as described in Create a DMARC Verification Profile, on page 635.
Step 4 Submit and commit your changes.
Exporting DMARC Verification Profiles
You can export all DMARC verification profiles on your email gateway to a single text file in the configuration
directory.
Procedure
Step 1 Choose Mail Policies > DMARC.
Step 2 Click Export Profiles.
Step 3 Enter a name for the file.
Step 4 Click Submit.
Importing DMARC Verification Profiles
Procedure
Step 1 Choose Mail Policies > DMARC.
Step 2 Click Import Profiles.
Step 3 Choose the file that contains the DMARC verification profiles.
Step 4 Click Submit. You are warned that importing will replace all existing DMARC verification profiles.
Step 5 Click Import.
Step 6 Commit your changes.
Deleting DMARC Verification Profiles
Procedure
Step 1 Choose Mail Policies > DMARC.
Step 2 Select the verification profiles that you want to delete.
Step 3 Click Delete.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
636
Email Authentication
Configure Global DMARC Settings
Step 4 Confirm the deletion.
Configure Global DMARC Settings
Procedure
Step 1 Choose Mail Policies > DMARC.
Step 2 Click Edit Global Settings.
Step 3 Make changes to the settings defined in the following table.
DMARC Global Settings
Global Setting Description
Specific senders bypass address Skip DMARC verification of messages from specific senders. Choose an
list address list from the drop-down list.
Note Address lists that are created using full email addresses or
domains only can be used to bypass DMARC verification. For
more information, see Using a List of Sender Addresses for
Incoming Connection Rules, on page 122.
Bypass verification for messages Skip DMARC verification of messages that contain specific headers. For
with headers example, use this option to skip DMARC verification of messages from
mailing lists and trusted forwarders.
Enter a header or multiple headers separated by commas.
Schedule for report generation The time when you want AsyncOS to generate DMARC aggregate reports.
For example, you can choose non-peak hours for generating aggregate
reports to avoid impact on mail flow.
Entity generating reports The entity generating DMARC aggregate reports. This helps the domain
owners who receive DMARC aggregate reports to identify the entity that
generated the report.
Enter a valid domain name.
Additional contact information Additional contact information, for example, details of your organization’s
for reports customer support, if the domain owners who receive DMARC aggregate
reports want to contact the entity that generated the report.
Send copy of all aggregate reports Send a copy of all DMARC aggregate reports to specific users, for
to example, internal users who perform analysis on the aggregate reports.
Enter an email address or multiple addresses separated by commas.
Error Reports Send delivery error reports to the domain owners if the DMARC aggregate
report size exceeds 10 MB or the size specified in the RUA tag of the
DMARC record.
Check the check box.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
637
Email Authentication
Configuring DMARC Verification on the Mail Flow Policy
Step 4 Submit and commit your changes.
Configuring DMARC Verification on the Mail Flow Policy
Procedure
Step 1 Choose Mail Policies > Mail Flow Policies.
Step 2 Click the incoming mail policy for the listener where you want to perform verification.
Step 3 In the Security Features section of the mail flow policy, enable DMARC Verification by choosing On.
Step 4 Select the DMARC verification profile that you want to use for the policy.
Step 5 (Optional) Enable sending of DMARC aggregate feedback reports to email addresses in the RUA tag of
DMARC-enabled domains from whom messages are received.
Aggregate feedback reports are generated daily.
Step 6 Submit and commit your changes.
What to do next
Related Topics
• DMARC Verification Logs, on page 638
DMARC Verification Logs
Log messages are added to the mail logs during the following stages of DMARC verification.
• DMARC verification attempted on a message
• DMARC verification is complete
• DMARC verification details including DKIM and SPF alignment results
• DMARC verification on a message is skipped
• DMARC record is fetched and parsed or DNS failures
• DMARC aggregate report delivery for a domain failed
• Error report generated for a domain
• Error report delivery for a domain succeeded
• Error report delivery for a domain failed
Configure a Return Address for DMARC Feedback Reports
Procedure
Step 1 Choose System Administration > Return Addresses.
Step 2 Click Edit Settings.
Step 3 Provide a return address for DMARC aggregate feedback reports.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
638
Email Authentication
DMARC Aggregate Reports
Step 4 Submit and commit your changes.
DMARC Aggregate Reports
DMARC relies on a feedback mechanism to enforce domain owner policies safely and in a scalable manner.
This feedback mechanism helps the domain owners to strengthen their authentication deployments.
If you are using AsyncOS to perform DMARC verification and you have enabled sending of aggregate
feedback reports in the mail flow policy, AsyncOS generates aggregate feedback reports daily, and sends it
to the domain owners. These reports are in XML format and are archived into a GZip file.
Note All DMARC aggregate feedback reports that AsyncOS generates are DMARC compliant.
A DMARC aggregate feedback report contains the following sections:
• Metadata of the report sender such as email address and report ID number.
• Details of the published DMARC policy.
• Details of DMARC policy disposition such as source IP address and disposition summary.
• Domain identifiers
• DMARC verification results and authentication summary.
Related Topics
• Sample DMARC Aggregate Feedback Report, on page 639
Sample DMARC Aggregate Feedback Report
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<version>1.0</version>
<report_metadata>
<org_name>cisco.com</org_name>
<email>[email protected]</email>
<extra_contact_info>http://cisco.com/dmarc/support</extra_contact_info>
<report_id>[email protected]</report_id>
<date_range>
<begin>1335571200</begin>
<end>1335657599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>1.1.1.1</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
639
Email Authentication
Forged Email Detection
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<envelope_from>example.com</envelope_from>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<selector>ny</selector>
<result>fail</result>
</dkim>
<dkim>
<domain>example.net</domain>
<selector></selector>
<result>pass</result>
</dkim>
<spf>
<domain>example.com</domain>
<scope>mfrom</scope>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
Forged Email Detection
Email forging (also known as spoofing, CEO fraud, or business email compromise) is the process of altering
the message header to hide the real identity of the sender and to make it look like a legitimate message from
someone you know. Assume that a fraudster impersonating as an executive of an organization, is sending a
forged message to an employee asking to send a list of clients and their personally identifiable information
(PII). The employee, unaware of the real identity of the sender, provides a list of clients and their PII. The
fraudster uses the PII to perform identity theft.
The email gateway can detect fraudulent messages with forged sender address (From: header) and perform
specified actions on such messages. For example, your email gateway can detect messages with forged sender
address and replace the From: header with the Envelope Sender. In this case, the employee will see the email
address of the real sender (fraudster’s) instead of the forged email address.
Related Topics
• Setting Up Forged Email Detection, on page 640
• Monitoring Forged Email Detection Results, on page 641
• Displaying Forged Email Detection Details in Message Tracking, on page 642
Setting Up Forged Email Detection
1. Identify the users in your organization (for example, executives) whose messages are likely to be forged.
Create a new content dictionary and add the names of the identified users to it.
While creating a content dictionary,
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
640
Email Authentication
Monitoring Forged Email Detection Results
• Enter the name of the user and not the email address. For example, enter “ Olivia Smith ” instead of
“ [email protected] .”
• Do not configure Advanced Matching and Smart Identifiers.
• Do not choose weight for the terms used.
• Do not use regular expressions.
The following figure shows a sample content dictionary created for Forged Email Detection.
Figure 38: Content Dictionary for Forged Email Detection
For instructions to configure a content dictionary, see Adding Dictionaries, on page 647.
2. Create an incoming content or message filter to detect forged messages and the actions that the email
gateway must take on such messages. Use the following:
• Condition/Rule: Forged Email Detection (See Content Filter Conditions, on page 282 and Message
Filter Rules, on page 140)
Note If you want to skip the Forged email detection filter for messages from specific
senders, choose the address list from the Exception List drop-down list. You can
choose only the address lists that are created using the full email addresses. For
more information on adding exception address list, refer to Using a List of Sender
Addresses for Incoming Connection Rules, on page 122.
• Action: Forged Email Detection or any other actions based on your requirement. (See Content Filter
Conditions, on page 282 and Message Filter Rules, on page 140)
3. Add the newly created content filter to an incoming mail policy. See How to Enforce Mail Policies on a
Per-User Basis, on page 268.
Monitoring Forged Email Detection Results
To view data about forged messages detected, see the Forged Email Matches report page (Monitor > Forged
Email Matches). This report page includes the following reports:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
641
Email Authentication
Displaying Forged Email Detection Details in Message Tracking
• Top Forged Email Matches. Displays the top ten users in the content dictionary that matched the forged
From: header in the incoming messages.
• Forged Email Matches: Details. Displays a list of all the users in the content dictionary that matched
the forged From: header in the incoming messages and for a given user, the number of messages matched.
Click on the number to view a list of messages in Message Tracking.
Displaying Forged Email Detection Details in Message Tracking
To display details of forged messages detected by the email gateway in Message Tracking, make sure that:
• Message Tracking is enabled. See Tracking Messages, on page 915.
• Content or message filters for detecting forged messages are operational.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
642
CHAPTER 27
Text Resources
This chapter contains the following sections:
• Overview of Text Resources, on page 643
• Content Dictionaries, on page 644
• Using and Testing the Content Dictionaries Filter Rules, on page 649
• Understanding Text Resources, on page 651
• Overview of Text Resource Management, on page 652
• Using Text Resources, on page 655
Overview of Text Resources
This chapter discusses creating and managing various text resources, such as content dictionaries, disclaimers,
and templates.
Related Topics
• Content Dictionaries, on page 643
• Text Resources, on page 644
• Message Disclaimer Stamping, on page 644
• Using Custom Dictionaries of Sensitive DLP Terms (Custom DLP Policies Only) , on page 522
Content Dictionaries
Content dictionaries are groups of words or entries that work in conjunction with the Body Scanning feature
on the email gateway and are available to both content and message filters. Use the dictionaries you define
to scan messages, message headers, and message attachments for terms included in the dictionary in order to
take appropriate action in accordance with your corporate policies. For example, you could create a list of
confidential or profane words, and, using a filter rule to scan messages that contain words in the list, drop,
archive, or quarantine the message.
The AsyncOS operating system includes the ability to define a total of 100 content dictionaries using the GUI
(Mail Policies > Dictionaries) or the CLI’s dictionaryconfig command. You can create, delete, and
view dictionaries; add and delete entries from a dictionary; and import and export entire dictionaries.
You can use content dictionaries to scan messages against message or content filters in order to take appropriate
action in accordance with your corporate policies. You can create, delete, and view dictionaries; add and
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
643
Text Resources
Text Resources
delete entries from a dictionary; and import and export entire dictionaries. You can also determine case
sensitivity and word boundary detection for each dictionary. For example, you could create a list of confidential
or profane words, and, using a filter rule to scan messages for words in the list, drop or archive messages
containing matching words. And you can add a “weight” terms in a dictionary so that certain terms trigger a
filter action more easily.
Dictionaries can contain non-ASCII characters.
Note that, for efficient processing, the following content dictionary entries are treated as words:
• Entries containing only alphanumeric characters
• Email addresses containing the following characters: 0-9, A-Z, a-z, dot, underscore, hyphen, and at
symbol
• Domain names containing the following characters: 0-9, A-Z, a-z, dot, underscore, hyphen, and at symbol
If you want the email gateway to treat such a word as a regular expression, enclose the word in parenthesis,
for example, ([email protected]) .
Related Topics
• Dictionary Content, on page 645
• Importing and Exporting Dictionaries as Text Files, on page 646
• Adding Dictionaries, on page 647
• Deleting Dictionaries, on page 648
• Importing Dictionaries, on page 648
• Exporting Dictionaries, on page 649
Text Resources
Text resources are text objects, such as disclaimers, notification templates, and anti-virus templates. You can
create new objects for use in various components of AsyncOS. You can import and export text resources.
Message Disclaimer Stamping
Message disclaimer stamping allows you to add a disclaimer text resource to messages. For example, you
could append a copyright statement, promotional message, or disclaimer to every message sent from within
your enterprise.
Content Dictionaries
Content dictionaries are groups of words or entries that work in conjunction with the Body Scanning feature
on the email gateway and are available to both content and message filters. Use the dictionaries you define
to scan messages, message headers, and message attachments for terms included in the dictionary in order to
take appropriate action in accordance with your corporate policies. For example, you could create a list of
confidential or profane words, and, using a filter rule to scan messages that contain words in the list, drop,
archive, or quarantine the message.
The AsyncOS operating system includes the ability to define a total of 100 content dictionaries using the GUI
(Mail Policies > Dictionaries) or the CLI’s dictionaryconfig command. You can create, delete, and
view dictionaries; add and delete entries from a dictionary; and import and export entire dictionaries.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
644
Text Resources
Dictionary Content
You can use content dictionaries to scan messages against message or content filters in order to take appropriate
action in accordance with your corporate policies. You can create, delete, and view dictionaries; add and
delete entries from a dictionary; and import and export entire dictionaries. You can also determine case
sensitivity and word boundary detection for each dictionary. For example, you could create a list of confidential
or profane words, and, using a filter rule to scan messages for words in the list, drop or archive messages
containing matching words. And you can add a “weight” terms in a dictionary so that certain terms trigger a
filter action more easily.
Dictionaries can contain non-ASCII characters.
Note that, for efficient processing, the following content dictionary entries are treated as words:
• Entries containing only alphanumeric characters
• Email addresses containing the following characters: 0-9, A-Z, a-z, dot, underscore, hyphen, and at
symbol
• Domain names containing the following characters: 0-9, A-Z, a-z, dot, underscore, hyphen, and at symbol
If you want the email gateway to treat such a word as a regular expression, enclose the word in parenthesis,
for example, ([email protected]) .
Related Topics
• Dictionary Content, on page 645
• Importing and Exporting Dictionaries as Text Files, on page 646
• Adding Dictionaries, on page 647
• Deleting Dictionaries, on page 648
• Importing Dictionaries, on page 648
• Exporting Dictionaries, on page 649
Dictionary Content
Words in dictionaries are created with one text string per line, and entries can be in plain text or in the form
of regular expressions. Dictionaries can also contain non-ASCII characters. Defining dictionaries of regular
expressions can provide more flexibility in matching terms, but doing so requires you to understand how to
delimit words properly. For a more detailed discussion of Python style regular expressions, consult the Python
Regular Expression HOWTO, accessible from
http://www.python.org/doc/howto/
Note To use the special character # at the beginning of a dictionary entry, you can use a character class [#] to prevent
it being treated as a comment.
For each term, you specify a “weight,” so that certain terms can trigger filter conditions more easily. When
AsyncOS scans messages for the content dictionary terms, it “scores” the message by multiplying the number
of term instances by the weight of term. Two instances of a term with a weight of three would result in a score
of six. AsyncOS then compares this score with a threshold value associated with the content or message filter
to determine if the message should trigger the filter action.
You can also add smart identifiers to a content dictionary. Smart identifiers are algorithms that search for
patterns in data that correspond to common numeric patterns, such as social security numbers and ABA routing
numbers. These identifiers can useful for policy enforcement. For more information about regular expressions,
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
645
Text Resources
Word Boundaries and Double-byte Character Sets
see “Regular Expressions in Rules” in the “Using Message Filters to Enforce Email Policies” chapter. For
more information about smart identifiers, see “Smart Identifiers” in the “Using Message Filters to Enforce
Email Policies” chapter.
Note Dictionaries containing non-ASCII characters may or may not display properly in the CLI on your terminal.
The best way to view and change dictionaries that contain non-ASCII characters is to export the dictionary
to a text file, edit that text file, and then import the new file back into the email gateway. For more information,
see Importing and Exporting Dictionaries as Text Files, on page 646.
Related Topics
• Word Boundaries and Double-byte Character Sets, on page 646
Word Boundaries and Double-byte Character Sets
In some languages (double-byte character sets), the concepts of a word or word boundary, or case do not exist.
Complex regular expressions that depend on concepts like what is or is not a character that would compose
a word (represented as “\w” in regex syntax) cause problems when the locale is unknown or if the encoding
is not known for certain. For that reason, you may want to disable word-boundary enforcement.
Importing and Exporting Dictionaries as Text Files
The content dictionary feature also includes, by default, the following text files located in the configuration
directory of the email gateway:
• config.dtd
• profanity.txt
• proprietary_content.txt
• sexual_content.txt
These text files are intended to be used in conjunction with the content dictionaries feature to aid you in
creating new dictionaries. These content dictionaries are weighted and use smart identifiers to better detect
patterns in data and trigger filters when the patterns indicate compliance issues.
Note Importing and exporting dictionaries does not preserve the Match Whole Words and Case Sensitive settings.
This settings are only preserved in the configuration file.
See FTP, SSH, and SCP Access, on page 1297 for more information accessing on the configuration directory.
You can also create your own dictionary files and import them onto the email gateway. The best way to add
non-ASCII characters to dictionaries is to add the terms into the dictionary in a text file off the email gateway,
move that file onto the email gateway, and then import that file as a new dictionary. For more information
about importing dictionaries, see Importing Dictionaries, on page 648. For information about exporting
dictionaries, see Exporting Dictionaries, on page 649.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
646
Text Resources
Adding Dictionaries
Caution These text files contain terms that some persons may consider obscene, indecent or offensive. If you import
terms from these files into your content dictionaries, the terms will be displayed when you later view the
content dictionaries you have configured on the email gateway.
Adding Dictionaries
Procedure
Step 1 Navigate to the Mail Policies > Dictionaries page.
Step 2 Click Add Dictionary.
Step 3 Type a name for the dictionary.
Step 4 (Optional) Configure Advanced Matching.
Note AsyncOS preserves the Match Whole Words and Case Sensitive settings when you save them in
the configuration file. AsyncOS does not preserve these settings when importing and exporting
dictionaries.
Step 5 (Optional) Add a smart-identifier to the dictionary.
Smart identifiers are algorithms that search for patterns in data that correspond to common numeric patterns,
such as social security numbers and ABA routing numbers. For more information about smart identifiers, see
the “Using Message Filters to Enforce Email Policies” chapter.
Step 6 Enter new dictionary entries into the list of terms.
If you have multiple new entries to add, and you want them to be equally likely trigger a filter action, put each
new term on its own line.
Note Content dictionary entries with the regular expression: “ .* ” at the beginning or end will cause the
system to lock if a match for the “word” MIME part is found. Cisco Systems recommends you do
not use “ .* ” at the beginning or end of a content dictionary entry.
Step 7 Specify a weight for the term(s).
You can “weight” a dictionary term so that it is more likely than other terms to trigger a filter action. For more
information about how this weight is used to determine filter actions, see “Threshold Scoring for Content
Dictionaries” in the “Using Message Filters to Enforce Email Policies” chapter.
Step 8 Click Add.
Step 9 Submit and commit your changes.
What to do next
Related Topics
• Dictionary Content, on page 645.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
647
Text Resources
Deleting Dictionaries
Deleting Dictionaries
Before You Begin
Be aware that AsyncOS marks any message filter that references the deleted dictionary as invalid. AsyncOS
leaves any content filter that references the deleted dictionary enabled, but will evaluate them to false.
Procedure
Step 1 Navigate to the Mail Policies > Dictionaries page.
Step 2 Click the trash can icon next to the dictionary to delete in the dictionary listing.
A confirmation message lists any filters that are currently referencing the dictionary.
Step 3 Click Delete in the confirmation message.
Step 4 Commit your changes.
Importing Dictionaries
Before You Begin
Verify that the file to import is present in the configuration directory on the email gateway.
Procedure
Step 1 Navigate to the Mail Policies > Dictionaries page.
Step 2 Click Import Dictionary.
Step 3 Select the location to import from.
Step 4 Select the file to import.
Step 5 Select the default weight to use for dictionary terms.
AsyncOS will assign a default weight to any terms with unspecified weights. You can edit the weights after
importing the file.
Step 6 Select an encoding.
Step 7 Click Next.
Step 8 Name and edit the dictionary.
Step 9 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
648
Text Resources
Exporting Dictionaries
Exporting Dictionaries
Procedure
Step 1 Navigate to the Mail Policies > Dictionaries page.
Step 2 Click Export Dictionary.
Step 3 Select the dictionary to export.
Step 4 Enter a file name for the exported dictionary.
This is the name of the file that will be created in the configuration directory on the email gateway.
Step 5 Select the location to export to.
Step 6 Select an encoding for the text file.
Step 7 Submit and commit your changes.
Using and Testing the Content Dictionaries Filter Rules
Dictionaries can be used along with the various dictionary-match() message filter rules and with content filters.
Related Topics
• Dictionary Match Filter Rule, on page 649
Dictionary Match Filter Rule
The message filter rule named dictionary-match(< dictionary_name >) (and its counterparts) evaluates to
true if the message body contains any of the regular expressions in the content dictionary named
dictionary_name . If that dictionary does not exist, the rule evaluates to false.
Note that the dictionary-match() rule functions similarly to the body-contains() body scanning rule: it
only scans the body and attachments of messages, and not the headers.
For scanning headers, you can use the appropriate *-dictionary-match() -type rule (there are rules for
specific headers, such as subject-dictionary-match() and a more generic rule, header-dictionary-match()
, in which you can specify any header including custom headers). See “Dictionary Rules” in the “Using
Message Filters to Enforce Email Policies” chapter for more information about dictionary matching.
Table 46: Message Filter Rules for Content Dictionaries
Rule Syntax Description
Dictionary Does the message contain a word that matches all the
dictionary-match
Match regular expressions listed in the named dictionary?
(<dictionary_name>)
In the following example, a new message filter using the dictionary-match() rule is created to blind carbon
copy the administrator when the email gateway scans a message that contains any words within the dictionary
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
649
Text Resources
Example Dictionary Entries
named “secret_words” (created in the previous example). Note that because of the settings, only messages
that contain the whole word “ codename ” matching the case exactly will evaluate to true for this filter.
bcc_codenames:
if (dictionary-match ('secret_words'))
bcc('[email protected]');
In this example, we send the message to the Policy quarantine:
quarantine_codenames:
if (dictionary-match ('secret_words'))
quarantine('Policy');
Related Topics
• Example Dictionary Entries, on page 650
• Testing Content Dictionaries, on page 650
Example Dictionary Entries
Table 47: Example Dictionary Entries
Description Example
Wildcard
Anchors Ends with: foo $ Begins with: ^ foo
Email address(Do not escape the [email protected], @example.com
period)
example.com$ (ends with)@example.*
Subject An email subject(keep in mind when using the ^ anchor in email subjects
that subjects are often prepended with “RE:” or “FW:” and the like)
Testing Content Dictionaries
The trace function can provide quick feedback on message filters that use the dictionary-match() rule.
See Debugging Mail Flow Using Test Messages: Trace, on page 1249 for more information. You can also use
the quarantine() action to test filters, as in the quarantine_codenames filter example above.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
650
Text Resources
Understanding Text Resources
Understanding Text Resources
Text resources are text templates that can be attached to messages or sent as messages. Text resources can be
one of the following types:
• Message disclaimers — Text that is added to messages. For more information, see Disclaimer Template,
on page 655.
• Notification templates — Messages that are sent as notifications, used with the notify() and notify-bcc()
actions. For more information, see Notification Templates, on page 660.
• Anti-virus Notification templates — Messages that are sent as notifications when a virus is found in a
message. You can create a template for a container (which appends the original message), or as a notice
that is sent without the appended message. For more information, see Anti-Virus Notification Templates,
on page 661.
• Bounce and Encryption Failure Notification templates — Messages that are sent as notifications
when a message is bounced or message encryption fails. For more information, see Bounce and Encryption
Failure Notification Templates, on page 663.
• Encryption Notification Templates — Messages that are sent when you configure the email gateway
to encrypt outgoing email. The message notifies recipients that they have received an encrypted message
and provides instructions for reading it. For more information, see Encryption Notification Templates,
on page 664.
You can use the CLI ( textconfig ) or the GUI to manage text resources, including: adding, deleting,
editing, importing, and exporting. For information on managing text resources using the GUI, see Overview
of Text Resource Management, on page 652.
Text resources can contain non-ASCII characters.
Note Text resources containing non-ASCII characters may or may not display properly in the CLI on your terminal.
To view and change text resources that contain non-ASCII characters, export the text resource to a text file,
edit that text file, and then import the new file back into the email gateway. For more information, see Importing
and Exporting Dictionaries as Text Files, on page 646.
Related Topics
• Importing and Exporting Dictionaries as Text Files, on page 646
Importing and Exporting Text Resources as Text Files
You must have access to the configuration directory on the email gateway. Imported text files must be present
in the configuration directory on the email gateway. Exported text files are placed in the configuration directory.
See FTP, SSH, and SCP Access, on page 1297 for more information on accessing the configuration directory.
To add non-ASCII characters to text resources, add the terms into the text resource in a text file off the email
gateway, move that file onto the email gateway, and then import that file as a new text resource. For more
information about importing text resources, see Importing Text Resources, on page 653. For information about
exporting text resources, see Exporting Text Resources, on page 653.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
651
Text Resources
Overview of Text Resource Management
Overview of Text Resource Management
You can manage text resources using either the GUI or the CLI. This section focuses on the GUI.
Manage text resources from the CLI using the textconfig command.
Text resource management includes these tasks:
• Adding
• Editing and deleting
• Exporting, and importing
• Defining plain text messages for all text resource types
• Defining HTML-based messages for some text resource types
Related topics
• Adding Text Resources, on page 652
• Deleting Text Resources, on page 652
• Exporting Text Resources, on page 653
• Importing Text Resources, on page 653
• Overview of HTML-Based Text Resources, on page 654.
Adding Text Resources
Procedure
Step 1 Navigate to Mail Policies > Text Resources
Step 2 Click Add Text Resource.
Step 3 Enter a name for the text resource in the Name field.
Step 4 Select the type of text resource from the Type field.
Step 5 Enter the message text in either the Text or the HTML and Plain Text field.
If the text resource allows only plain text messages, use the Text field. If the text resource allows both HTML
and plain text messages, use the HTML and Plain Text fields.
Step 6 Submit and commit your changes.
What to do next
Related topics
• Overview of HTML-Based Text Resources, on page 654.
Deleting Text Resources
Before you begin
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
652
Text Resources
Importing Text Resources
Note the impact of deleting text resources:
• Any message filters that reference the deleted text resource are marked as invalid.
• Any content filters that reference the deleted text resource are left enabled, but will evaluate to false.
Procedure
Step 1 On the Mail Policies > Text Resources page, click the trash can icon under the Delete column for the text
resource you want to delete. A confirmation message is displayed.
Step 2 Click Delete to delete the text resource.
Note You cannot delete a text resource that is referenced in any of the content or message filter
configurations.
Step 3 Commit your changes.
Importing Text Resources
Before you begin
Ensure that the file to import is in the configuration directory on the email gateway.
Procedure
Step 1 On the Mail Policies > Text Resources page, click Import Text Resource.
Step 2 Select a file to import.
Step 3 Specify an encoding.
Step 4 Click Next.
Step 5 Choose a name, edit, and select the text resource type.
Step 6 Submit and commit your changes.
Exporting Text Resources
Before you begin
Be aware that when you export a text resource, a text file is created in the configuration directory on the email
gateway.
Procedure
Step 1 On the Mail Policies > Text Resources page, click Export Text Resource.
Step 2 Select a text resource to export.
Step 3 Enter a file name for the text resource.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
653
Text Resources
Overview of HTML-Based Text Resources
Step 4 Select an encoding for the text file.
Step 5 Click Submit to create the text file containing the text resource in the configuration directory.
Overview of HTML-Based Text Resources
You can create some text resources with both HTML-based and plain text messages, such as Disclaimers.
When a text resource containing both HTML-based and plain text messages is applied to an email message,
the HTML-based text resource message is applied to the text/html part of the email message, and the plain
text message is applied to the text/plain part of the email message.
When you add or edit an HTML-based text resource, the GUI includes a rich text edit that allows you to enter
rich text without having to manually write HTML code.
Consider the following information when adding and editing an HTML-based text resource:
• You can choose to have the plain text version of the message to be automatically generated based on the
HTML version, or you can define the plain text version independently.
• You can switch between the rich text editor and HTML code by clicking the Code View button.
• To enter HTML code that is not supported in the rich text editor in the GUI, switch to code view and
manually enter HTML code. For example, you might want to do this to insert a reference to an image
file located on an external server using the <img src> HTML tag.
Related Topics
• Importing and Exporting HTML-Based Text Resources, on page 654
Importing and Exporting HTML-Based Text Resources
You can export to and import from a text file HTML-based text resources. When you export an HTML-based
text resource to a file, the file contains the following sections for each version of the text resource:
• [html_version]
• [text_version]
The order of these sections does not matter.
For example, an exported file might contain the following text:
[html_version]
<p>Sample <i>message.</i></p>
[text_version]
Sample message.
Consider the following rules and guidelines when exporting and importing HTML-based text resources:
• When you export an HTML-based text resource whose plain text message is automatically generated
from the HTML version, the exported file does not contain the [text_version] section.
• When you import from a text file, any HTML code under the [html_version] section is converted to the
HTML message in the created text resource if the text resource type supports HTML messages. Similarly,
any text under the [text_version] section is converted to the plain text message in the created text
resource.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
654
Text Resources
Using Text Resources
• When you import from a file that contains an empty or nonexistent [html_version] section to create a
HTML-based text resource, the email gateway creates both an HTML and plain text message using the
text in the [text_version] section.
Using Text Resources
All types of text resources are created in the same way, using the Text Resources page or the textconfig CLI
command. Once created, each type is used in a different way. Disclaimers and notification templates are used
with filters and listeners, while anti-virus notification templates are used with mail policies and anti-virus
settings.
Related Topics
• Disclaimer Template, on page 655
• Disclaimer Stamping and Multiple Encodings, on page 658
• Notification Templates, on page 660
• Anti-Virus Notification Templates, on page 661
• Bounce and Encryption Failure Notification Templates, on page 663
• Encryption Notification Templates, on page 664
Disclaimer Template
The email gateway can add a default disclaimer above or below the text (heading or footer) for some or all
messages received by a listener. You can add disclaimers to messages on the email gateway using the following
methods:
• Via a listener, using the GUI or the listenerconfig command (see Adding Disclaimer Text via a Listener,
on page 656).
• Using the content filter action, Add Disclaimer Text (see Content Filter Actions, on page 290).
• Using the message filter action, add-footer() (see the “Using Message Filters to Enforce Email Policies”
chapter).
• Using a data loss prevention profile (see Data Loss Prevention, on page 509).
• Using message modification for Outbreak Filters to alert the user that the message may be an attempt at
phishing or malware distribution (see Modifying Messages, on page 430). Disclaimers added for this type
of notification are added above the text.
For example, you can append a copyright statement, promotional message, or disclaimer to every message
sent from within your enterprise.
Prior to using disclaimer text you have to create the disclaimer template. Use the Text Resources page in the
GUI (see Adding Text Resources, on page 652) or the textconfig command (see the CLI Reference Guide
for AsyncOS for Cisco Secure Email Gateway) to create and manage a set of text strings to be used.
Related Topics
• Adding Disclaimers via Filters, on page 656
• Adding Disclaimer Text via a Listener, on page 656
• Disclaimers and Filter Action Variables, on page 656
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
655
Text Resources
Adding Disclaimer Text via a Listener
Adding Disclaimer Text via a Listener
Once you have disclaimer text resources created, select which text strings will be appended to messages
received by the listener. You can add disclaimer text above or below a message. This feature is available on
both public (inbound) and private (outbound) listeners.
If you send a message that consists of text and HTML (Microsoft Outlook calls this type of message a “multipart
alternative”), the email gateway will stamp the disclaimer on both parts of the message. However, if your
message has signed content, the content will not be modified because the modification will invalidate the
signature. Instead, a new part is created with a disclaimer stamp that says “ Content-Disposition inline
attachment .” For more information on multipart messages, see “Message Bodies vs. Message Attachments”
in the “Using Message Filters to Enforce Email Policies” chapter.
Adding Disclaimers via Filters
You can also append specific, predefined text strings to the disclaimers of messages using the filter action
add-footer() or the content filter action “Add Disclaimer Text.” For example, the following message filter
rule appends the text string named legal.disclaimer to all messages sent from users in the LDAP group
“Legal:”
Add-Disclaimer-For-Legal-Team:
if (mail-from-group == 'Legal')
add-footer('legal.disclaimer');
Disclaimers and Filter Action Variables
You can also use message filter action variables (see “Action Variables” in the “Using Message Filters to
Enforce Email Policies” chapter for more information).
The following variables are available for the Disclaimer Template:
Table 48: Anti-Virus Notification Variables
Variable Substituted With
$To Replaced by the message To: header (not the Envelope Recipient).
$From Replaced by the message From: header (not the Envelope Sender).
$Subject Replaced by the subject of the original message.
$Date Replaced by the current date, using the format MM/DD/YYYY.
$Time Replaced by the current time, in the local time zone.
$GMTimestamp Replaced by the current time and date, as would be found in the Received: line of
an email message, using GMT.
$MID Replaced by the Message ID, or “MID” used internally to identify the message. Not
to be confused with the RFC822 “Message-Id” value (use $Header to retrieve that).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
656
Text Resources
Disclaimers and Filter Action Variables
Variable Substituted With
$Group Replaced by the name of the sender group the sender matched on when injecting
the message. If the sender group had no name, the string “>Unknown<” is inserted.
$Policy Replaced by the name of the HAT policy applied to the sender when injecting the
message. If no predefined policy name was used, the string “>Unknown<” is inserted.
$Reputation Replaced by the IP Reputation score of the sender. If there is no reputation score,
it is replaced with “None”.
$filenames Replaced with a comma-separated list of the message’s attachments’ filenames.
$filetypes Replaced with a comma-separated list of the message's attachments' file types.
$filesizes Replaced with a comma-separated list of the message’s attachment’s file sizes.
$remotehost Replaced by the hostname of the system that sent the message to the email gateway.
$AllHeaders Replaced by the message headers.
$EnvelopeFrom Replaced by the Envelope Sender (Envelope From, <MAIL FROM>) of the message.
$Hostname Replaced by the hostname of the email gateway.
$header[‘string ’] Replaced by the value of the quoted header, if the original message contains a
matching header. Note that double quotes may also be used.
$enveloperecipients Replaced by all Envelope Recipients (Envelope To, <RCPT TO>) of the message.
$bodysize Replaced by the size, in bytes, of the message.
$FilterName Returns the name of the filter being processed.
$MatchedContent Returns the content that triggered a scanning filter rule (including filter rules such
as body-contains and content dictionaries).
$DLPPolicy Replaced by the name of the email DLP policy violated.
$DLPSeverity Replaced by the severity of violation. Can be “Low,” “Medium,” “High,” or
“Critical.”
$DLPRiskFactor Replaced by the risk factor of the message’s sensitive material (score 0 - 100).
$threat_category Replaced with the type of Outbreak Filters threat, such as phishing, virus, scam, or
malware.
$threat_type Replaced by a subcategory of the Outbreak Filters threat category. For example,
can be a charity scam, a financial phishing attempt, a fake deal, etc.
$threat_description Replaced by a description of the Outbreak Filters threat.
$threat_level Replaced by the message’s threat level (score 0 - 5).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
657
Text Resources
Disclaimer Stamping and Multiple Encodings
Variable Substituted With
$threat_verdict Replaced by Yes or No, depending on the Message Modification Threat Level
threshold. If the viral or non-viral threat level of a message is greater than or equal
to the message modification threat level threshold, the value of this variable is set
to Yes.
To use message filter action variables in disclaimers, create a message disclaimer (via the Text Resource page
in the GUI or the textconfig command), and reference the variable:
The add-footer() action supports non-ASCII text by adding the footer as an inline, UTF-8 coded, quoted
printable attachment.
Disclaimer Stamping and Multiple Encodings
AsyncOS includes a setting used to modify the way disclaimer stamping with different character encodings
works. By default, AsyncOS attempts to place the disclaimers it attaches within the body part of an email
message. You can use a setting configured within the localeconfig command to configure the behavior if
the encodings of the body part and the disclaimer are different. To understand this setting, it is helpful to view
an email message as consisting of several parts:
To: [email protected] Headers
From: [email protected]
Subject: Hi!
<blank line>
Hello! Body part
This message has been First attachment part
scanned...
Example.zip Second attachment part
The message body after the first blank line may contain many MIME parts. The second and following parts
are often called “attachments,” while the first is often called the “body” or “text.”
A disclaimer can be included in an email as either an attachment (above) or as part of the body
To: [email protected] Headers
From: [email protected]
Subject: Hi!
<blank line>
Hello! Body part
This message has been Disclaimer now included in body part
scanned...
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
658
Text Resources
Disclaimer Stamping and Multiple Encodings
Example.zip First attachment part
Typically, when there is an encoding mismatch between the message body and a disclaimer, AsyncOS attempts
to encode the entire message in the same encoding as the message body so that the disclaimer will be included
in the body (“inline”) and not included as a separate attachment. In other words, the disclaimer will be included
inline if the encoding of the disclaimer matches that of the body, or if the text in the disclaimer contains
characters that can be displayed inline (in the body). For example, it is possible to have a ISO-8859-1 encoded
disclaimer that only contains US-ASCII characters; consequently, this will display “inline” without problems.
However, if the disclaimer cannot be combined with the body, you can use the localeconfig command to
configure AsyncOS to attempt to promote, or convert, the body text to match the encoding of the disclaimer
so that the disclaimer can be included in the body of the message:
example.com> localeconfig
Behavior when modifying headers: Use encoding of message body
Behavior for untagged non-ASCII headers: Impose encoding of message body
Behavior for mismatched footer or heading encoding: Try both body and footer or heading
encodings
Behavior when decoding errors found: Disclaimer is displayed as inline content and the
message body is added as an attachment.
Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
[]> setup
If a header is modified, encode the new header in the same encoding as the message body?
(Some MUAs incorrectly handle headers encoded in a different encoding than the body.
However, encoding a modified header in the same encoding as the message body may cause
certain
characters in the modified header to be lost.) [Y]>
If a non-ASCII header is not properly tagged with a character set and is being used or
modified,
impose the encoding of the body on the header during processing and final representation
of the message?
(Many MUAs create non-RFC-compliant headers that are then handled in an undefined way.
Some MUAs handle headers encoded in character sets that differ from that of the main body
in an incorrect way.
Imposing the encoding of the body on the header may encode the header more precisely.
This will be used to interpret the content of headers for processing, it will not modify
or rewrite the
header unless that is done explicitly as part of the processing.) [Y]>
Disclaimers (as either footers or headings) are added in-line with the message body whenever
possible.
However, if the disclaimer is encoded differently than the message body, and if imposing a
single encoding
will cause loss of characters, it will be added as an attachment. The system will always
try to use the
message body's encoding for the disclaimer. If that fails, the system can try to edit the
message body to
use an encoding that is compatible with the message body as well as the disclaimer. Should
the system try to
re-encode the message body in such a case? [Y]>
If the disclaimer that is added to the footer or header of the message generates an error
when decoding the message body,
it is added at the top of the message body. This prevents you to rewrite a new message
content that must merge with
the original message content and the header/footer-stamp. The disclaimer is now added as
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
659
Text Resources
Notification Templates
an additional MIME part
that displays only the header disclaimer as an inline content, and the rest of the message
content is split into
separate email attachments. Should the system try to ignore such errors when decoding the
message body? [N]>
Behavior when modifying headers: Use encoding of message body
Behavior for untagged non-ASCII headers: Impose encoding of message body
Behavior for mismatched footer or heading encoding: Try both body and footer or heading
encodings
Behavior when decoding errors found: Disclaimer is displayed as inline content and the
message body
is added as an attachment.
Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
[]>
For more information about the localeconfig command, see the “Configuring the Email Gateway to Receive
Mail” chapter.
Notification Templates
Notification templates are used with the notify() and notify-copy() filter actions. Notification
templates may contain non-ascii text and action variables (see “Action Variables” in the “Using Message
Filters to Enforce Email Policies” chapter), including the anti-virus-related variables used by anti-virus
notifications. For example, you could use the $Allheaders action variable to include the headers from the
original message. You can configure the From: address for notifications, see Configuring the Return Address
for Email Gateway Generated Messages, on page 1041.
Once you have created a notification template, you can refer to it in content and message filters. The following
figure shows a content filter where the notify-copy() filter action is set to send the “grape_text”
notification to “[email protected]:”
Figure 39: Notify Example in a Content Filter
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
660
Text Resources
Anti-Virus Notification Templates
Anti-Virus Notification Templates
There are two types of anti-virus notification templates:
• anti-virus notification template. The anti-virus notification template is used when the original message
is not attached to the virus notification.
• anti-virus container template. The container template is used when the original message is sent as an
attachment.
Anti-virus notification templates are used in basically the same way as notification templates except that they
are used with the anti-virus engine instead of filters. You can specify a custom notification to send while
editing a mail policy. You can configure the From: address for anti-virus notifications. For information, see
Configuring the Return Address for Email Gateway Generated Messages, on page 1041.
Related Topics
• Custom Anti-Virus Notification Templates, on page 661
Custom Anti-Virus Notification Templates
The following figure shows a mail policy where a custom anti-virus notification is specified.
Figure 40: Anti-Virus Container Template Notification Example in a Mail Policy
Related Topics
• Anti-Virus Notification Variables, on page 661
Anti-Virus Notification Variables
When creating an anti-virus notification, you can use any of the notification variables listed in the following
table:
Table 49: Anti-Virus Notification Variables
Variable Substituted With
$To Replaced by the message To: header (not the Envelope Recipient).
$From Replaced by the message From: header (not the Envelope Sender).
$Subject Replaced by the subject of the original message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
661
Text Resources
Anti-Virus Notification Variables
Variable Substituted With
$AV_VIRUSES Replaced by the list of all the viruses found anywhere in the message:
“Unix/Apache.Trojan”, “W32/Bagel-F”
$AV_VIRUS_TABLE Replaced by the table of MIME-Part/Attachment names and viruses in each
part:
“HELLO.SCR” : “W32/Bagel-F”
<unnamed part of the message> : “Unix/Apache.Trojan”
$AV_VERDICT Replaced by the anti-virus verdict.
$AV_DROPPED_TABLE Replaced by the table of attachments that were dropped. Each row is composed
of a part or filename followed by the list of viruses associated with that part:
“HELLO.SCR” : “W32/Bagel-f”, “W32/Bagel-d” “Love.SCR” : “Netsky-c”,
“W32/Bagel-d”
$AV_REPAIRED_VIRUSES Replaced by the list of all the viruses found and repaired.
$AV_REPAIRED_TABLE Replaced by the table of all parts and viruses found and repaired: “HELLO.SCR”
: “W32/Bagel-F”
$AV_DROPPED_PARTS Replaced by the list of filenames that were dropped:
“HELLO.SCR”, “CheckThisOut.exe”
$AV_REPAIRED_PARTS Replaced by the list of filenames or parts that were repaired.
$AV_ENCRYPTED_PARTS Replaced by the list of filenames or parts that were encrypted.
$AV_INFECTED_PARTS Replaced by a comma-separated list of filenames for the files that contained a
virus.
$AV_UNSCANNABLE_PARTS Replaced by the list of filenames or parts that were unscannable.
$Date Replaced by the current date, using the format MM/DD/YYYY.
$Time Replaced by the current time, in the local time zone.
$GMTimestamp Replaced by the current time and date, as would be found in the Received: line
of an email message, using GMT.
$MID Replaced by the Message ID, or “MID” used internally to identify the message.
Not to be confused with the RFC822 “Message-Id” value (use $Header to
retrieve that).
$Group Replaced by the name of the sender group the sender matched on when injecting
the message. If the sender group had no name, the string “>Unknown<” is
inserted.
$Policy Replaced by the name of the HAT policy applied to the sender when injecting
the message. If no predefined policy name was used, the string “>Unknown<”
is inserted.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
662
Text Resources
Bounce and Encryption Failure Notification Templates
Variable Substituted With
$Reputation Replaced by the IP Reputation score of the sender. If there is no reputation
score, it is replaced with “None”.
$filenames Replaced with a comma-separated list of the message’s attachments’ filenames.
$filetypes Replaced with a comma-separated list of the message's attachments' file types.
$filesizes Replaced with a comma-separated list of the message’s attachment’s file sizes.
$remotehost Replaced by the hostname of the system that sent the message to the email
gateway.
$AllHeaders Replaced by the message headers.
$EnvelopeFrom Replaced by the Envelope Sender (Envelope From, <MAIL FROM>) of the
message.
$Hostname Replaced by the hostname of the email gateway.
Note Variable names are not case-sensitive. For example, specifying “$to” is equivalent to specifying “$To” in the
text resource. If an “AV_” variable is empty in the original message, the string <None> is substituted.
After the text resource has been defined, use the Mail Policies > Incoming/Outgoing Mail Policies > Edit
Anti-Virus Settings page or the policyconfig -> edit -> antivirus command to specify that
the original message is to be included as an RFC 822 attachment for Repaired, Unscannable, Encrypted, or
Virus Positive messages. See Send Custom Alert Notification, on page 376 for more information.
Bounce and Encryption Failure Notification Templates
Bounce and encryption failure notification templates are used in basically the same way as notification
templates except that they are used with bounce notifications and message encryption failure notifications.
You can specify a custom bounce notification to send while editing a bounce profile and a custom message
encryption failure notification while editing an encryption profile.
The following figure shows a bounce notification template specified in a bounce profile.
Figure 41: Bounce Notification Example in a Bounce Profile
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
663
Text Resources
Bounce and Encryption Failure Notification Variables
Note You must use RFC-1891 DSNs to use custom templates.
The following figure shows an encryption failure template specified in an encryption profile.
Figure 42: Encryption Failure Notification Example in an Encryption Profile
Related Topics
• Bounce and Encryption Failure Notification Variables, on page 664
Bounce and Encryption Failure Notification Variables
When creating a bounce or encryption failure notification, you can use any of the notification variables listed
in the following table:
Table 50: Bounce Notification Variables
Variable Substituted With
$Subject The subject of the original message.
$Date Replaced by the current date, using the format MM/DD/YYYY.
$Time Replaced by the current time, in the local time zone.
$GMTimeStamp Replaced by the current time and date, as would be found in the Received: line of
an email message, using GMT.
$MID Replaced by the Message ID, or “MID” used internally to identify the message.
Not to be confused with the RFC822 “Message-Id” value (use $Header to retrieve
that).
$BouncedRecipient Bounced recipient address
$BounceReason Reason for this notification
$remotehost Replaced by the hostname of the system that sent the message to the email gateway.
Encryption Notification Templates
Encryption notification templates are used when you configure Cisco Email Encryption to encrypt outbound
email. The notification informs recipients that they have received an encrypted message and provides
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
664
Text Resources
Encryption Notification Templates
instructions for reading it. You can specify a custom encryption notification to send with encrypted messages.
You specify both an HTML and a text encryption notification when you create an encryption profile. Therefore,
if you want to create a custom profile, you should create both text and HTML notifications.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
665
Text Resources
Encryption Notification Templates
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
666
CHAPTER 28
Validating Recipients Using an SMTP Server
This chapter contains the following sections:
• Overview of SMTP Call-Ahead Recipient Validation, on page 667
• SMTP Call-Ahead Recipient Validation Workflow, on page 667
• How to Validate Recipients Using an External SMTP Server, on page 669
• Enabling a Listener to Validate Incoming Mail Via the SMTP Server, on page 672
• Configuring LDAP Routing Query Settings, on page 672
• SMTP Call-Ahead Query Routing, on page 673
• Bypassing SMTP Call-Ahead Validation for Certain Users or Groups, on page 674
Overview of SMTP Call-Ahead Recipient Validation
The SMTP call-ahead recipient validation feature queries an external SMTP server before accepting incoming
mail for a recipient. Use this feature to validate recipients when you cannot use LDAP Accept or the Recipient
Access Table (RAT). For example, suppose you host mail for many mailboxes, each using a separate domain,
and your LDAP infrastructure does not allow you to query the LDAP server to validate each recipient. In this
case, the email gateway can query the SMTP server and validate the recipient before continuing the SMTP
conversation.
You can use SMTP call-ahead recipient validation in order to reduce processing on messages for invalid
recipients. Typically, a message for an invalid recipient progresses through the work queue before it can be
dropped. Instead, an invalid message can be dropped or bounced during the incoming/receiving part of the
email pipeline without requiring additional processing.
SMTP Call-Ahead Recipient Validation Workflow
When you configure your email gateway for SMTP call-ahead recipient validation, the email gateway suspends
the SMTP conversation with the sending MTA while it “calls ahead” to the SMTP server to verify the recipient.
When the email gateway queries the SMTP server, it returns the SMTP server’s response to the Email Security
appliance, and depending on the settings you have configured, you can accept the mail or drop the connection
with a code and custom response.
The following figure shows the basic workflow of the SMTP call-head validation conversation.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
667
Validating Recipients Using an SMTP Server
SMTP Call-Ahead Recipient Validation Workflow
Figure 43: SMTP Call Ahead Server Conversation Workflow
1. The sending MTA initiates an SMTP conversation.
2. The email gateway suspends the SMTP conversation while it sends a query to the SMTP server to verify
the recipient, [email protected] .
Note If SMTP routes or LDAP routing queries are configured, these routes will be used to query the SMTP server.
3. The SMTP Server returns a query response to the email gateway.
4. The email gateway resumes the SMTP conversation and sends a response to the sending MTA, allowing
the conversation to continue or dropping the connection based on the SMTP server response (and settings
you configure in the SMTP Call-Ahead profile).
Due to the order of processes in the email pipeline, if the message for a given recipient is rejected by the RAT,
then the SMTP call-ahead recipient validation will not occur. For example, if you specified in the RAT that
only mail for example.com is accepted, then mail for [email protected] is rejected before SMTP
call-ahead recipient validation can occur.
Note If you have configured Directory Harvest Attack Prevention (DHAP) in the HAT, be aware that SMTP
call-ahead server rejections are part of the number of rejections included in the maximum invalid recipients
per hour that you specify. You may need to adjust this number to account for additional SMTP server rejections.
For more information about DHAP, see the “Configuring the Gateway to Receive Email” chapter.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
668
Validating Recipients Using an SMTP Server
How to Validate Recipients Using an External SMTP Server
How to Validate Recipients Using an External SMTP Server
Do This More Info
Step 1 Determine how the email gateway connects to the Configuring the Call-Ahead Server
SMTP server and interprets the server’s responses. Profile, on page 669
Step 2 Configure a public listener to use the SMTP server to Enabling a Listener to Validate
validate recipients Incoming Mail Via the SMTP
Server, on page 672
Step 3 (Optional) Update your LDAP Routing query to Configuring LDAP Routing Query
determine the SMTP server to use when routing mail Settings, on page 672
to a different host.
Step 4 (Optional) Configure the email gateway to bypass Bypassing SMTP Call-Ahead
call-ahead validation for certain recipients Validation for Certain Users or
Groups, on page 674
Related Topics
• Configuring the Call-Ahead Server Profile, on page 669
Configuring the Call-Ahead Server Profile
When you configure the SMTP Call-Ahead Server Profile, you specify the settings that determine how the
email gateway connects with the SMTP server and how it interprets the responses sent back from the SMTP
server.
Procedure
Step 1 Click Network > SMTP Call-Ahead.
Step 2 Click Add Profile.
Step 3 Enter the settings for the profile. For more information, see Table - SMTP Call-Ahead Server Profile Settings.
Step 4 Configure the advanced settings for the profile. For more information, see Table - SMTP Call-Ahead Server
Profile Advanced Settings.
Step 5 Submit and commit your changes.
What to do next
• SMTP Call-Ahead Server Profile Settings, on page 670
• Call Ahead Server Responses, on page 671
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
669
Validating Recipients Using an SMTP Server
SMTP Call-Ahead Server Profile Settings
SMTP Call-Ahead Server Profile Settings
When you configure the SMTP Call-Ahead Server Profile, you need to configure settings that determine how
the email gateway connects with the SMTP server.
Table 51: SMTP Call-Ahead Server Profile Settings
Setting Description
Profile Name Name of the call-ahead server profile.
Call-Ahead Server Type Choose from one of the following methods for connecting to the call-ahead
server:
• Use Delivery Host. Select this option to specify that the host for the
delivery email address is used for the SMTP call-ahead query. For
example, if the mail recipient address is [email protected] , the
SMTP query is executed against the SMTP server associated with
example.com . If you have configured SMTP routes or LDAP routing
queries, these routes are used to determine the SMTP server to query.
For details about configuring LDAP routing queries, see Configuring
LDAP Routing Query Settings, on page 672.
• Static Call-Ahead Server. Use this option to create a static list of
call-ahead servers to query. You may want to use this option if you do
not expect the names and locations of the call-ahead servers to change
often. When you use this option, the email gateway queries the hosts in
a round-robin fashion, starting with the first static call-ahead server
listed.
Note Note that when you choose the static call-ahead server type, no
SMTP routes are applied to the query. Instead an MX lookup is
performed, and then an A lookup is performed on the hosts to
obtain the call-ahead IP addresses for the static servers.
Static Call-Ahead Servers If you choose to use the static call-ahead server type, enter a list of host and
port combinations in this field. List the server and port using the following
syntax:
ironport.com:25
Separate multiple entries with a comma.
The following table describes the SMTP Call-Ahead Server Profile advanced settings:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
670
Validating Recipients Using an SMTP Server
Call Ahead Server Responses
Table 52: SMTP Call-Ahead Server Profile Advanced Settings
Setting Description
Interface The interface used to initiate the SMTP conversation with the SMTP server.
Choose to use the Management interface or Auto. When you select Auto,
the email gateway attempts to automatically detect an interface to use. The
Cisco IronPort interface attempts to connect to the SMTP server in the
following ways:
• If the call-ahead server is on the same subnet as one of the configured
interfaces, then the connection is initiated by the matching interface.
• Any configured SMTP routes are used to route the query.
• Otherwise, the interface that is on the same subnet as the default
gateway are used.
MAIL FROM Address The MAIL FROM: address to be used for the SMTP conversation with the
SMTP server.
Validation Request Timeout The number of seconds to wait for a result from the SMTP server. This
timeout value is for a single recipient validation request which may involve
contacting multiple call-ahead servers. See Call Ahead Server Responses,
on page 671.
Validation Failure Action The action to be taken when a recipient validation request fails (due to a
timeout, server failure, network issue, or unknown response). You can
configure how you want the email gateway to handle the different responses.
See Call Ahead Server Responses, on page 671.
Temporary Failure Action The action to be taken when a recipient validation request temporarily fails
(and a 4xx response is returned from the remote SMTP server). This can
occur when the mailbox is full, the mailbox is not available, or the service
is not available).
See Call Ahead Server Responses, on page 671.
Max. Recipients per Session Maximum number of recipients to be validated in a single SMTP session.
Specify between 1 - 25,000 sessions.
Max. Connections per Server Maximum number of connections to a single call-ahead SMTP server.
Specify between 1-100 connections.
Cache Size of the cache for SMTP responses. Specify between 100-1,000,000
entries
Cache TTL Time-to-live value for entries in the cache. This field defaults to 900 seconds.
Specify between 60 - 86400 seconds.
Call Ahead Server Responses
The SMTP server may return the following responses:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
671
Validating Recipients Using an SMTP Server
Enabling a Listener to Validate Incoming Mail Via the SMTP Server
• 2xx: When an SMTP code starting with 2 is received from the call-ahead server, the recipient is accepted.
For example, a response of 250 allows the mailing action to continue.
• 4xx: An SMTP code starting with a 4 means that a temporary failure has occurred in processing the
SMTP request. A retry may later be processed successfully. For example, a response of 451 means the
requested action was aborted or there was a local error in processing.
• 5xx: An SMTP code starting with 5 means a permanent failure in processing the SMTP request occurred.
For example, a response of 550 means the requested action was not taken or the mailbox was unavailable.
• Timeout. If no response is returned from the call-ahead server, you can configure how long to attempt
to retry before a timeout occurs.
• Connection error. If a connection to the call-ahead server fails, you can configure whether to accept or
reject a connection for the recipient address.
• Custom Response. You can configure to reject a connection with custom SMTP response (code and
text) for validation failures and temporary failures.
Enabling a Listener to Validate Incoming Mail Via the SMTP
Server
Once you create the SMTP Call-Ahead Server Profile, you need to enable it on a listener to allow the listener
to validate incoming mail via the SMTP server. SMTP call-ahead functionality is only available on public
listeners, as recipient validation is not necessary for private listeners.
Procedure
Step 1 Go to Network > Listeners.
Step 2 Click the name of the listener where you want to enable SMTP call-ahead functionality.
Step 3 In the SMTP Call Ahead Profile field, select the SMTP Call-Ahead profile you want to enable.
Step 4 Submit and commit your changes.
Configuring LDAP Routing Query Settings
If you use an LDAP routing query to route mail to a different mail host, AsyncOS uses the Alternate Mailhost
Attribute to determine the SMTP server to query. However, there are cases where you may not want that to
occur. For example, in the following schema, note that the mail host attribute ( mailHost ) has a different
SMTP address than the servers listed in the call-ahead SMTP server attribute ( callAhead ):
dn: mail=cisco.com, ou=domains
mail: cisco.com
mailHost: smtp.mydomain.com
policy: ASAV
callAhead: smtp2.mydomain.com,smtp3.mydomain.com:9025
In this case, you can use the SMTP Call-Ahead field to create a routing query that directs the SMTP call-ahead
query to the servers listed in the callAhead attribute. For example, you might create a routing query with the
following attributes:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
672
Validating Recipients Using an SMTP Server
SMTP Call-Ahead Query Routing
Figure 44: LDAP Routing Query Configured for SMTP Call-Ahead
In this query, the {d} represents the domain part of the recipient address, and the SMTP Call-Ahead Server
Attribute returns the values for the call-ahead servers and the port that should be used for the query:
smtp2.mydomain.com, smtp3.mydomain.com on port 9025.
Note This example shows just one way to configure a query that enables you to use the LDAP routing query to
direct SMTP call-ahead queries to the correct SMTP servers. You are not required to use the query string or
specific LDAP attributes described in this example.
SMTP Call-Ahead Query Routing
When routing an SMTP call-ahead query, AsyncOS checks for information in the following order:
1. Checks the domain name.
2. Checks for LDAP Routing queries.
3. Checks for SMTP Routes.
4. Performs a DNS Lookup (First an MX Lookup is performed, followed by an A lookup).
If there is no LDAP routing query or no SMTP Routes configured for the domain, the result of preceding state
is passed to next stage. In any case where there is no SMTP Route present, a DNS lookup is performed.
When you use an LDAP Routing query for an SMTP call-ahead query and you also have SMTP routes
configured, the routing behavior depends upon the values returned by the routing query.
• If the LDAP routing query returns a single hostname without a port, the SMTP call-ahead query applies
SMTP routes. If the SMTP routes only lists the destination host as the hostname, a DNS lookup is
performed to obtain the IP address of the SMTP server.
• If the LDAP routing query returns a single hostname with a port, the SMTP route is used, but the port
returned by the LDAP query is used over any ports specified in SMTP routes. If the SMTP routes only
lists the destination host as the hostname, a DNS lookup is performed to obtain the IP address of the
SMTP server.
• If the LDAP routing query returns multiple hosts with or without ports, SMTP routes are applied, but
the ports returned by the LDAP routing query are used over those present in SMTP routes. If the SMTP
routes only lists the destination host as the hostname, a DNS lookup is performed to obtain the IP address
of the SMTP server.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
673
Validating Recipients Using an SMTP Server
Bypassing SMTP Call-Ahead Validation for Certain Users or Groups
Bypassing SMTP Call-Ahead Validation for Certain Users or
Groups
You may want to enable SMTP call-ahead validation on a listener but skip the SMTP call-ahead validation
for certain users or groups of users.
You may want to skip SMTP call-ahead validation for recipients for whom mail should not be delayed during
SMTP call-ahead queries. For example, you could add a RAT entry for a customer service alias that you know
is valid and will likely need immediate attention.
To configure bypassing SMTP call-ahead validation via the GUI, select Bypass SMTP Call-Ahead when
you add or edit the RAT entry
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
674
CHAPTER 29
Encrypting Communication with Other MTAs
This chapter contains the following sections:
• Overview of Encrypting Communication with Other MTAs, on page 675
• Working with Certificates, on page 676
• Enabling TLS on a Listener’s HAT, on page 681
• Enabling TLS and Certificate Verification on Delivery, on page 684
• DNS-based Authentication of Named Entities, on page 687
• Managing Lists of Certificate Authorities, on page 691
• Enabling a Certificate for HTTPS, on page 694
Overview of Encrypting Communication with Other MTAs
Enterprise Gateways (or Message Transfer Agents, i.e. MTAs) normally communicate “in the clear” over the
Internet. That is, the communications are not encrypted. In several scenarios, malicious agents can intercept
this communication without the knowledge of the sender or the receiver. Communications can be monitored
and even altered by a third party.
Transport Layer Security (TLS) is an improved version of the Secure Socket Layer (SSL) technology. It is a
widely used mechanism for encrypting SMTP conversations over the Internet. AsyncOS supports the
STARTTLS extension to SMTP (Secure SMTP over TLS), described in RFC 3207 (which obsoletes RFC
2487).
The TLS implementation in AsyncOS provides privacy through encryption. It allows you to import an X.509
certificate and private key from a certificate authority service or create a self-signed certificate to use on the
email gateway. AsyncOS supports separate TLS certificates for public and private listeners, secure HTTP
(HTTPS) management access on an interface, the LDAP interface, and all outgoing TLS connections.
Related Topics
• How to Encrypt SMTP Conversations using TLS, on page 675
How to Encrypt SMTP Conversations using TLS
How to Encrypt SMTP Conversations using TLS
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
675
Encrypting Communication with Other MTAs
Working with Certificates
Do This More Info
Step 1 Obtain an X.509 certificate and private key from a Working with Certificates, on page 676
recognized certificate authority.
Step 2 Install the certificate on the email gateway Install a certificate by either:
• Creating a Self-Signed Certificate , on
page 678
• Importing a Certificate , on page 680
Step 3 Enable TLS for receiving messages, delivering • Enabling TLS on a Listener’s HAT, on
messages, or both page 681
• Enabling TLS and Certificate Verification
on Delivery, on page 684
Step 4 (Optional) Customize the list of trusted certificate Managing Lists of Certificate Authorities, on
authorities that the appliance uses to verify a page 691
certificate from a remote domain to establish the
domain’s credentials.
Step 5 (Optional) Configure the email gateway to send an Sending Alerts When a Required TLS
alert when it’s unable to deliver messages to a Connection Fails, on page 686
domain that requires a TLS connection.
Working with Certificates
To use TLS, the email gateway must have an X.509 certificate and matching private key for receiving and
delivery. You may use the same certificate for both SMTP receiving and delivery and different certificates
for HTTPS services on an interface, the LDAP interface, and all outgoing TLS connections to destination
domains, or use one certificate for all of them.
You can view the entire list of certificates on the Network > Certificates page in the web interface and in the
CLI by using the print command after you configure the certificates using certconfig . Note that the print
command does not display intermediate certificates.
Caution Your email gateway ships with a demonstration certificate to test the TLS and HTTPS functionality, but
enabling either service with the demonstration certificate is not secure and is not recommended for general
use. When you enable either service with the default demonstration certificate, a warning message is printed
in the CLI.
Related Topics
• Deploying a Signed Certificate , on page 677
• Deploying Self-Signed Certificates , on page 677
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
676
Encrypting Communication with Other MTAs
Deploying a Signed Certificate
Deploying a Signed Certificate
Use a signed certificate when you cannot exchange self-signed certificates between the email gateway and
the other machine, for example because that machine is not in your domain. Your corporate security department
may have other requirements.
Do This More Info
Step 1 If you are deploying in a cluster, follow Certificates and Centralized Management, on
instructions. page 678
Step 2 Generate a self-signed certificate and Certificate Creating a Self-Signed Certificate , on page 678
Signing Request (CSR).
Step 3 Send the generated certificate to a recognized About Sending a Certificate Signing Request
Certificate Authority for signing. (CSR) to a Certificate Authority , on page 679
Step 4 Upload the signed certificate. Uploading a Certificate Signed by a Certificate
Authority , on page 680
Step 5 Ensure that the certificate authority that signed the Managing Lists of Certificate Authorities, on page
certificate is on the list of trusted authorities. 691
Step 6 If applicable, use an intermediate certificate. Intermediate Certificates, on page 678
Deploying Self-Signed Certificates
You can generally use self-signed certificates for communications between email gateways that are behind
your corporate firewall. Your corporate security department may have other requirements.
Do This More Info
Step 1 If you are deploying in a cluster, follow Certificates and Centralized Management, on page
instructions. 678
Step 2 Generate a self-signed certificate from the Creating a Self-Signed Certificate , on page 678
email gateway.
Step 3 Export the self-signed certificate. Exporting a Certificate , on page 681
Step 4 Import the self-signed certificate to the See the documentation for the other machine.
machine with which the email gateway will
communicate.
Step 5 Generate and export a self-signed certificate See the documentation for the other machine.
from the other machine.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
677
Encrypting Communication with Other MTAs
Certificates and Centralized Management
Do This More Info
Step 6 Import the self-signed certificate from the Importing a Certificate , on page 680
other machine into the email gateway.
or
See the chapter in this guide for configuring
communication with that machine.
For example, to configure secure communications with
a Cisco AMP Threat Grid Appliance, see instructions
for configuring Advanced settings in Configuring an
On-Premises File Analysis Server , on page 486.
Certificates and Centralized Management
A certificate usually uses the local machine’s hostname for the certificate’s common name. If your email
gateways are part of a cluster, you will need to import a certificate for each cluster member as the machine
level, with the exception of a wild card certificate or a Subject Alternative Name (SAN) certificate that you
can install at the cluster level. Each cluster member’s certificate must use the same certificate name so the
cluster can refer to it when a member’s listener is communicating with another machine.
Intermediate Certificates
In addition to root certificate verification, AsyncOS supports the use of intermediate certificate verification.
Intermediate certificates are certificates issued by a trusted root certificate authority which are then used to
create additional certificates - effectively creating a chained line of trust. For example, a certificate may be
issued by godaddy.com who, in turn, is granted the rights to issue certificates by a trusted root certificate
authority. The certificate issued by godaddy.com must be validated against godaddy.com’s private key as
well as the trusted root certificate authority’s private key.
Creating a Self-Signed Certificate
You might want to create a self-signed certificate on the email gateway for any of the following reasons:
• To encrypt SMTP conversations with other MTAs using TLS (both inbound and outbound conversations).
• To enable the HTTPS service on the email gateway for accessing the GUI using HTTPS.
• Use as a client certificate for LDAPS if the LDAP server asks for a client certificate.
• To allow secure communication between the email gateway and a Cisco AMP Threat Grid Appliance.
To create a self-signed certificate using the CLI, use the certconfig command.
Procedure
Step 1 Select Network > Certificates.
Step 2 Click Add Certificate.
Step 3 Select Create Self-Signed Certificate.
Step 4 Enter the following information for the self-signed certificate:
Common Name The fully qualified domain name.
Organization The exact legal name of the organization.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
678
Encrypting Communication with Other MTAs
About Sending a Certificate Signing Request (CSR) to a Certificate Authority
Common Name The fully qualified domain name.
Organizational Unit Section of the organization.
City (Locality) The city where the organization is legally located.
State (Province) The state, county, or region where the organization is legally located.
Country The two letter ISO abbreviation of the country where the organization is
legally located.
Duration before expiration The number of days before the certificate expires.
Private Key Size Size of the private key to generate for the CSR. Only 2048-bit and 1024-bit
are supported.
Step 5 Click Next.
Step 6 Select the FQDN Validation check box to allow the email gateway to check whether the 'Common Name
present in the certificate is in the FQDN format.
Step 7 Enter a name for the certificate. By default, AsyncOS assigns the common name previously entered.
Step 8 If you will submit this certificate as a Certificate Signing Request (CSR), click Download Certificate Signing
Request to save the CSR in PEM format to a local or network machine.
Step 9 Submit and commit your changes.
What to do next
See the appropriate next step:
• Deploying a Signed Certificate , on page 677
• Deploying Self-Signed Certificates , on page 677
About Sending a Certificate Signing Request (CSR) to a Certificate Authority
A certificate authority is a third-party organization or company that issues digital certificates used to verify
identity and distributes public keys. This provides an additional level of assurance that the certificate is issued
by a valid and trusted identity. You may purchase certificates and private keys from a recognized certificate
authority. Cisco does not recommend one service over another.
The email gateway can create a self-signed certificate and generate a Certificate Signing Request (CSR) to
submit to a certificate authority to obtain the public certificate. The certificate authority will return a trusted
public certificate signed by a private key. Use the Network > Certificates page in the web interface or the
certconfig command in the CLI to create the self-signed certificate, generate the CSR, and install the trusted
public certificate.
If you are acquiring or creating a certificate for the first time, search the Internet for “certificate authority
services SSL Server Certificates,” and choose the service that best meets the needs of your organization.
Follow the service’s instructions for obtaining a certificate.
What To Do Next
See Deploying a Signed Certificate , on page 677.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
679
Encrypting Communication with Other MTAs
Uploading a Certificate Signed by a Certificate Authority
Uploading a Certificate Signed by a Certificate Authority
When the certificate authority returns the trusted public certificate signed by a private key, upload the certificate
to the email gateway.
You can use the certificate with a public or private listener, an IP interface’s HTTPS services, the LDAP
interface, or all outgoing TLS connections to destination domains.
Procedure
Step 1 Make sure that the trusted public certificate that you receive is in PEM format or a format that you can convert
to PEM using before uploading to the email gateway. (Tools for doing this are included with OpenSSL, free
software from http://www.openssl.org.)
Step 2 Upload the signed certificate to the email gateway:
Note Uploading the certificate from the certificate authority overwrites the existing self-signed certificate.
a) Select Network > Certificates.
b) Click the name of the certificate that you sent to the Certificate Authority for signing.
c) Enter the path to the file on your local machine or network volume.
Step 3 You can also upload an intermediate certificate related to the self-signed certificate.
What to do next
Related Topics
• Deploying a Signed Certificate , on page 677
Importing a Certificate
AsyncOS also allows you to import certificates from other machines that are saved in the PKCS #12 format
to use on your email gateway.
To import a certificate using the CLI, use the certconfig command.
Note If you are deploying a signed certificate, do not use this procedure to import the signed certificate. Instead,
see Uploading a Certificate Signed by a Certificate Authority , on page 680 .
Procedure
Step 1 Select Network > Certificates.
Step 2 Click Add Certificate.
Step 3 Select the Import Certificate option.
Step 4 Enter the path to the certificate file on your network or local machine.
Step 5 Enter the passphrase for the file.
Step 6 Click Next to view the certificate’s information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
680
Encrypting Communication with Other MTAs
Exporting a Certificate
Step 7 Select the FQDN Validation check box to allow the email gateway to check whether the 'Common Name,'
'SAN: DNS Name' fields, or both present in the certificate, are in the FQDN format.
Step 8 Enter a name for the certificate.
AsyncOS assigns the common name by default.
Step 9 Submit and commit your changes.
What to do next
• If you are deploying self-signed certificates, see Deploying Self-Signed Certificates , on page 677.
Exporting a Certificate
AsyncOS also allows you to export certificates and save them in the PKCS #12 format.
Note If you are deploying a signed certificate, do not use this procedure to generate a Certificate Signing Request
(CSR). Instead, see Deploying a Signed Certificate , on page 677.
Procedure
Step 1 Navigate to the Network > Certificates page.
Step 2 Click Export Certificate.
Step 3 Select the certificate you want to export.
Step 4 Enter the file name for the certificate.
Step 5 Enter and confirm the passphrase for the certificate file.
Step 6 Click Export.
Step 7 Save the file to a local or network machine.
Step 8 You can export additional certificates or click Cancel to return to the Network > Certificates page.
What to do next
• If you are deploying self-signed certificates, see Deploying Self-Signed Certificates , on page 677.
Enabling TLS on a Listener’s HAT
You must enable TLS for any listeners where you require encryption. You may want to enable TLS on listeners
facing the Internet (that is, public listeners), but not for listeners for internal systems (that is, private listeners).
Or, you may want to enable encryption for all listeners.
You can specify the following settings for TLS on a listener.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
681
Encrypting Communication with Other MTAs
Assigning a Certificate to a Public or Private Listener for TLS Connections Using the GUI
Table 53: TLS Settings for a Listener
TLS Setting Meaning
1. No TLS is not allowed for incoming connections. No connections to the listener will
require encrypted SMTP conversations. This is the default setting for all listeners
you configure on the email gateway.
2. Preferred TLS is allowed for incoming connections to the listener from MTAs.
3. Required TLS is allowed for incoming connections to the listener from MTAs, and until
a STARTTLS command is received, the email gateway responds with an error
message to every command other than NOOP , EHLO , or QUIT . This behavior
is specified by RFC 3207, which defines the SMTP Service Extension for Secure
SMTP over Transport Layer Security. “Requiring” TLS means that email which
the sender is not willing to encrypt with TLS will be refused by the email gateway
before it is sent, thereby preventing it from be transmitted in the clear.
By default, neither private nor public listeners allow TLS connections. You must enable TLS in a listener’s
HAT to enable TLS for either inbound (receiving) or outbound (sending) email. In addition, all default mail
flow policy settings for private and public listeners have the tls setting set to “off.”
You can assign a specific certificate for TLS connections to individual public listeners when creating a listener.
For more information, see Listening for Connection Requests by Creating a Listener Using Web Interface,
on page 83.
Related Topics
• Assigning a Certificate to a Public or Private Listener for TLS Connections Using the GUI, on page 682
• Assigning a Certificate to a Public or Private Listener for TLS Connections Using the CLI, on page 683
• Logging, on page 687
• GUI Example: Changing the TLS setting for Listeners HAT, on page 683
• CLI Example: Changing the TLS Setting for Listeners HAT, on page 683
Assigning a Certificate to a Public or Private Listener for TLS Connections
Using the GUI
Procedure
Step 1 Navigate to the Network > Listeners page.
Step 2 Click the name of the Listener to edit.
Step 3 In the Certificate field, choose a certificate.
Step 4 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
682
Encrypting Communication with Other MTAs
Assigning a Certificate to a Public or Private Listener for TLS Connections Using the CLI
Assigning a Certificate to a Public or Private Listener for TLS Connections
Using the CLI
Procedure
Step 1 Use the listenerconfig -> edit command to choose a listener you want to configure.
Step 2 Use the certificate command to see the available certificates.
Step 3 Choose the certificate you want to assign to the listener when prompted.
Step 4 When you are finished configuring the listener, issue the commit command to enable the change.
Logging
The Email Security appliance will note in the mail logs instances when TLS is required but could not be used
by the listener. The mail logs will be updated when the following conditions are met:
• TLS is set to “required” for a listener.
• The Email Security appliance has sent a “Must issue a STARTTLS command first” command.
• The connection is closed without having received any successful recipients.
Information on why the TLS connection failed will be included in the mail logs.
GUI Example: Changing the TLS setting for Listeners HAT
Procedure
Step 1 Navigate to the Mail Policies > Mail Flow Policies page.
Step 2 Choose a listener whose policies you want to modify, and then click the link for the name of policy to edit.
(You can also edit the Default Policy Parameters.)
Step 3 In the “Encryption and Authentication” section, for the “TLS:” field, choose the level of TLS you want for
the listener.
Step 4 Submit and commit your changes
The mail flow policy for the listener is updated with the TLS setting you chose
CLI Example: Changing the TLS Setting for Listeners HAT
Procedure
Step 1 Use the listenerconfig -> edit command to choose a listener you want to configure.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
683
Encrypting Communication with Other MTAs
Enabling TLS and Certificate Verification on Delivery
Step 2 Use the hostaccess -> default command to edit the listener’s default HAT settings.
Step 3 Change the TLS setting by entering one of the following choices when you are prompted with the following
questions:
Do you want to allow encrypted TLS connections?
1. No
2. Preferred
3. Required
[1]> 3
You have chosen to enable TLS. Please use the 'certconfig' command to
ensure that there is a valid certificate configured.
Step 4 Note that this example asks you to use the certconfig command to ensure that there is a valid certificate that
can be used with the listener. If you have not created any certificates, the listener uses the demonstration
certificate that is pre-installed on the email gateway. You may enable TLS with the demonstration certificate
for testing purposes, but it is not secure and is not recommended for general use. Use the listenerconfig
-> edit -> certificate command to assign a certificate to the listener. Once you have configured TLS,
the setting will be reflected in the summary of the listener in the CLI.
Name: Inboundmail
Type: Public
Interface: PublicNet (192.168.2.1/24) TCP Port 25
Protocol: SMTP
Default Domain:
Max Concurrency: 1000 (TCP Queue: 50)
Domain map: disabled
TLS: Required
Step 5 Issue the commit command to enable the change
Enabling TLS and Certificate Verification on Delivery
You can require that TLS is enabled for email delivery to specific domains using the Destination Controls
page or the destconfig command.
In addition to TLS, you can require that the domain’s server certificate is verified. This domain verification
is based on a digital certificate used to establish the domain’s credentials. The validation process involves
four validation requirements:
• The chain of issuer certificates for the SMTP session ends in a certificate issued by a trusted certificate
authority (CA)
• The Common Name (CN) listed on the certificate matches either the receiving machine's DNS name or
the message's destination domain.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
684
Encrypting Communication with Other MTAs
Enabling TLS and Certificate Verification on Delivery
-or-
The message's destination domain matches one of the DNS names in the certificate's Subject Alternative
Name (subjectAltName) extension, as described in RFC 2459. The matching supports wildcards as
described in section 3.1 of RFC 2818.
• [Optional - Only if FQDN validation enabled in SSL Configuration settings]: Check whether the 'Common
Name,' 'SAN: DNS Name' fields, or both present in the server certificate, are in the FQDN format.
• [Optional - Only if X 509 validation enabled in SSL Configuration settings]: Check for the signature
algorithm of the server certificate.
A trusted CA is a third-party organization or company that issues digital certificates used to verify identity
and distributes public keys. This provides an additional level of assurance that the certificate is issued by a
valid and trusted identity.
You can configure your email gateway to send messages to a domain over a TLS connection as an alternative
to envelope encryption. See the “Cisco Email Encryption” chapter for more information.
You can specify a certificate for the email gateway to use for all outgoing TLS connections. To specify the
certificate, click Edit Global Settings on the Destination Controls page or use destconfig -> setup in the
CLI. The certificate is a global setting, not a per-domain setting.
You can specify 5 different settings for TLS for a given domain when you include a domain using the
Destination Controls page or the destconfig command. In addition to specifying whether exchanges with a
domain are required or preferred to be TLS encoded, you can dictate whether validation of the domain is
necessary. See the following table for an explanation of the settings:
Table 54: TLS Settings for Delivery
TLS Setting Meaning
Default The default TLS setting set using the Destination Controls page or the destconfig ->
default subcommand used for outgoing connections from the listener to the MTA for the
domain.
The value “Default” is set if you answer “no” to the question: “Do you wish to apply a
specific TLS setting for this domain?”
1. No TLS is not negotiated for outgoing connections from the interface to the MTA for the
domain.
2. Preferred TLS is negotiated from the email gateway interface to the MTA(s) for the domain. However,
if the TLS negotiation fails (prior to receiving a 220 response), the SMTP transaction does
not fall back to clear text. No attempt is made to verify if the certificate originates from a
trusted certificate authority. If an error occurs and the TLS negotiation fails after the 220
response is received, the SMTP transaction will continue "in the clear" (not encrypted).
3. Required TLS is negotiated from the email gateway interface to MTA(s) for the domain. No attempt
is made to verify the domain’s certificate. If the negotiation fails, no email is sent through
the connection. If the negotiation succeeds, the mail is delivered via an encrypted session.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
685
Encrypting Communication with Other MTAs
Sending Alerts When a Required TLS Connection Fails
TLS Setting Meaning
4. Preferred TLS is negotiated from the email gateway to the MTA(s) for the domain. The email gateway
(Verify) attempts to verify the domain’s certificate.
Three outcomes are possible:
• TLS is negotiated and the certificate is verified. The mail is delivered via an encrypted
session.
• TLS is negotiated, but the certificate is not verified. The mail is delivered via an
encrypted session.
• No TLS connection is made and, subsequently the certificate is not verified. The email
message is delivered in plain text.
5. Required TLS is negotiated from the email gateway to the MTA(s) for the domain. Verification of
(Verify) the domain certificate is required. The following outcomes are possible:
• A TLS connection is negotiated and the certificate is verified. The email message is
delivered via an encrypted session.
• A TLS connection is negotiated, but the certificate is not verified by a trusted Cerfificate
Authority (CA). The mail is not delivered.
• A TLS connection is not negotiated. The mail is not delivered.
6. Required - The difference between TLS Required - Verify and TLS Required - Verify Hosted Domain
Verify Hosted options lays in identity verification process. The way how the presented identity is processed
Domains and what type of reference identifiers are allowed to be used make a difference about a final
result.
The presented identity is first derived from subjectAltName extension of type dNSName. If
there is no match between the dNSName and one of accepted reference identities (REF-ID),
the verification fails no matter if CN exist in subject field and could pass further identity
verification. The CN derived from subject field is validated only when the certificate does
not contain any of subjectAltName extension of type dNSName.
If there is no specific entry for a given recipient domain in the good neighbor table, or if there is a specific
entry but there is no specific TLS setting for the entry, then the behavior is whatever is set using the Destination
Controls page or the destconfig -> default subcommand (“No,” “Preferred,” “Required,” “Preferred
(Verify),” or “Required (Verify)”).
Related Topics
• Sending Alerts When a Required TLS Connection Fails, on page 686
• Logging, on page 687
• Managing Lists of Certificate Authorities, on page 691
Sending Alerts When a Required TLS Connection Fails
You can specify whether the email gateway sends an alert if the TLS negotiation fails when delivering messages
to a domain that requires a TLS connection. The alert message contains name of the destination domain for
the failed TLS negotiation. The email gateway sends the alert message to all recipients set to receive Warning
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
686
Encrypting Communication with Other MTAs
Enabling TLS Connection Alerts
severity level alerts for System alert types. You can manage alert recipients via the System Administration >
Alerts page in the GUI (or via the alertconfig command in the CLI).
Related Topics
• Enabling TLS Connection Alerts , on page 687
Enabling TLS Connection Alerts
Procedure
Step 1 Navigate to the Mail Policies Destination Controls page.
Step 2 Click Edit Global Settings.
Step 3 Click Enable for “Send an alert when a required TLS connection fails.”
This is a global setting, not a per-domain setting. For information on the messages that the email gateway
attempted to deliver, use the Monitor > Message Tracking page or the mail logs.
Step 4 Submit and commit your changes.
What to do next
You can also configure this in the command-line interface using the destconfig -> setup command to enable
TLS connection alerts using the CLI
Logging
The email gateway will note in the mail logs instances when TLS is required for a domain but could not be
used. Information on why the TLS connection could not be used will be included. The mail logs will be
updated when any of the following conditions are met:
• The remote MTA does not support ESMTP (for example, it did not understand the EHLO command
from the email gateway).
• The remote MTA supports ESMTP but “STARTTLS” was not in the list of extensions it advertised in
its EHLO response.
• The remote MTA advertised the “STARTTLS” extension but responded with an error when the email
gateway sent the STARTTLS command.
DNS-based Authentication of Named Entities
• Overview of SMTP DNS-based Authentication of Named Entities, on page 688
• Enabling TLS for Delivery with DANE Support, on page 690
• Sending Alerts When DANE Fails, on page 691
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
687
Encrypting Communication with Other MTAs
Overview of SMTP DNS-based Authentication of Named Entities
Overview of SMTP DNS-based Authentication of Named Entities
TLS connections that are authenticated using certificates can become vulnerable to a security breach in any
one of the following ways:
• A trusted Certificate Authority (CA) can issue certificates to any domain name.
• An attacker can use a man-in-the-middle (MITM) attack to downgrade a TLS connection to plain text
communication.
• If DNSSEC is not configured on the DNS server, an attacker can forge a DNS response with fake DNS
MX records and redirect messages to an insecure server which can lead to DNS cache poisoning attacks.
• Self-signed certificates or certificates issued by a private Certificate Authority (CA) can be used when
a receiving Mail Transfer Agent (MTA) is not configured with a list of trusted Certificate Authority.
The SMTP DNS-based Authentication of Named Entities (DANE) protocol validates your X.509 certificates
with DNS names using a Domain Name System Security (DNSSEC) extension configured on your DNS
server and a DNS resource record, also known as a TLSA record.
The TLSA record is added in the cerificate that contains details about either the Certificate Authority (CA),
the end entity certificate, or the trust anchor used for the DNS name described in RFC 6698. For more
information, see Creating TLSA Record, on page 689. The Domain Name System Security (DNSSEC) extensions
provide added security on the DNS by addressing vulnerabilities in DNS security. DNSSEC using cryptographic
keys and digital signatures ensures that the lookup data is correct and connects to legitimate servers.
The following are the benefits of using SMTP DANE for outgoing TLS connections:
• Provides secure delivery of messages by preventing Man-in-the-Middle (MITM) downgrade attacks,
eavesdropping and DNS cache poisoning attacks.
• Provides authenticity of TLS certificates and DNS information, when secured by DNSSEC.
Related Topics
• SMTP DANE Workflow, on page 688
• Creating TLSA Record, on page 689
• Enabling TLS for Delivery with DANE Support, on page 690
• Sending Alerts When DANE Fails, on page 691
SMTP DANE Workflow
The following figure describes flow of messages using outgoing TLS connection with DANE support:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
688
Encrypting Communication with Other MTAs
Creating TLSA Record
Figure 45: Message Delivery Using TLS with DANE Support
1. Sender (Alice) sends a message to a recipient (Bob) outside the organization.
2. The message reaches the email gateway.
3. The email gateway requests for a DNS resource record, also known as a TLSA record of the DNS from
the DNS server.
4. The certificates and a TLSA record is retrieved from the DNS server, secured by DNSSEC.
5. The email gateway establishes a STARTTLS SMTP session to the recipient's address.
6. The X.509 certificates are validated against the complete TLSA record or hash value of the TLSA record,
of the recipient's address. After successful validation, the message is delivered to the recipient's Mail
Transfer Agent (MTA). If certificate verification fails, the message is delivered at a later time or the
message is bounced.
7. The MTA delivers the message to recipient's mailbox.
Creating TLSA Record
You can create a TLSA record of your preferred certificate authority (CA) on the DNS record signed with
DNSSEC. Below is a sample TLSA record for a Fully Qualified Domain Name (FQDN) www.example.com:
_443._tcp.www.example.com. IN TLSA (0 0 1
91751cee0a1ab8414400238a761411daa29643ab4b8243e9a91649e25be53ada)
The above example TLSA record has the following fields that are encrypted:
• Certificate Usage: Specifies the type of certificate.
• In the given sample, the first '0' digit specifies the CA certificate that must be matched to the PKIX
certification path, as described in RFC 6698.
• If it is '1', it specifies the end entity certificate that must be matched to the end entity certificate
given by the server in TLS.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
689
Encrypting Communication with Other MTAs
Enabling TLS for Delivery with DANE Support
• If it is '2', it specifies a certificate that must be used as a trust anchor while validating the end entity
certificate given by the server in TLS.
• If it is '3', it specifies a certificate that must match the end entity certificate given by the server in
TLS.
• Selector Field: Specifies the part of TLS certificate that is matched with the association data.
• In the given sample, the second '0' specifies that the full certificate must be matched.
• If it is '1', it specifies that only the 'SubjectPublicKeyInfo' field must be matched.
• Matching Type: Specifies the type of HASH value that is used.
• In the given sample, the third '1' specifies the SHA-256 hash of the selected content.
• If it is '0', it specifies the exact match on the selected content.
• If it is '2' it specifies the SHA-512 hash of the selected content.
Enabling TLS for Delivery with DANE Support
Before you begin
• Ensure that the envelope sender and the TLSA resource record is DNSSEC verified.
• Ensure that you enable TLS to configure DANE on your email gateway. For more information, see
Enabling TLS and Certificate Verification on Delivery, on page 684.
Procedure
Step 1 Go to Mail Policies > Destination Controls page.
Step 2 Click Add Destination Controls or modify an existing entry.
Step 3 From the TLS Support field, you must select Preferred, Required or Mandatory to enable DANE support
on your email gateway.
Step 4 From the DANE Support field, you can specify the following settings for DANE for a given TLS connection.
DANE Setting Description
Default The default DANE setting set using the Destination Controls
page is used for outgoing TLS connections from the listener to
the MTA for the domain.
The "Default" DANE setting is inherited from the default TLS
settings in Destination Controls. You can override this setting
to the custom Destination Control entry.
None Select "None", if you do not want DANE to be used for
negotiating outgoing connections from the interface to the MTA
for the domain.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
690
Encrypting Communication with Other MTAs
Sending Alerts When DANE Fails
DANE Setting Description
Opportunistic If you select "Opportunistic" and the remote host does not
support DANE, opportunistic TLS is used for encrypting SMTP
conversations.
If you select "Opportunistic" and the remote host supports
DANE, it becomes the preferred mode for encrypting SMTP
conversations.
Mandatory If you select "Mandatory" and the remote host does not support
DANE, no connection is established to the destination host.
If you select "Mandatory" and the remote host supports DANE,
it becomes the preferred mode for encrypting SMTP
conversations.
Step 5 Submit and Commit your changes.
Sending Alerts When DANE Fails
You can specify whether the email gateway sends an alert if the DANE verification fails to all MX hosts when
delivering messages to a domain that requires a TLS connection with DANE support. The email gateway
sends the alert message to all recipients set to receive Warning severity level alerts for System alert types.
Enabling DANE Alerts
Procedure
Step 1 Go to System Administration > Alerts page.
Step 2 Select the alert recipient you want to enable the alert.
Step 3 Select the Message Delivery check box corresponding to the alert type.
Step 4 Submit and commit your changes.
Managing Lists of Certificate Authorities
The email gateway uses stored trusted certificate authorities that it uses to verify a certificate from a remote
domain to establish the domain’s credentials. You can configure the email gateway to use the following trusted
certificate authorities:
• Pre-installed list. The email gateway has a pre-installed list of trusted certificate authorities. This is
called the system list.
• User-defined list. You can customize a list of trusted certificate authorities and then import the list onto
the email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
691
Encrypting Communication with Other MTAs
Viewing the Pre-Installed list of Certificate Authorities
You can use either the system list or the customized list, and you can also use both lists to verify certificate
from a remote domain.
Manage the lists using the Network > Certificates > Edit Certificate Authorities page in the GUI or the
certconfig > certauthority command in the CLI.
On the Network > Certificates > Edit Certificate Authorities page, you can perform the following tasks:
• View the system list (pre-installed) of certificate authorities. For more information, see Viewing the
Pre-Installed list of Certificate Authorities, on page 692.
• Choose whether or not to use the system list. You can enable or disable the system list. For more
information, see Disabling the System Certificate Authority List, on page 692.
• Choose whether or not to use a custom certificate authority list. You can enable the email gateway
to use a custom list and then import the list from a text file. For more information, see Importing a Custom
Certificate Authority List, on page 693.
• Export the list of certificate authorities to a file. You can export either the system or customized list
of certificate authorities to a text file. For more information, see Exporting a Certificate Authorities List,
on page 693.
Related Topics
• Viewing the Pre-Installed list of Certificate Authorities, on page 692
• Disabling the System Certificate Authority List, on page 692
• Importing a Custom Certificate Authority List, on page 693
• Exporting a Certificate Authorities List, on page 693
• Certificate Updates, on page 694
• Managing Trusted Root Certificates, on page 694
Viewing the Pre-Installed list of Certificate Authorities
Procedure
Step 1 Navigate to the Network > Certificates page.
Step 2 Click Edit Settings in the Certificate Authorities section.
Step 3 Click View System Certificate Authorities.
Disabling the System Certificate Authority List
The pre-installed system certificate authorities list cannot be removed from the email gateway, but you can
enable or disable it. You might want to disable it to allow the email gateway to only use your custom list to
verify certificates from remote hosts.
Procedure
Step 1 Navigate to the Network > Certificates page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
692
Encrypting Communication with Other MTAs
Importing a Custom Certificate Authority List
Step 2 Click Edit Settings in the Certificate Authorities section.
Step 3 Click Disable for the System List.
Step 4 Submit and commit your changes.
Importing a Custom Certificate Authority List
You can create a custom of list trusted certificate authorities and import it onto the email gateway. The file
must be in the PEM format and include certificates for the certificate authorities that you want the email
gateway to trust.
Procedure
Step 1 Navigate to the Network > Certificates page.
Step 2 Click Edit Settings in the Certificate Authorities section.
Step 3 Click Enable for the Custom List.
Step 4 Enter the full path to the custom list on a local or network machine.
Step 5 Select the FQDN Validation check box to allow the email gateway to check whether the 'Common Name,'
'SAN: DNS Name' fields, or both present in the certificate, are in the FQDN format.
Step 6 Submit and commit your changes.
Exporting a Certificate Authorities List
If you want to use only a subset of the trusted certificate authorities in the system or edit an existing custom
list, you can export the list to a .txt file and edit it to add or remove certificate authorities. After you have
finished editing the list, import the file back onto the email gateway as a custom list.
Procedure
Step 1 Navigate to the Network > Certificates page.
Step 2 Click Edit Settings in the Certificate Authorities section.
Step 3 Click Export List.
AsyncOS displays the Export Certificate Authority List page.
Step 4 Select the list you want to export.
Step 5 Enter a filename for the list.
Step 6 Click Export.
AsyncOS displays a dialog box asking if want to open or save the list as a .txt file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
693
Encrypting Communication with Other MTAs
Certificate Updates
Certificate Updates
The Updates section under Certificate Lists displays the version and last-updated information for the Cisco
trusted-root-certificate (system CA certificate) bundle on the email gateway. The bundle is updated periodically.
Click Update Now on the Certificates page to update the existing Cisco trusted-root-certificate (system CA
certificate) bundle to the latest available version.
Managing Trusted Root Certificates
You can view the count and details of the following certificates in your email gateway:
• Custom Trusted Root (custom CA) certificates
• Cisco Trusted Root (system CA) certificates
Procedure
Step 1 Navigate to Network > Certificates page.
Step 2 Click Manage Trusted Root Certificates under the Certificate Lists section to view the details of the custom
or system CA certificates.
Step 3 Click the required certificate link (for example, 'Admin-Root-CA') under the Cisco Trusted Root Certificate
List section to view the certificate details.
Step 4 [Optional] Click the Download Certificate link below the certificate (for example, 'Admin-Root-CA') details
to download the certificate.
Note You can also click the required certificate link under the Custom Trusted Root Certificates List
section to view or download the certificate details.
Note You can also delete a Custom Trusted Root (custom CA) certificate, if required.
Enabling a Certificate for HTTPS
You can enable a certificate for HTTPS services on an IP interface using either the Network > IP Interfaces
page in the GUI or the interfaceconfig command in the CLI.
Procedure
Step 1 Navigate to the Network > IP Interfaces page.
Step 2 Select the interface you want to enable the HTTPS service.
Step 3 Under Appliance Management, check the HTTPS check box and enter the port number.
Step 4 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
694
Encrypting Communication with Other MTAs
Enabling a Certificate for HTTPS
What to do next
Note The demonstration certificate that is pre-installed on the email gateway. You may enable HTTPS services
with the demonstration certificate for testing purposes, but it is not secure and is not recommended for general
use.
You can enable HTTPS services using the System Setup Wizard in the GUI. For more information , see Setup
and Installation, on page 25.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
695
Encrypting Communication with Other MTAs
Enabling a Certificate for HTTPS
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
696
CHAPTER 30
Configuring Routing and Delivery Features
This chapter contains the following sections:
• Routing Email for Local Domains, on page 697
• Rewriting Addresses, on page 702
• Creating Alias Tables, on page 703
• Configuring Masquerading, on page 710
• The Domain Map Feature, on page 720
• Directing Bounced Email, on page 726
• Controlling Email Delivery Using Destination Controls, on page 734
• Bounce Verification, on page 742
• Set Email Delivery Parameters, on page 746
• Configuring Mail Gateways for all Hosted Domains Using Virtual Gateway™ Technology, on page 749
• Using Global Unsubscribe, on page 757
• Review: Email Pipeline, on page 760
Routing Email for Local Domains
In Configuring the Gateway to Receive Email, on page 77 you customized private and public listeners to
service SMTP connections for an Enterprise Gateway configuration. Those listeners were customized to
handle specific connections (via HAT modification) and receive mail for specific domains (via RAT
modification of public listeners).
The email gateway routes mail to local domains to hosts specified via the Network > SMTP Routes page
(or the smtproutes command). This feature is similar to the sendmail mailertable feature.
Note If you have completed the GUI’s System Setup Wizard (or the Command Line Interface systemsetup command)
as described in the “Setup and Installation” chapter and committed the changes, you defined the first SMTP
route entries on the email gateway for each RAT entry you entered at that time.
Related Topics
• SMTP Routes Overview, on page 698
• Default SMTP Route, on page 698
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
697
Configuring Routing and Delivery Features
SMTP Routes Overview
• Defining an SMTP Route, on page 699
• SMTP Routes Limits, on page 699
• SMTP Routes and DNS, on page 699
• SMTP Routes and Alerts, on page 700
• SMTP Routes, Mail Delivery, and Message Splintering, on page 700
• SMTP Routes and Outbound SMTP Authentication, on page 700
• Managing SMTP Routes to Send Outbound Email Using the GUI, on page 700
SMTP Routes Overview
SMTP Routes allow you to redirect all email for a particular domain to a different mail exchange (MX) host.
For example, you could make a mapping from example.com to groupware.example.com . This mapping
causes any email with @example.com in the Envelope Recipient address to go instead to groupware.example.com
. The system performs an “MX” lookup on groupware.example.com , and then performs an “A” lookup on
the host, just like a normal email delivery. This alternate MX host does not need to be listed in DNS MX
records and it does not even need to be a member of the domain whose email is being redirected. The AsyncOS
operating system allows up to forty thousand (40,000) SMTP Route mappings to be configured for your email
gateway. (See SMTP Routes Limits, on page 699)
This feature also allows host “globbing.” If you specify a partial domain, such as .example.com , then any
domain ending in example.com matches the entry. For instance, [email protected] and
[email protected] both match the mapping.
If a host is not found in the SMTP Routes table, an MX lookup is performed using DNS. The result is not
re-checked against the SMTP Routes table. If the DNS MX entry for foo.domain is bar.domain , any email
sent to foo.domain is delivered to the host bar.domain . If you create a mapping for bar.domain to some
other host, email addressed to foo.domain is not affected.
In other words, recursive entries are not followed. If there is an entry for a.domain to redirect to b.domain ,
and a subsequent entry to redirect email for b.domain to a.domain , a mail loop will not be created. In this
case, email addressed to a.domain will be delivered to the MX host specified by b.domain , and conversely
email addressed to b.domain will be delivered to the MX host specified by a.domain .
The SMTP Routes table is read from the top down for every email delivery. The most specific entry that
matches a mapping wins. For example, if there are mappings for both host1.example.com and .example.com
in the SMTP Routes table, the entry for host1.example.com will be used because it is the more specific entry
— even if it appears after the less specific .example.com entry. Otherwise, the system performs a regular MX
lookup on the domain of the Envelope Recipient.
Default SMTP Route
You can also define a default SMTP route with the special keyword ALL . If a domain does not match a previous
mapping in the SMTP Routes list, it defaults to being redirected to the MX host specified by the ALL entry.
When you print the SMTP Routes entries, the default SMTP route is listed as ALL: . You cannot delete the
default SMTP route; you may only clear any values entered for it.
Configure the default SMTP route via the Network > SMTP Routes page or the smtproutes command.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
698
Configuring Routing and Delivery Features
Defining an SMTP Route
Defining an SMTP Route
Use the Network > SMTP Routes page (or the smtproutes command) to construct routes. When you create
a new route, you first specify the domain or partial domain for which you want to create a permanent route.
You then specify destination hosts. Destination hosts can be entered as fully-qualified hostnames or as IP
addresses. IP addresses can be either Internet Protocol version 4 (IPv4) or version 6 (IPv6).
For IPv6 addresses, AsyncOS supports the following formats:
• 2620:101:2004:4202::0-2620:101:2004:4202::ff
• 2620:101:2004:4202::
• 2620:101:2004:4202::23
• 2620:101:2004:4202::/64
You can also specify a a special destination host of /dev/null to drop the messages that match the entry. (So,
in effect, specifying /dev/null for the default route is will ensure that no mail received by the email gateway
is ever delivered.)
A receiving domain can have multiple destination hosts, each assigned a priority number, much like an MX
record. The destination host with the lowest number identifies as the primary destination host for the receiving
domain. Other destination hosts listed will be used as backup.
Destinations with identical priority will be used in a “round-robin” fashion. The round-robin process is based
on SMTP connections, and is not necessarily message-based. Also, if one or more of the destination hosts are
not responding, messages will be delivered to one of the reachable hosts. If all the configured destination
hosts are not responding, mail is queued for the receiving domain and delivery to the destination hosts is
attempted later. (It does not fail over to using MX records).
When constructing routes using the smtproutes command in the CLI, you can prioritize each destination host
by using /pri= , followed by an integer between 0 and 65535 to assign priority ( 0 is the highest priority)
after the hostname or IP address. For example, host1.example.com/pri=0 has a higher priority than
host2.example.com/pri=10. Separate multiple entries with commas.
SMTP Routes Limits
You can define up to 40,000 routes. The final default route of ALL is counted as a route against this limit.
Therefore, you can define up to 39,999 custom routes and one route that uses the special keyword ALL .
SMTP Routes and DNS
Use the special keyword USEDNS to tell the email gateway to do MX lookups to determine next hops for
specific domains. This is useful when you need to route mail for subdomains to a specific host. For example,
if mail to example.com is to be sent to the company’s Exchange server, you might have something similar to
the following SMTP route:
example.com exchange.example.com
However, for mail to various subdomains (foo.example.com), add an SMTP route that looks like this:
.example.com USEDNS
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
699
Configuring Routing and Delivery Features
SMTP Routes and Alerts
SMTP Routes and Alerts
Alerts sent from the email gateway to addresses specified in the System Administration > Alerts page (or the
alertconfig command) follow SMTP Routes defined for those destinations.
SMTP Routes, Mail Delivery, and Message Splintering
Incoming: if one message has 10 recipients and they are all on the same Exchange server, AsyncOS will open
one TCP connection and present exactly one message to the mail store, not 10 separate messages.
Outgoing: works similarly, but if one message is going to 10 recipients in 10 different domains, AsyncOS
will open 10 connections to 10 MTAs and deliver them one email each.
Splintering: if one incoming message has 10 recipients and they are each in separate Incoming Policy groups
(10 groups), the message will splinter even if all 10 recipients are on the same Exchange server. Thus, 10
separate emails will be delivered over a single TCP connection.
SMTP Routes and Outbound SMTP Authentication
If an Outbound SMTP Authentication profile has been created, you can apply it to an SMTP Route. This
allows authentication for outgoing mail in cases where the email gateway sits behind a mail relay server that
is at the edge of the network. For more information about Outbound SMTP Authentication, see Outgoing
SMTP Authentication, on page 811.
Managing SMTP Routes to Send Outbound Email Using the GUI
Use the Network > SMTP Routes page to manage SMTP Routes on your email gateway. You can add, modify,
and delete mappings in the table. You can export or import the SMTP Routes entries.
Related Topics
• Adding SMTP Routes, on page 700
• Exporting SMTP Routes, on page 701
• Importing SMTP Routes, on page 701
Adding SMTP Routes
Procedure
Step 1 Click Add Route on the Network > SMTP Routes page.
Step 2 Enter a receiving domain. This can be a hostname, domain, IPv4 address, or IPv6 address.
Step 3 Enter a destination host. This can be a hostname, IPv4 address, or IPv6 address. You can add multiple
destination hosts by clicking Add Row and entering the next destination host in the new row.
Note You can specify a port number by adding “:<port number> ” to the destination host: example.com:25.
Step 4 If you add multiple destination hosts, enter an integer between 0 and 65535 to assign priority to the hosts. 0
is the highest priority. See Defining an SMTP Route, on page 699for more information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
700
Configuring Routing and Delivery Features
Exporting SMTP Routes
Step 5 Submit and commit your changes.
Exporting SMTP Routes
Similar to the Host Access Table (HAT) and the Recipient Access Table (RAT), you can also modify SMTP
routes mappings by exporting and importing a file. To export the SMTP Routes:
Procedure
Step 1 Click Export SMTP Routes on the SMTP Routes page.
Step 2 Enter a name for the file and click Submit.
Importing SMTP Routes
Similar to the Host Access Table (HAT) and the Recipient Access Table (RAT), you can also modify SMTP
routes mappings by exporting and importing a file. To import SMTP Routes:
Procedure
Step 1 Click Import SMTP Routes on the SMTP Routes page.
Step 2 Select the file that contains the exported SMTP Routes.
Step 3 Click Submit. You are warned that importing will replace all existing SMTP Routes. All of the SMTP Routes
in the text file are imported.
Step 4 Click Import.
You can place “comments” in the file. Lines that begin with a ‘#’ character are considered comments and are
ignored by AsyncOS. For example:
# this is a comment, but the next line is not
ALL:
What to do next
At this point, our Email Gateway configuration looks like this:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
701
Configuring Routing and Delivery Features
Rewriting Addresses
Figure 46: SMTP Routes Defined for a Public Listene
Rewriting Addresses
AsyncOS provides several methods for rewriting Envelope Sender and Recipient addresses in the email
pipeline. Rewriting addresses can be used, for example, to redirect mail sent to a partner domain or to hide
(“mask”) your internal infrastructure.
The following table provides an overview of the various features used for rewriting sender and recipient email
addresses.
Table 55: Methods for Rewriting Addresses
Original Address Change to Feature Works on
*@anydomain user@domain Alias Tables (see Creating • Envelope Recipients only
Alias Tables, on page 703 ) • Applied globally
• Maps aliases to email
addresses or other aliases
*@olddomain *@newdomain Domain Mapping (see The • Envelope Recipients only
Domain Map Feature, on page • Applied per listener
720)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
702
Configuring Routing and Delivery Features
Creating Alias Tables
Original Address Change to Feature Works on
*@olddomain *@newdomain Masquerading (see • Envelope Sender and the
Configuring Masquerading, on To:, From:, and/or CC:
page 710) headers
• Applied per listener
Creating Alias Tables
Alias tables provide a mechanism to redirect messages to one or more recipients. You can construct a mapping
table of aliases to usernames and other aliases in a similar fashion to the /etc/mail/aliases feature of a
sendmail configuration on some Unix systems.
When the Envelope Recipient (also known as the Envelope To, or RCPT TO ) of an email accepted by a listener
matches an alias as defined in an alias table, the Envelope Recipient address of the email will be rewritten.
Note A listener checks the alias table and modifies the recipients after checking the RAT and before message filters.
See the “Understanding the Email Pipeline” chapter.
Note The Alias Table functionality actually rewrites the Envelope Recipient of the email. This is different than the
smtproutes command (see Directing Bounced Email, on page 726), which does not rewrite the Envelope
Recipient of the email, but instead simply reroutes the email to specified domains.
Related Topics
• Configuring an Alias Table from the Command Line, on page 703
• Exporting and Importing an Alias Table , on page 704
• Deleting Entries from the Alias Table, on page 705
Configuring an Alias Table from the Command Line
Alias tables are defined in sections as follows: each section is headed by a domain context, which is a list of
domains that the section is relevant to, followed by a list of maps.
A domain context is a list of one or more domains or partial domains, separated by commas and enclosed in
square brackets (' [ ' and ' ] '). A domain is a string containing letters, digits hyphens, and periods as defined
in RFC 1035, section 2.3.1., “Preferred name syntax.” A partial domain, such as .example.com is a domain
that begins with a period. All domains that end with a substring matching the partial domain are considered
a match. For example, the domain context .example.com would match mars.example.com and
venus.example.com . Below the domain context is a list of maps, which are aliases followed by a list of
recipients. A map is constructed as follows:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
703
Configuring Routing and Delivery Features
Exporting and Importing an Alias Table
Table 56: Alias Table Syntax
Left-hand Side (LHS) Separator Right-hand Side (RHS)
a list of one or more aliases to the colon character (“ : a list of one or more recipient addresses or aliases
match ”)
An alias in the left-hand side can contain the following formats:
username Specifies an alias to match. There must be a preceding “domains” attribute
specified in the table. The lack of this parameter will produce an error.
user@domain Specifies an exact email address to match on.
You can enter multiple aliases, separated by commas on a single left-hand side line.
Each recipient in the right-hand side can be a full user@domain email address, or another alias.
An alias file can contain “global” aliases (aliases that are applied globally instead of to a specific domain)
with no implied domain, domain contexts within which aliases have one or more implied domains, or both.
“Chains” (or recursive entries) of aliases may be created, but they must end in a full email address.
A special destination of /dev/null is supported to drop the message in order to be compatible with context
of a sendmail configuration. If a message is mapped to /dev/null via an alias table, the dropped counter is
increased. (See the “Managing and Monitoring via the CLI” chapter.) The recipient is accepted but not
enqueued.
Related Topics
• Example Alias Table, on page 705
• Example aliasconfig Command, on page 707
Exporting and Importing an Alias Table
To import an alias table, first see FTP, SSH, and SCP Access, on page 1297to ensure that you can access the
email gateway.
Use the export subcommand of the aliasconfig command to save any existing alias table. A file (whose
name you specify) will be written to the /configuration directory for the listener. You can modify this file
outside of the CLI and then re-import it. (If you have malformed entries in the file, errors are printed when
you try to import the file.)
Place the alias table file in the /configuration directory, and then use the import subcommand of the
aliasconfig command to upload the file.
Comment out lines in the table using a number symbol (#) at the beginning of each line.
Remember to issue the commit command after you import an alias table file so that the configuration changes
take effect.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
704
Configuring Routing and Delivery Features
Deleting Entries from the Alias Table
Deleting Entries from the Alias Table
If you delete entries from the alias table from the command line interface (CLI), you are prompted to choose
a domain group first. Choose the “ALL (any domain)” entry to see a numbered list of aliases that apply to all
domains. Then choose the number(s) of the aliases you want to delete.
Example Alias Table
Note All entries in this example table have been commented out.
# sample Alias Table file
# copyright (c) 2001-2005, IronPort Systems, Inc.
# Incoming Envelope To addresses are evaluated against each
# entry in this file from top to bottom. The first entry that
# matches will be used, and the Envelope To will be rewritten.
# Separate multiple entries with commas.
# Global aliases should appear before the first domain
# context. For example:
# [email protected]: [email protected]
# [email protected]: [email protected]
# This alias has no implied domain because it appears
# before a domain context:
# [email protected]: [email protected]
# The following aliases apply to recipients @ironport.com and
# any subdomain within .example.com because the domain context
# is specified.
# Email to [email protected] or [email protected] will
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
705
Configuring Routing and Delivery Features
Example Alias Table
# be delivered to [email protected].
# Similarly, email to [email protected] will be
# delivered to [email protected]
# [ironport.com, .example.com]
# joe, fred: [email protected]
# In this example, email to partygoers will be sent to
# three addresses:
# partygoers: [email protected], [email protected], [email protected]
# In this example, mail to [email protected] will be delivered to
# [email protected]. Note that mail to [email protected] will
# NOT be processed by the alias table because the domain context
# overrides the previous domain context.
# [example.com]
# help: [email protected]
# In this example, mail to [email protected] is dropped.
# [email protected]: /dev/null
# "Chains" may be created, but they must end in an email address.
# For example, email to "all" will be sent to 9 addresses:
# [example.com]
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
706
Configuring Routing and Delivery Features
Example aliasconfig Command
# all: sales, marketing, engineering
# sales: [email protected], [email protected], [email protected]
# marketing:[email protected], advertising
# engineering:[email protected], [email protected], [email protected]
# advertising:[email protected], [email protected]
Example aliasconfig Command
In this example, the aliasconfig command is used to construct an alias table. First, the domain context of
example.com is specified. Then, an alias of customercare is constructed so that any email sent to
[email protected] is redirected to [email protected] , [email protected] , and [email protected].
Next, a global alias of admin is constructed so that an email sent to admin is redirected to
[email protected]. Finally, the alias table is printed to confirm.
Note that when the table is printed, the global alias for admin appears before the first domain context of
example.com .
mail3.example.com> aliasconfig
No aliases in table.
Choose the operation you want to perform:
- NEW - Create a new entry.
- IMPORT - Import aliases from a file.
[]> new
How do you want your aliases to apply?
1. Globally
2. Add a new domain context
[1]> 2
Enter new domain context.
Separate multiple domains with commas.
Partial domains such as .example.com are allowed.
[]> example.com
Enter the alias(es) to match on.
Separate multiple aliases with commas.
Allowed aliases:
- "user" - This user in this domain context.
- "user@domain" - This email address.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
707
Configuring Routing and Delivery Features
Example aliasconfig Command
[]> customercare
Enter address(es) for "customercare".
Separate multiple addresses with commas.
[]> [email protected], [email protected], [email protected]
Adding alias customercare: [email protected],[email protected],[email protected]
Do you want to add another alias? [N]> n
There are currently 1 mappings defined.
Choose the operation you want to perform:
- NEW - Create a new entry.
- EDIT - Modify an entry.
- DELETE - Remove an entry.
- PRINT - Display the table.
- IMPORT - Import aliases from a file.
- EXPORT - Export table to a file.
- CLEAR - Clear the table.
[]> new
How do you want your aliases to apply?
1. Globally
2. Add a new domain context
3. example.com
[1]> 1
Enter the alias(es) to match on.
Separate multiple aliases with commas.
Allowed aliases:
- "user@domain" - This email address.
- "user" - This user for any domain
- "@domain" - All users in this domain.
- "@.partialdomain" - All users in this domain, or any of its sub domains.
[]> admin
Enter address(es) for "admin".
Separate multiple addresses with commas.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
708
Configuring Routing and Delivery Features
Example aliasconfig Command
Adding alias admin: [email protected]
Do you want to add another alias? [N]> n
There are currently 2 mappings defined.
Choose the operation you want to perform:
- NEW - Create a new entry.
- EDIT - Modify an entry.
- DELETE - Remove an entry.
- PRINT - Display the table.
- IMPORT - Import aliases from a file.
- EXPORT - Export table to a file.
- CLEAR - Clear the table.
admin: [email protected]
[ example.com ]
customercare: [email protected], [email protected], [email protected]
There are currently 2 mappings defined.
Choose the operation you want to perform:
- NEW - Create a new entry.
- EDIT - Modify an entry.
- DELETE - Remove an entry.
- PRINT - Display the table.
- IMPORT - Import aliases from a file.
- EXPORT - Export table to a file.
- CLEAR - Clear the table.
[]>
At this point, our Email Gateway configuration looks like this:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
709
Configuring Routing and Delivery Features
Configuring Masquerading
Figure 47: Alias Tables Defined for the Email Gateway
Configuring Masquerading
Masquerading is a feature that rewrites the Envelope Sender (also known as the sender, or MAIL FROM )
and the To:, From:, and/or CC: headers on email processed by a listener according to a table that you construct.
A typical example implementation of this feature is “Virtual Domains,” which allows you to host multiple
domains from a single site. Another typical implementation is “hiding” your network infrastructure by
“stripping” the subdomains from strings in email headers. The Masquerading feature is available for both
private and public listeners.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
710
Configuring Routing and Delivery Features
Masquerading and altsrchost
Note The Masquerading feature is configured on a per-listener basis, as opposed to the Alias Tables functionality,
which is configured for the entire system.
A listener checks the masquerading table for matches and modifies the recipients while the message is in the
work queue, immediately after LDAP recipient acceptance queries and before LDAP routing queries. See the
“Understanding the Email Pipeline” chapter.
The Masquerading feature actually rewrites addresses for the Envelope Sender and the To:, From:, and CC:
fields of the email that has been received. You can specify different masquerading parameters for each listener
you create in one of two ways:
• via a static table of mappings you create
• via an LDAP query.
This section discusses the static table method. The table format is forward-compatible with the
/etc/mail/genericstable feature of a sendmail configuration on some Unix systems. See LDAP Queries, on
page 775for more information on LDAP masquerading queries.
Related Topics
• Masquerading and altsrchost, on page 711
Masquerading and altsrchost
Generally, the masquerading feature rewrites the Envelope Sender, and any subsequent actions to be performed
on the message will be “triggered” from the masqueraded address. However, when you run the altscrchost
command from the CLI, the altsrchost mappings are triggered from the original address (and not the modified,
masqueraded address).
For more information, see Configuring Mail Gateways for all Hosted Domains Using Virtual Gateway™
Technology, on page 749and Review: Email Pipeline, on page 760.
Related Topics
• Configuring Static Masquerading Tables, on page 711
• Sample Masquerading Table for a Private Listener, on page 712
• Importing a Masquerading Table , on page 713
• Example Masquerading , on page 713
Configuring Static Masquerading Tables
You configure the static masquerading table of mappings by using the edit -> masquerade subcommand of
the listenerconfig command. Alternatively, you can import a file containing the mappings. See Importing a
Masquerading Table , on page 713. The subcommand creates and maintains a table that maps input addresses,
usernames, and domains to new addresses and domains. See LDAP Queries, on page 775for more information
on LDAP masquerading queries.
When messages are injected into the system, the table is consulted, and the message is rewritten if a match in
the header is found.
A domain masquerading table is constructed as follows:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
711
Configuring Routing and Delivery Features
Sample Masquerading Table for a Private Listener
Table 57: Masquerading Table Syntax
Left-hand Side (LHS) Separator Right-hand Side (RHS)
a list of one or more whitespace (space or tab the rewritten username and/or domain
usernames and/or domains to character)
match
The following table lists valid entries in the masquerading table:
Left-hand Side (LHS) Right-hand Side (RHS)
username username@domain
This entry specifies a username to match. Incoming email messages matching a username on the left-hand
side are matched and rewritten with the address on the right-hand size. The right-hand side must be a full
address.
user@domain username@domain
The entry specifies an exact address to match. Incoming messages matching a full address on the left-hand
side are rewritten with the address listed on the right-hand side. The right-hand side must be a full address.
@domain @domain
This entry specifies any address with the specified domain. The original domain on the left-hand side is
replaced with the domain in the right-hand side, leaving the username intact.
@.partialdomain @domain
This entry specifies any address with the specified domain. The original domain on the left-hand side is
replaced with the domain in the right-hand side, leaving the username intact.
ALL @domain
The ALL entry matches bare addresses and rewrites them with the address on the right-hand side. The
right-hand side must be a domain preceded by an “ @ ”. This entry always has the lowest precedence
regardless of its location in the table.
Note You can use the ALL entry for private listeners only.
• Rules are matched by the order in which they appear in the masquerading table.
• Addresses in the From:, To:, and CC: fields in the headers are matched and rewritten upon receiving by
default. You can also configure the option to match and rewrite the Envelope Sender. Enable and disable
the Envelope Sender and which headers to rewrite using the config subcommand.
• You can comment out lines in the table using a number symbol (#) at the beginning of each line. Everything
following a # to the end of the line will be considered a comment and ignored.
• A masquerading table is limited to 400,000 entries, whether you create them via the new subcommand
or import them from a file.
Sample Masquerading Table for a Private Listener
# sample Masquerading file
@.example.com @example.com # Hides local subdomains in the header
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
712
Configuring Routing and Delivery Features
Importing a Masquerading Table
sales [email protected]
@techsupport [email protected]
user@localdomain [email protected]
ALL @bigsender.com
Importing a Masquerading Table
A traditional sendmail /etc/mail/genericstable file can be imported. To import a genericstable file, first
see FTP, SSH, and SCP Access, on page 1297to ensure that you can access the email gateway.
Place the genericstable file in the configuration directory, and then use the import subcommand of the
masquerade subcommand to upload the file. Use the commands in this order:
listenerconfig -> edit -> listener_number -> masquerade -> import
Alternatively, you can use the export subcommand to download the existing configuration. A file (whose
name you specify) will be written to the configuration directory. You can modify this file outside of the CLI
and then import it again.
When you use the import subcommand, ensure that the file contains only valid entries. If there is an invalid
entry (for example, a left-hand side with no right-hand side), the CLI reports syntax errors when you import
the file. If there is a syntax error during import, no mappings in the entire file are imported.
Remember to issue the commit command after you import a genericstable file so that the configuration
changes for the listener take effect.
Example Masquerading
In this example, the masquerade subcommand of listenerconfig is used to construct a domain masquerading
table for the private listener named “OutboundMail” on the PrivateNet interface.
First, the option to use LDAP for masquerading is declined. (For information on configuring LDAP
masquerading queries, see LDAP Queries, on page 775for more information on LDAP masquerading queries.)
Then, a partial domain notation of @.example.com is mapped to @example.com so that any email sent from
any machine in the subdomain of .example.com will be mapped to example.com . Then, the username joe
is mapped to the domain [email protected]. The domain masquerading table is then printed to confirm both
entries, and then exported to a file named masquerade.txt . The config subcommand is used to disable
re-writing addresses in the CC: field, and finally, the changes are committed.
mail3.example.com> listenerconfig
Currently configured listeners:
1. InboundMail (on PublicNet, 192.168.2.1) SMTP TCP Port 25 Public
2. OutboundMail (on PrivateNet, 192.168.1.1) SMTP TCP Port 25 Private
Choose the operation you want to perform:
- NEW - Create a new listener.
- EDIT - Modify a listener.
- DELETE - Remove a listener.
- SETUP - Change global settings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
713
Configuring Routing and Delivery Features
Example Masquerading
[]> edit
Enter the name or number of the listener you wish to edit.
[]> 2
Name: OutboundMail
Type: Private
Interface: PrivateNet (192.168.1.1/24) TCP Port 25
Protocol: SMTP
Default Domain:
Max Concurrency: 600 (TCP Queue: 50)
Domain Map: Disabled
TLS: No
SMTP Authentication: Disabled
Bounce Profile: Default
Footer: None
LDAP: Off
Choose the operation you want to perform:
- NAME - Change the name of the listener.
- INTERFACE - Change the interface.
- LIMITS - Change the injection limits.
- SETUP - Configure general options.
- HOSTACCESS - Modify the Host Access Table.
- BOUNCECONFIG - Choose the bounce profile to use for messages injected on this
listener.
- MASQUERADE - Configure the Domain Masquerading Table.
- DOMAINMAP - Configure domain mappings.
- LDAPACCEPT - Configure an LDAP query to determine whether a recipient address should
be accepted or bounced/dropped.
- LDAPROUTING - Configure an LDAP query to reroute messages.
- LDAPGROUP - Configure an LDAP query to determine whether a sender or
recipient is in a specified group.
- SMTPAUTH - Configure an SMTP authentication.
[]> masquerade
Do you want to use LDAP for masquerading? [N]> n
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
714
Configuring Routing and Delivery Features
Example Masquerading
Domain Masquerading Table
There are currently 0 entries.
Masqueraded headers: To, From, Cc
Choose the operation you want to perform:
- NEW - Create a new entry.
- DELETE - Remove an entry.
- PRINT - Display all entries.
- IMPORT - Import all entries from a file.
- EXPORT - Export all entries to a file.
- CONFIG - Configure masqueraded headers.
- CLEAR - Remove all entries.
[]> new
Enter the source address or domain to masquerade.
Usernames like "joe" are allowed.
Full addresses like "[email protected]" are allowed.
Full addresses with subdomain wildcards such as "[email protected]" are allowed.
Domains like @example.com and @.example.com are allowed.
Hosts like @training and @.sales are allowed.
[]> @.example.com
Enter the masqueraded address or domain.
Domains like @example.com are allowed.
Full addresses such as [email protected] are allowed.
[]> @example.com
Entry mapping @.example.com to @example.com created.
Domain Masquerading Table
There are currently 1 entries.
Masqueraded headers: To, From, Cc
Choose the operation you want to perform:
- NEW - Create a new entry.
- DELETE - Remove an entry.
- PRINT - Display all entries.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
715
Configuring Routing and Delivery Features
Example Masquerading
- IMPORT - Import all entries from a file.
- EXPORT - Export all entries to a file.
- CONFIG - Configure masqueraded headers.
- CLEAR - Remove all entries.
[]> new
Enter the source address or domain to masquerade.
Usernames like "joe" are allowed.
Full addresses like "[email protected]" are allowed.
Full addresses with subdomain wildcards such as "[email protected]" are allowed.
Domains like @example.com and @.example.com are allowed.
Hosts like @training and @.sales are allowed.
[]> joe
Enter the masqueraded address.
Only full addresses such as [email protected] are allowed.
Entry mapping joe to [email protected] created.
Domain Masquerading Table
There are currently 2 entries.
Masqueraded headers: To, From, Cc
Choose the operation you want to perform:
- NEW - Create a new entry.
- DELETE - Remove an entry.
- PRINT - Display all entries.
- IMPORT - Import all entries from a file.
- EXPORT - Export all entries to a file.
- CONFIG - Configure masqueraded headers.
- CLEAR - Remove all entries.
@.example.com @example.com
Domain Masquerading Table
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
716
Configuring Routing and Delivery Features
Example Masquerading
There are currently 2 entries.
Masqueraded headers: To, From, Cc
Choose the operation you want to perform:
- NEW - Create a new entry.
- DELETE - Remove an entry.
- PRINT - Display all entries.
- IMPORT - Import all entries from a file.
- EXPORT - Export all entries to a file.
- CONFIG - Configure masqueraded headers.
- CLEAR - Remove all entries.
[]> export
Enter a name for the exported file:
[]> masquerade.txt
Export completed.
Domain Masquerading Table
There are currently 2 entries.
Masqueraded headers: To, From, Cc
Choose the operation you want to perform:
- NEW - Create a new entry.
- DELETE - Remove an entry.
- PRINT - Display all entries.
- IMPORT - Import all entries from a file.
- EXPORT - Export all entries to a file.
- CONFIG - Configure masqueraded headers.
- CLEAR - Remove all entries.
[]> config
Do you wish to masquerade Envelope Sender?
[N]> y
Do you wish to masquerade From headers?
[Y]> y
Do you wish to masquerade To headers?
[Y]> y
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
717
Configuring Routing and Delivery Features
Example Masquerading
Do you wish to masquerade CC headers?
[Y]> n
Do you wish to masquerade Reply-To headers?
[Y]> n
Domain Masquerading Table
There are currently 2 entries.
- NEW - Create a new entry.
- DELETE - Remove an entry.
- PRINT - Display all entries.
- IMPORT - Import all entries from a file.
- EXPORT - Export all entries to a file.
- CONFIG - Configure masqueraded headers.
- CLEAR - Remove all entries.
[]>
Name: OutboundMail
Type: Private
Interface: PrivateNet (192.168.1.1/24) TCP Port 25
Protocol: SMTP
Default Domain:
Max Concurrency: 600 (TCP Queue: 50)
Domain Map: Disabled
TLS: No
SMTP Authentication: Disabled
Bounce Profile: Default
Footer: None
LDAP: Off
Choose the operation you want to perform:
- NAME - Change the name of the listener.
- INTERFACE - Change the interface.
- LIMITS - Change the injection limits.
- SETUP - Configure general options.
- HOSTACCESS - Modify the Host Access Table.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
718
Configuring Routing and Delivery Features
Example Masquerading
- BOUNCECONFIG - Choose the bounce profile to use for messages injected on this
listener.
- MASQUERADE - Configure the Domain Masquerading Table.
- DOMAINMAP - Configure domain mappings.
- LDAPACCEPT - Configure an LDAP query to determine whether a recipient address should
be accepted or bounced/dropped.
- LDAPROUTING - Configure an LDAP query to reroute messages.
- LDAPGROUP - Configure an LDAP query to determine whether a sender or
recipient is in a specified group.
- SMTPAUTH - Configure an SMTP authentication.
[]>
Currently configured listeners:
1. InboundMail (on PublicNet, 192.168.2.1) SMTP TCP Port 25 Public
2. OutboundMail (on PrivateNet, 192.168.1.1) SMTP TCP Port 25 Private
Choose the operation you want to perform:
- NEW - Create a new listener.
- EDIT - Modify a listener.
- DELETE - Remove a listener.
- SETUP - Change global settings.
[]>
Our Enterprise Gateway configuration now looks like this:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
719
Configuring Routing and Delivery Features
The Domain Map Feature
Figure 48: Masquerading Defined for a Private Listene
The Domain Map Feature
You can configure a “domain map” for listeners. For each listener you configure, you can construct a domain
map table which rewrites the Envelope Recipient for each recipient in a message that matches a domain in
the domain map table. This feature is similar to the sendmail “Domain Table” or Postfix “Virtual Table”
feature. Only the Envelope Recipient is affected; the “To:” headers are not re-written by this feature.
Note The processing of the domain map feature happens immediately before the RAT and right after Default Domain
is evaluated. See the “Understanding the Email Pipeline” chapter.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
720
Configuring Routing and Delivery Features
The Domain Map Feature
A common implementation of the domain map feature is to accept incoming mail for more than one legacy
domain. For example, if your company has acquired another company, you could construct a domain map on
the email gateway to accept messages for the acquired domain and rewrite the Envelope Recipients to your
company’s current domain.
Note You can configure up to 20,000 separate, unique domain mappings.
Table 58: Domain Map Table Example Syntax
Left Side Right Side Comments
[email protected] [email protected] Only complete address for the right side
[email protected] [email protected]
@example.com [email protected] Complete address or fully-qualified domain name.
or
@example.net
@.example.com [email protected]
or
@example.net
In the following example, the domainmap subcommand of the listenerconfig command is used to create a
domain map for the public listener “InboundMail.” Mail for the domain and any subdomain of
oldcompanyname.com is mapped to the domain example.com . The mapping is then printed for confirmation.
Contrast this example with the configuration of placing both domains in the listener’s RAT: the domain map
feature will actually rewrite the Envelope Recipient of [email protected] to [email protected] ,
whereas placing the domain oldcompanyname.com in the listener’s RAT will simply accept the message for
[email protected] and route it without rewriting the Envelope Recipient. Also, contrast this example
with the alias table feature. Alias tables must resolve to an explicit address; they cannot be constructed to map
“any username @domain ” to “the same username @newdomain .”
mail3.example.com> listenerconfig
Currently configured listeners:
1. Inboundmail (on PublicNet, 192.168.2.1) SMTP TCP Port 25 Public
2. Outboundmail (on PrivateNet, 192.168.1.1) SMTP TCP Port 25 Private
Choose the operation you want to perform:
- NEW - Create a new listener.
- EDIT - Modify a listener.
- DELETE - Remove a listener.
- SETUP - Change global settings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
721
Configuring Routing and Delivery Features
The Domain Map Feature
[]> edit
Enter the name or number of the listener you wish to edit.
[]> 1
Name: InboundMail
Type: Public
Interface: PublicNet (192.168.2.1/24) TCP Port 25
Protocol: SMTP
Default Domain:
Max Concurrency: 1000 (TCP Queue: 50)
Domain Map: Disabled
TLS: No
SMTP Authentication: Disabled
Bounce Profile: Default
Use SenderBase For Reputation Filters and IP Profiling: Yes
Footer: None
LDAP: Off
Choose the operation you want to perform:
- NAME - Change the name of the listener.
- INTERFACE - Change the interface.
- LIMITS - Change the injection limits.
- SETUP - Configure general options.
- HOSTACCESS - Modify the Host Access Table.
- RCPTACCESS - Modify the Recipient Access Table.
- BOUNCECONFIG - Choose the bounce profile to use for messages injected on this
listener.
- MASQUERADE - Configure the Domain Masquerading Table.
- DOMAINMAP - Configure domain mappings.
[]> domainmap
Domain Map Table
There are currently 0 Domain Mappings.
Domain Mapping is: disabled
Choose the operation you want to perform:
- NEW - Create a new entry.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
722
Configuring Routing and Delivery Features
The Domain Map Feature
- IMPORT - Import domain mappings from a file.
[]> new
Enter the original domain for this entry.
Domains such as "@example.com" are allowed.
Partial hostnames such as "@.example.com" are allowed.
Email addresses such as "[email protected]" and "[email protected]"
are also allowed.
[]> @.oldcompanyname.com
Enter the new domain for this entry.
The new domain may be a fully qualified
such as "@example.domain.com" or a complete
email address such as "[email protected]"
[]> @example.com
Domain Map Table
There are currently 1 Domain Mappings.
Domain Mapping is: enabled
Choose the operation you want to perform:
- NEW - Create a new entry.
- EDIT - Modify an entry.
- DELETE - Remove an entry.
- PRINT - Display all domain mappings.
- IMPORT - Import domain mappings from a file.
- EXPORT - Export domain mappings to a file.
- CLEAR - Clear all domain mappings.
@.oldcompanyname.com --> @example.com
Domain Map Table
There are currently 1 Domain Mappings.
Domain Mapping is: enabled
Choose the operation you want to perform:
- NEW - Create a new entry.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
723
Configuring Routing and Delivery Features
The Domain Map Feature
- EDIT - Modify an entry.
- DELETE - Remove an entry.
- PRINT - Display all domain mappings.
- IMPORT - Import domain mappings from a file.
- EXPORT - Export domain mappings to a file.
- CLEAR - Clear all domain mappings.
[]>
Name: InboundMail
Type: Public
Interface: PublicNet (192.168.2.1/24) TCP Port 25
Protocol: SMTP
Default Domain:
Max Concurrency: 1000 (TCP Queue: 50)
Domain Map: Enabled
TLS: No
SMTP Authentication: Disabled
Bounce Profile: Default
Use SenderBase For Reputation Filters and IP Profiling: Yes
Footer: None
LDAP: Off
Choose the operation you want to perform:
- NAME - Change the name of the listener.
- INTERFACE - Change the interface.
- LIMITS - Change the injection limits.
- SETUP - Configure general options.
- HOSTACCESS - Modify the Host Access Table.
- RCPTACCESS - Modify the Recipient Access Table.
- BOUNCECONFIG - Choose the bounce profile to use for messages injected on this
listener.
- MASQUERADE - Configure the Domain Masquerading Table.
- DOMAINMAP - Configure domain mappings.
[]>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
724
Configuring Routing and Delivery Features
Importing and Exporting a Domain Map Table
Related Topics
• Importing and Exporting a Domain Map Table , on page 725
Importing and Exporting a Domain Map Table
To import or export a domain map table, first see FTP, SSH, and SCP Access, on page 1297to ensure that you
can access the email gateway.
Create a text file of entries of domains to map. Separate the entries with white space (either a tab character
or spaces). Comment out lines in the table using a number symbol (#) at the beginning of each line.
Place the file in the configuration directory, and then use the import subcommand of the domain subcommand
to upload the file. Use the commands in this order:
listenerconfig -> edit -> inejctor_number -> domainmap -> import
Alternatively, you can use the export subcommand to download the existing configuration. A file (whose
name you specify) will be written to the configuration directory. You can modify this file outside of the CLI
and then import it again.
When you use the import subcommand, ensure that the file contains only valid entries. If there is an invalid
entry (for example, a left-hand side with no right-hand side), the CLI reports syntax errors when you import
the file. If there is a syntax error during import, no mappings in the entire file are imported.
Remember to issue the commit command after you import a domain map table file so that the configuration
changes for the listener take effect.
Our Enterprise Gateway configuration now looks like this:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
725
Configuring Routing and Delivery Features
Directing Bounced Email
Figure 49: Domain Map Defined for a Public Listener
Directing Bounced Email
Bounced email is an inevitable part of any email delivery. Your email gateway is able to process bounced
email in a number of highly configurable ways.
Please note, this section describes how to control how your email gateway generates outgoing bounces (based
on incoming mail). To control how your email gateway controls incoming bounces (based on outgoing mail)
use Bounce Verification (see Bounce Verification, on page 735).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
726
Configuring Routing and Delivery Features
Handling Undeliverable Email
Related Topics
• Handling Undeliverable Email, on page 727
• Creating a New Bounce Profile, on page 733
• Applying Bounce Profiles to Listeners, on page 733
Handling Undeliverable Email
The AsyncOS operating system classifies undeliverable email, or “bounced messages,” into the following
categories:
“Conversational” bounces:
The remote domain bounces the message during the initial SMTP conversation.
Soft bounces A message that is temporarily undeliverable. For example, a user’s mailbox may be
full. These messages can be retried at a later time. (e.g. An SMTP 4XX error code.)
Hard bounces A message that is permanently undeliverable. For example, the user no longer exists
for that domain. These messages will not be retried. (e.g. An SMTP 5XX error code.)
“Delayed” (or “Non-conversational”) bounces:
The remote domain accepts the message for delivery, only to bounce it at a later time.
Soft bounces A message that is temporarily undeliverable. For example, a user’s mailbox may be
full. These messages can be retried at a later time. (e.g. An SMTP 4XX error code.)
Hard bounces A message that is permanently undeliverable. For example, the user no longer exists
for that domain. These messages will not be retried. (e.g. An SMTP 5XX error code.)
You use the Bounce Profiles page on the Network menu in the GUI (or the bounceconfig command) to
configure how AsyncOS handles hard and soft conversational bounces for each listener you create. You create
bounce profiles and then apply profiles to each listener via the Network > Listeners page (or the
listenerconfig command). You can also assign bounce profiles to specific messages using message filters.
(See Using Message Filters to Enforce Email Policies, on page 139for more information.)
Related Topics
• Notes on Soft and Hard Bounces, on page 727
• Bounce Profile Parameters, on page 728
• Hard Bounces and the status Command, on page 731
• Conversational Bounces and SMTP Routes Message Filter actions, on page 731
• Example Bounce Profiles, on page 731
• Delivery Status Notification Format, on page 732
• Delay Warning Messages, on page 732
• Delay Warning Messages and Hard Bounces, on page 732
Notes on Soft and Hard Bounces
• For conversational soft bounces, a soft bounce event is defined as each time a recipient delivery temporarily
fails. A single recipient may incur several soft bounce events. You use the Bounce Profiles page or the
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
727
Configuring Routing and Delivery Features
Bounce Profile Parameters
bounceconfig command to configure parameters for each soft bounce event. (See Bounce Profile
Parameters, on page 728.)
• By default, the system generates a bounce message and sends it to the original sender for each hard
bounced recipient. (The message is sent to the address defined in the Envelope Sender address of the
message envelope. Envelope From is also commonly referred to as the Envelope Sender.) You can disable
this feature and instead rely on log files for information about hard bounces. (See the “Logging” chapter.)
• Soft bounces become hard bounces after the maximum time in queue or the maximum number of retries,
whichever comes first.
Bounce Profile Parameters
When configuring a bounce profile, the following parameters control how conversational bounces are handled
per message:
Table 59: Bounce Profile Parameters
Maximum number The number of times the system should try to reconnect to the recipient host to re-deliver
of retries the soft bounced message before treating it as a hard bounced message. The default is
100 retries.
Maximum number The amount of time the system should spend trying connect to the recipient host to
of seconds in queue re-deliver the soft bounced message before treating it as a hard bounced message. The
default is 259,200 seconds (72 hours).
Initial number of The amount of time the system should wait before the first attempt to re-deliver the
seconds to wait soft bounced message. The default is 60 seconds. Set the initial retry time to a high
before retrying a value to reduce the frequency of soft bounce attempts. Conversely, to increase the
message frequency, lower the value.
Maximum number The maximum amount of time the system should wait before trying to re-deliver the
of seconds to wait soft bounced message. The default is 3,600 seconds (1 hour). This is not the interval
before retrying a between each subsequent try; rather, it is another parameter that can be used to control
message the number of retries. The initial retry interval is limited on the high end by the
maximum retry interval. If the calculated retry interval period exceeds the maximum
retry interval then the maximum retry interval is used instead.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
728
Configuring Routing and Delivery Features
Bounce Profile Parameters
Send Hard Bounce Specify whether to send bounce message for hard bounce. If this option is enabled,
Messages you can choose the format of the bounce message. By default, bounce messages use
the DSN format (RFC 1894).
You can also send customized bounce messages based on the language of the original
message (subject and body). For example, you may want to send bounce messages in
Chinese for messages in Chinese and bounce messages in English for all the messages
in other languages.
Under Notification Template, click Add Row and choose the message language and
the template that you want to use.
Note Make sure that you do not delete the default entry (Message Language set
to Default). You can change the bounce notification template for the default
entry.
The language of a message is considered Default in the following scenarios:
• If the language of the message is different from the language selected in the other
Notification Template entries.
• If the language of the message is not supported by the email gateway.
• If the email gateway is unable to detect the language of the message.
• If the content (subject and body) in the message is less than 50 bytes.
While configuring the above example (send bounce messages in Chinese for messages
in Chinese and bounce messages in English for all the messages in other languages,)
the Notification Template table will look like this:
You can also choose whether to parse the DSN status field from the bounce response.
If you choose “Yes,” the email gateway searches the bounce response for a DSN status
code (RFC 3436) and uses the code in the Status field of the delivery status notification.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
729
Configuring Routing and Delivery Features
Bounce Profile Parameters
Send Delay Specify whether to send warning message for delayed delivery. If this option is enabled,
Warning Messages you can configure custom delay warning messages based on the language of the original
message (subject and body). For example, you may want to send delay warning
messages in Chinese for the messages in Chinese and delay warning messages in
English for all the messages in other languages.
Under Notification Template, click Add Row and choose the message language and
the template that you want to use.
Note Make sure that you do not delete the default entry (Message Language set
to Default). You can change the bounce notification template for the default
entry.
The language of a message is considered Default in the following scenarios:
• If the language of the message is different from the language selected in the other
Notification Template entries.
• If the language of the message is not supported by the email gateway.
• If the email gateway is unable to detect the language of the message.
• If the content (subject and body) in the message is less than 50 bytes.
While configuring the above example (send delay warning messages in Chinese for
the messages in Chinese and delay warning messages in English for all the messages
in other languages,) the Notification Template table will look like this:
You can also specify the minimum interval between messages as well as the maximum
number of retries to send.
Specify Recipient You can bounce messages to an alternate address rather than the default of the Envelope
for Bounces Sender address.
Use DomainKeys You can select a DomainKeys profile to use for signing bounce and delay messages.
signing for bounce For information on DomainKeys, see DomainKeys and DKIM Authentication, on page
and delay messages 601.
Global Settings
Configure these settings via the Edit Global Settings link on the Bounce Profiles page or by editing
the default bounce profile via the bounceconfig command in the CLI.
Initial number of The amount of time the system should wait before
seconds to wait
retrying a host that is unreachable. The default is 60 seconds.
before retrying an
unreachable host
Max interval The maximum amount of time the system should wait before retrying a host that is
allowed between unreachable. The default is 3,600 seconds (1 hour). When the delivery initially fails
retries to an due to the host being down, it will start with the minimum number of seconds retry
unreachable host value, and for each subsequent retry to the downed host, will increase the duration, up
to this maximum number of seconds value.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
730
Configuring Routing and Delivery Features
Hard Bounces and the status Command
Hard Bounces and the status Command
When hard bounce message generation is enabled, the following counters in the status and status detail
commands increment each time the email gateway generates a hard bounce message for delivery:
Counters: Reset Uptime Lifetime
Receiving
Messages Received 0 0 0
Recipients Received 0 0 0
Gen. Bounce Recipients 0 0 0
For more information, see the “Monitoring and Managing via the CLI” chapter. When hard bounce message
generation is disabled, none of these counters increments when a recipient hard bounces.
Note The Envelope Sender address of the message envelope is different than the From: in the message headers.
AsyncOS can be configured to send hard bounce messages to an email address different than the Envelope
Sender address.
Conversational Bounces and SMTP Routes Message Filter actions
Mappings for SMTP Routes and message filter actions are not applied to the routing of SMTP bounce messages
generated by the email gateway as a result of a conversational bounce. When an email gateway receives a
conversational bounce message, it generates an SMTP bounce message back to the Envelope Sender of the
original message. In this case, the email gateway is actually generating the message, so any SMTP Routes
that apply to an injected message for relaying do not apply.
Example Bounce Profiles
Consider these two examples using different bounce profile parameters:
Table 60: Example 1: Bounce Profile Parameters
Parameter Value
Max number of retries 2
Max number of seconds in queue 259,200 seconds (72 hours)
Initial number of seconds before retrying 60 seconds
Max number of seconds to wait before retrying 60 seconds
In Example 1, the first recipient delivery attempt is made at t=0, immediately after the message is injected
into the email gateway. With the default initial retry time of 60 seconds, the first retry attempt is made
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
731
Configuring Routing and Delivery Features
Delivery Status Notification Format
approximately one minute later at t=60. The retry interval is calculated and it is determined to use the maximum
retry interval of 60 seconds. Thus, the second retry attempt is made at approximately t=120. Immediately after
this retry attempt, the system generates a hard bounce message for that recipient because the maximum number
of retries is two.
Table 61: Example 2: Bounce Profile Parameters
Parameter Value
Max number of retries 100
Max number of seconds in queue 100 seconds
Initial number of seconds before retrying 60 seconds
Max number of seconds to wait before retrying 120 seconds
In Example 2, the first delivery attempt is made at t=0 and the first retry is made at t=60. The system hard
bounces the message immediately before the next delivery attempt (scheduled to occur at t=120) because it
has exceeded the maximum time in queue of 100 seconds.
Delivery Status Notification Format
Bounce messages generated by the system, by default, use the Delivery Status Notification (DSN) format for
both hard and soft bounces. DSN is a format defined by RFC 1894 (see http://www.faqs.org/rfcs/rfc1894.html
) that “defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail
gateway to report the result of an attempt to deliver a message to one or more recipients.” By default, the
delivery status notification includes an explanation of the delivery status and the original message if the
message size is less than 10k. If the message size is greater than 10k, the delivery status notification includes
the message headers only. If the message headers exceed 10k, the delivery status notification truncates the
headers. If you want include messages (or message headers) that are greater than 10k in the DSN, you can
use the max_bounce_copy parameter in the bounceconfig command (this parameter is only available from
the CLI).
Delay Warning Messages
Time in Queue Messages (delay notification messages) generated by the system also use the DSN format.
Change the default parameters by using the Bounce Profiles page on the Network menu (or the bounceconfig
command) to edit existing or create new bounce profiles and change the default values for:
• The minimum interval between sending delay warning messages.
• The maximum number of delay warning messages to send per recipient.
Delay Warning Messages and Hard Bounces
Note that it is possible to receive both a delay warning and a hard bounce for the same message simultaneously
, if you have set a very small durations for both the “Maximum Time in Queue” setting and the minimum
interval setting for “Send Delay Warning Messages.” Cisco Systems recommends using the default values
for these settings as a minimum if you choose to enable sending of delay warning messages.
Further, delay warning messages and bounce messages originated by the email gateway may be delayed by
as much as 15 minutes during processing.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
732
Configuring Routing and Delivery Features
Creating a New Bounce Profile
Creating a New Bounce Profile
In the following example, a bounce profile named bouncepr1 is created using the Bounce Profiles page. In
this profile, all hard bounced messages are sent to the alternate address [email protected] .
Delay warnings messages are enabled. One warning message will be sent per recipient, and the default value
of 4 hours (14400 seconds) between warning messages is accepted.
Related Topics
• Editing the Default Bounce Profile, on page 733
• Example of a Minimalist Bounce Profile, on page 733
Editing the Default Bounce Profile
You can edit any bounce profile by clicking its name in the Bounce Profiles listing. You can also edit the
default bounce profile. In this example, the default profile is edited to increase the maximum number of
seconds to wait before retrying unreachable hosts from 3600 (one hour) to 10800 (three hours):
Example of a Minimalist Bounce Profile
In the following example, a bounce profile named minimalist is created. In this profile, messages are not
retried when they bounce (zero maximum retries), and the maximum time to wait before retrying is specified.
Hard bounce messages are disabled, and soft bounce warnings are not sent.
Applying Bounce Profiles to Listeners
Once you have created a bounce profile, you can apply that profile to a listener using the Network > Listeners
page or the listenerconfig command.
In the following example, the bouncepr1 profile is applied to the OutgoingMail listener.
At this point, our Email Gateway configuration looks like this:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
733
Configuring Routing and Delivery Features
Controlling Email Delivery Using Destination Controls
Figure 50: Applying a Bounce Profile to a Private Listener
Controlling Email Delivery Using Destination Controls
Uncontrolled high-volume email delivery can overwhelm recipient domains. AsyncOS gives you full control
of message delivery by defining the number of connections your email gateway will open or the number of
messages your email gateway will send to each destination domain.
Using the Destination Controls feature (Mail Policies > Destination Controls in the GUI, or the destconfig
command in the CLI), you can control:
• Rate Limiting, on page 735
• TLS, on page 735
• Bounce Verification, on page 735
• Bounce Profile, on page 735
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
734
Configuring Routing and Delivery Features
Rate Limiting
Rate Limiting
• Concurrent Connections: number of simultaneous connections to remote hosts the email gateway will
attempt to open.
• Maximum Messages Per Connection: number of messages your email gateway will send to a destination
domain before the email gateway initiates a new connection.
• Recipients: number of recipients the email gateway will send to a given remote host in a given time
period.
• Limits: how to apply the limits you have specified on a per-destination and per MGA hostname basis.
TLS
• Whether TLS connections to remote hosts will be accepted, allowed, or required (see Controlling TLS,
on page 738).
• Whether to send an alert when TLS negotiation fails when delivering a message to a remote host that
requires a TLS connection. This is a global setting, not a per-domain setting.
• Assign a TLS certificate to use for all outbound TLS connections to remote hosts.
Bounce Verification
• Whether or not to perform address tagging via Bounce Verification (see Bounce Verification, on page
742).
Bounce Profile
• Which bounce profile should be used by the email gateway for a given remote host (the default bounce
profile is set via the Network > Bounce Profiles page).
You can also control the default settings for unspecified domains.
Related Topics
• Determining Which Interface is Used for Mail Delivery, on page 735
• Default Delivery Limits, on page 736
• Working with Destination Controls, on page 736
Determining Which Interface is Used for Mail Delivery
Unless you specify the output interface via the deliveryconfig command or via a message filter (
alt-src-host ), or through the use of a virtual gateway, the output interface is selected by the AsyncOS
routing table. Basically, selecting “auto” means to let AsyncOS decide.
In greater detail: local addresses are identified by applying the interface netmask to the interface IP address.
Both of these are set via the Network > Interfaces page or by the interfaceconfig command (or during
system setup). If the address space overlaps, the most specific netmask is used. If a destination is local, packets
are sent via the appropriate local interface.
If the destination is not local, packets are sent to the default router (set via the Network > Routing page or
with the setgateway command). The IP address of the default router is local. The output interface is determined
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
735
Configuring Routing and Delivery Features
Default Delivery Limits
by the rule for selecting the output interface for local addresses. For example, AsyncOS chooses the most
specific IP address and netmask that include the default router's IP address.
The routing table is configured via the Network > Routing page (or via the routeconfig command). A
matching entry in the routing table takes precedence over the default route. A more specific route take
precedence over a less specific route.
Default Delivery Limits
Each outbound destination domain has its own outbound queue. Therefore, each domain has a separate set of
concurrency limits as specified in the Destination Controls table. Further, each unique domain not listed
specifically in the Destination Controls table uses another set of the “Default” limits as set in the table.
Working with Destination Controls
Use the Mail Policies > Destination Controls page in the GUI or the destconfig command in the CLI to create,
edit, and delete Destination Control entries.
Related Topics
• Controlling the Version of Internet Protocol Addresses, on page 736
• Controlling the Number of Connections, Messages, and Recipients to a Domain, on page 736
• Controlling TLS, on page 738
• Controlling Bounce Verification Tagging, on page 738
• Controlling Bounces, on page 738
• Adding a New Destination Control Entry, on page 738
• Importing and Exporting Destination Control Configurations, on page 739
• Destination Controls and the CLI, on page 742
Controlling the Version of Internet Protocol Addresses
You can configure which version of Internet Protocol addresses to use for the connection to a domain. The
email gateway uses both Internet Protocol version 4 (IPv4) and Internet Protocol version (IPv6). You can
configure a listener on the email gateway to use one version of the protocol or both.
If the “Required” setting for either IPv4 or IPv6 is specified, the email gateway will negotiation a connection
to the domain using an address of the specified version. If the domain does not use that IP address version,
no email will be sent. If the “Preferred” setting for either IPv4 or IPv6 is specified, the email gateway will
first attempt to negotiation a connection to the domain using an address of the specified version then fall back
to the other if the first is not reachable.
Controlling the Number of Connections, Messages, and Recipients to a Domain
You may want to limit how your appliance will deliver email to avoid overwhelming remote hosts or your
own internal groupware servers with email from your email gateway.
For each domain, you can assign a maximum number of connections, outbound messages, and recipients that
will never be exceeded by the system in a given time period. This “good neighbor” table is defined through
the Destination Controls feature (Mail Policies > Destination Controls or the destconfig command —
previously the setgoodtable command). You can specify the domain name using the following syntax:
domain.com
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
736
Configuring Routing and Delivery Features
Controlling the Number of Connections, Messages, and Recipients to a Domain
or
.domain.com
This syntax enables AsyncOS to specify destination controls for sub-domains such as sample.server.domain.com
without entering each full subdomain address individually.
For connections, messages, and recipients, you set whether the limits you define are enforced for each Virtual
Gateway address, or for the entire system. (Virtual Gateway address limits control the number of concurrent
connections per IP interface. System-wide limits control the total number of connections the email gateway
will allow.)
You also set whether the limits you define are enforced for the entire domain.
Note The current system default is 500 connections per domain and 50 messages per connection.
These values are explained in the following table.
Table 62: Values in the Destination Controls Table
Field Description
Concurrent The maximum number of outbound connections that will be made by the email gateway
Connections to a given host. (Note that the domain can include your internal groupware hosts.)
Maximum The maximum number of messages allowed for a single outbound connection from the
Messages Per email gateway to a given host before initiating a new connection.
Connection
Recipients The maximum number of recipients allowed within the given period of time. “None”
denotes that there is no recipient limit for the given domain.
The minimum period of time — between 1 and 60 minutes — that the email gateway
will count the number of recipients. Specifying a time period of “0” disables the feature.
Note If you change the recipient limit, AsyncOS resets the counters for all messages
already in the queue. The email gateway delivers the messages based on the
new recipient limit.
Apply Limits Specifies whether the limit will be applied (enforces) to the entire domain.
This setting applies to connection, message, and recipient limits.
Specifies whether the limit will be applied system-wide or for each Virtual Gateway
address.
Note If you have configured groups of IP addresses, but you have not configured
virtual gateways, do not configure apply limits per each virtual gateway. This
setting is intended only for systems configured to use virtual gateways. For
information on configuring virtual gateways, see Configuring Mail Gateways
for all Hosted Domains Using Virtual Gateway™ Technology, on page 749.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
737
Configuring Routing and Delivery Features
Controlling TLS
Note If limits are applied per each Virtual Gateway address, you can still effectively implement system-wide limits
by setting the Virtual Gateway limit to the system-wide limit you want divided by the number of possible
virtual gateways. For example, if you have four Virtual Gateway addresses configured, and you do not want
to open more than 100 simultaneous connections to the domain yahoo.com , set the Virtual Gateway limit to
25 simultaneous connections.
The delivernow command, when acting on all domains, resets all counters tracked in the destconfig command.
Controlling TLS
You can also configure the TLS (Transport Layer Security) on a per-domain basis. If the “Required” setting
is specified, a TLS connection will be negotiated from the email gateway listener to MTA(s) for the domain.
If the negotiation fails, no email will be sent through the connection. For more information, see Enabling TLS
and Certificate Verification on Delivery, on page 684.
You can specify whether the email gateway sends an alert if the TLS negotiation fails when delivering messages
to a domain that requires a TLS connection. The alert message contains name of the destination domain for
the failed TLS negotiation. The email gateway sends the alert message to all recipients set to receive Warning
severity level alerts for System alert types. You can manage alert recipients via the System Administration >
Alerts page in the GUI (or via the alertconfig command in the CLI).
To enable TLS connection alerts, click Edit Global Settings on the Destination Controls page or destconfig
-> setup subcommand. This is a global setting, not a per-domain setting. For information on the messages
that the email gateway attempted to deliver, use the Monitor > Message Tracking page or the mail logs.
You must specify a certificate to use for all outgoing TLS connections. Use the Edit Global Settings on the
Destination Controls page or destconfig -> setup subcommand to specify the certificate. For information on
obtaining a certificate, see Working with Certificates, on page 676.
For more information on alerts, see the “System Administration” chapter.
Controlling Bounce Verification Tagging
You can specify whether or not mail sent is tagged for bounce verification. You can specify this for the default,
as well as specific destinations. Cisco suggests enabling bounce verification for the default, and then creating
new destinations for specific exclusions. See Bounce Verification, on page 742for more information.
Controlling Bounces
In addition to controlling the number of connections and recipients will deliver to a remote host, you can also
specify a bounce profile to be used for that domain. If specified, the bounce profile appears in the fifth column
of the destconfig command. If you do not specify a bounce profile, the default bounce profile will be used.
For more information, see Creating a New Bounce Profile, on page 733.
Adding a New Destination Control Entry
Procedure
Step 1 Click Add Destination:
Step 2 Configure the entry.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
738
Configuring Routing and Delivery Features
Importing and Exporting Destination Control Configurations
Step 3 Submit and commit your changes.
Importing and Exporting Destination Control Configurations
If you are managing multiple domains, you can create a single configuration file to define Destination Control
entries for all of the domains and import it onto the email gateway. The format of the configuration file is
similar to a Windows INI configuration file. The parameters for a domain are grouped in a section with the
domain name as the section name. For example, use the section name [example.com] to group the parameters
for the domain example.com. Any parameter that is not defined will be inherited from the default Destination
Control entry. You can define the parameters for the default Destination Control entry by including a [DEFAULT]
section in the configuration file.
Importing the configuration file overwrites all of email gateway's Destination Control entries, except for the
default entry unless the configuration file includes the [DEFAULT] section. All other existing Destination
Control entries will be deleted.
You can define any of the following parameters for a domain in the configuration file. All parameters are
required for the [DEFAULT] section except for the bounce_profile parameter:
Table 63: Destination Control Configuration File Parameters
Parameter Name Description
ip_sort_pref Specifies the Internet Protocol version for the domain.
Enter one of the following values:
• PREFER_V6 for “IPv6 Preferred”
• REQUIRE_v6 for “IPv6 Required”
• PREFER_V4 for “IPv4 Preferred”
• REQUIRE_v4 for “IPv4 Required”
max_host_concurrency The maximum number of outbound connections that will be made by the email
gateway to a given host.
If you define this parameter for a domain, the limit_type and limit_apply
parameters must also be defined.
max_messages_per_connection The maximum number of messages allowed for a single outbound connection from
the email gateway to a given host before initiating a new connection.
recipient_minutes The period of time — between 1 and 60 minutes — that the email gateway will
count the number of recipients. Leave undefined if no recipient limit should be
applied.
recipient_limit The maximum number of recipients allowed within the given period of time. Leave
undefined if no recipient limit should be applied.
If you define this parameter for a domain, the recipient_minutes , limit_type
, and limit_apply parameters must also be defined.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
739
Configuring Routing and Delivery Features
Importing and Exporting Destination Control Configurations
Parameter Name Description
limit_type Specifies whether the limit will be applied to the entire domain or to each mail
exchange IP address specified for that domain.
Enter one of the following values:
•0 (or host ) for the domain
•1 (or MXIP ) for the mail exchange IP address
limit_apply Specifies whether the limit will be applied system-wide or for each Virtual Gateway
address.
Enter one of the following values:
•0 (or system ) for system-wide
•1 (or VG ) for Virtual Gateway
bounce_validation Specifies whether to turn on bounce validation address tagging.
Enter one of the following values:
•0 (or off )
•1 (or on )
table_tls Specifies the TLS setting for the domain. See Enabling TLS and Certificate
Verification on Delivery, on page 684for more information.
Enter one of the following values:
• 0 (or off )
• 1 (or on ) for “Preferred”
• 2 (or required ) for “Required”
• 3 (or on_verify ) for “Preferred (Verify)”
• 4 (or require_verify ) for “Required (Verify)”
Strings are not case sensitive.
bounce_profile Name of the bounce profile to use. This cannot be used in the [DEFAULT] destination
control entry.
send_tls_req_alert Whether to send an alert if the required TLS connection fails.
Enter one of the following values:
•0 (or off )
•1 (or on )
This is a global setting and can only be used in the [DEFAULT] destination control
entry.
certificate Certificate used for outgoing TLS connections. This is a global setting and can only
be used in the [DEFAULT] destination control entry.
Note If you do not specify a certificate, AsyncOS assigns the demonstration
certificate, but using the demonstration certificate is not secure and not
recommended for general use.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
740
Configuring Routing and Delivery Features
Importing and Exporting Destination Control Configurations
The following example shows a configuration file for the domains example1.com and example2.com along
with the default Destination Control entry:
[DEFAULT]
ip_sort_pref = PREFER_V6
max_host_concurrency = 500
max_messages_per_connection = 50
recipient_minutes = 60
recipient_limit = 300
limit_type = host
limit_apply = VG
table_tls = off
bounce_validation = 0
send_tls_req_alert = 0
certificate = example.com
[example1.com]
ip_sort_pref = PREFER_V6
recipient_minutes = 60
recipient_limit = 100
table_tls = require_verify
limit_apply = VG
bounce_profile = tls_failed
limit_type = host
[example2.com]
table_tls = on
bounce_profile = tls_failed
The above example results in the following Destination Control entries for example1.com and example2.com:
example1.com
IP Address Preference: IPv6 Preferred
Maximum messages per connection: 50
Rate Limiting:
500 concurrent connections
100 recipients per 60 minutes
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
741
Configuring Routing and Delivery Features
Destination Controls and the CLI
Limits applied to entire domain, across all virtual gateways
TLS: Required (Verify)
Bounce Profile: tls_failed
example2.com
IP Address Preference: IPv6 Preferred
Maximum messages per connection: Default
Rate Limiting: Default
TLS: Preferred
Bounce Profile: tls_failed
Use the Import Table button on the Destination Controls page or the destconfig -> import command to
import a configuration file.You can also export your Destination Control entries to an INI file using the Export
Table button on the Destination Controls page or the destconfig -> export command. AsyncOS includes
the [Default] domain control entry in the exported INI file.
Destination Controls and the CLI
You can use the destconfig command in the CLI to configure Destination Control entries. This command is
discussed in the CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway.
Bounce Verification
A “bounce” message is a new message that is sent by a receiving MTA, using the Envelope Sender of the
original email as the new Envelope Recipient. This bounce is sent back to the Envelope Recipient (usually)
with a blank Envelope Sender (MAIL FROM: < >) when the original message is undeliverable (typically due
to a non-existent recipient address).
Increasingly, spammers are attacking email infrastructure via misdirected bounce attacks. These attacks consist
of a flood of bounce messages, sent by unknowing, legitimate mail servers. Basically, the process spammers
use is to send email via open relays and “zombie” networks to multiple, potentially invalid addresses (Envelope
Recipients) at various domains. In these messages, the Envelope Sender is forged so that the spam appears
to be coming from a legitimate domain (this is known as a “Joe job”).
In turn, for each incoming email with an invalid Envelope Recipient, the receiving mail servers generate a
new email — a bounce message — and send it along to the Envelope Sender at the innocent domain (the one
whose Envelope Sender address was forged). As a result, this target domain receives a flood of “misdirected”
bounces — potentially millions of messages. This type of distributed denial of service attack can bring down
email infrastructure and render it impossible for the target to send or receive legitimate email.
To combat these misdirected bounce attacks, AsyncOS includes Bounce Verification. When enabled, Bounce
Verification tags the Envelope Sender address for messages sent via your email gateway. The Envelope
Recipient for any bounce message received by the email gateway is then checked for the presence of this tag.
Legitimate bounces (which should contain this tag) are untagged and delivered. Bounce messages that do not
contain the tag can be handled separately.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
742
Configuring Routing and Delivery Features
Overview: Tagging and Bounce Verification
Note that you can use Bounce Verification to manage incoming bounce messages based on your outgoing
mail. To control how your email gateway generates outgoing bounces (based on incoming mail), see Directing
Bounced Email, on page 726.
Related Topics
• Overview: Tagging and Bounce Verification, on page 743
• Preventing a Bounced Message Storm Using Bounce Verification, on page 744
• Accepting Legitimate Untagged Bounced Messages, on page 744
Overview: Tagging and Bounce Verification
When sending email with bounce verification enabled, your email gateway will rewrite the Envelope Sender
address in the message. For example, MAIL FROM: [email protected] becomes MAIL FROM:
[email protected] . The 123... string in the example is the “bounce verification tag”
that gets added to the Envelope Sender as it is sent by your email gateway. The tag is generated using a key
defined in the Bounce Verification settings (see Bounce Verification Address Tagging Keys, on page 744for
more information about specifying a key). If this message bounces, the Envelope Recipient address in the
bounce will typically include this bounce verification tag.
You can enable or disable bounce verification tagging system-wide as a default. You can also enable or disable
bounce verification tagging for specific domains. In most situations, you would enable it by default, and then
list specific domains to exclude in the Destination Controls table (see Working with Destination Controls, on
page 736).
If a message already contains a tagged address, AsyncOS does not add another tag (in the case of an email
gateway delivering a bounce message to an email gateway inside the DMZ).
Related Topics
• Handling Incoming Bounce Messages, on page 743
• Bounce Verification Address Tagging Keys, on page 744
Handling Incoming Bounce Messages
Bounces that include a valid tag are delivered. The tag is removed and the Envelope Recipient is restored.
This occurs immediately after the Domain Map step in the email pipeline. You can define how your email
gateways handle untagged or invalidly tagged bounces — reject them or add a custom header. See Configuring
Bounce Verification Settings, on page 745 for more information.
If the bounce verification tag is not present, or if the key used to generate the tag has changed, or if the message
is more than seven days old, the message is treated as per the settings defined for Bounce Verification.
For example, the following mail log shows a bounced message rejected by the email gateway:
Fri Jul 21 16:02:19 2006 Info: Start MID 26603 ICID 125192
Fri Jul 21 16:02:19 2006 Info: MID 26603 ICID 125192 From: <>
Fri Jul 21 16:02:40 2006 Info: MID 26603 ICID 125192 invalid bounce, rcpt address
<[email protected]> rejected by bounce verification.
Fri Jul 21 16:03:51 2006 Info: Message aborted MID 26603 Receiving aborted by sender
Fri Jul 21 16:03:51 2006 Info: Message finished MID 26603 aborted
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
743
Configuring Routing and Delivery Features
Bounce Verification Address Tagging Keys
Note When delivering non-bounce mail to your own internal mail server (Exchange, etc.), you should disable
Bounce Verification tagging for that internal domain.
AsyncOS considers bounces as mail with a null Mail From address (<>). For non-bounce messages that might
contain a tagged Envelope Recipient, AsyncOS applies a more lenient policy. In such cases, AsyncOS ignores
the seven-day key expiration and tries to find a match with older keys as well.
Bounce Verification Address Tagging Keys
The tagging key is a text string your email gateway uses when generating the bounce verification tag. Ideally,
you would use the same key across all of your email gateways so that all mail leaving your domain is tagged
consistently. That way, if one email gateway tags the Envelope Sender on an outgoing message an incoming
bounce will be verified and delivered even if the bounce is received by a different email gateway.
There is a seven day grace period for tags. For example, you may choose to change your tagging key multiple
times within a seven-day period. In such a case, your email gateway will try to verify tagged messages using
all previous keys that are less than seven days old.
Accepting Legitimate Untagged Bounced Messages
AsyncOS also includes a HAT setting related to Bounce Verification for considering whether untagged bounces
are valid. The default setting is “No,” which means that untagged bounces are considered invalid and the
email gateway either rejects the message or applies a customer header, depending on the action selected on
the Mail Policies > Bounce Verification page. If you select “Yes,” the email gateway considers untagged
bounces to be valid and accepts them. This may be used in the following scenario:
Suppose you have a user that wants to send email to a mailing list. However, the mailing list accepts messages
only from a fixed set of Envelope Senders. In such a case, tagged messages from your user will not be accepted
(as the tag changes regularly).
Procedure
Step 1 Add the domain to which the user is trying to send mail to the Destination Controls table and disable tagging
for that domain. At this point, the user can send mail without problems.
Step 2 However, to properly support receiving bounces from that domain (since they will not be tagged) you can
create a sender group for that domain and enable the Consider Untagged Bounces to be Valid parameter in
an “Accept” mail flow policy.
Preventing a Bounced Message Storm Using Bounce Verification
Procedure
Step 1 Enter a tagging key. For more information, see Configuring Bounce Verification Address Tagging Keys, on
page 745.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
744
Configuring Routing and Delivery Features
Configuring Bounce Verification Address Tagging Keys
Step 2 Edit the bounce verification settings. For more information, see Configuring Bounce Verification Settings,
on page 745.
Step 3 Enable bounce verification via Destination Controls. For more information, see Working with Destination
Controls, on page 736.
What to do next
Related Topics
• Configuring Bounce Verification Address Tagging Keys, on page 745
• Configuring Bounce Verification Settings, on page 745
• Configuring Bounce Verification Using the CLI, on page 746
• Bounce Verification and Cluster Configuration, on page 746
Configuring Bounce Verification Address Tagging Keys
The Bounce Verification Address Tagging Keys listing shows your current key and any unpurged keys you
have used in the past. To add a new key:
Procedure
Step 1 On the Mail Policies > Bounce Verification page, click New Key.
Step 2 Enter a text string and click Submit.
Step 3 Commit your changes.
What to do next
Related Topics
• Purging Keys, on page 745
Purging Keys
You can purge your old address tagging keys by selecting a rule for purging from the pull-down menu and
clicking Purge.
Configuring Bounce Verification Settings
The bounce verification settings determine which action to take when an invalid bounce is received.
Procedure
Step 1 Choose Mail Policies > Bounce Verification.
Step 2 Click Edit Settings.
Step 3 Select whether to reject invalid bounces, or to add a custom header to the message. If you want to add a header,
enter the header name and value.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
745
Configuring Routing and Delivery Features
Configuring Bounce Verification Using the CLI
Step 4 Optionally, enable smart exceptions. This setting allows incoming mail messages, and bounce messages
generated by internal mail servers, to be automatically exempted from bounce verification processing (even
when a single listener is used for both incoming and outgoing mail).
Step 5 Submit and commit your changes.
Configuring Bounce Verification Using the CLI
You can use the bvconfig and destconfig commands in the CLI to configure bounce verification. These
commands are discussed in the CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway .
Bounce Verification and Cluster Configuration
Bounce verification works in a cluster configuration as long as both email gateways use the same "bounce
key." When you use the same key, either systems should be able to accept a legitimate bounce back. The
modified header tag/key is not specific to each email gateway.
Set Email Delivery Parameters
The deliveryconfig command sets parameters to be used when delivering email from the email gateway.
The email gateway accepts email using multiple mail protocols: SMTP and QMQP. However, all outgoing
email is delivered using SMTP, which is why the deliveryconfig command does not require that the protocol
be specified.
Note Several of the features or commands described in this section will affect, or be affected by routing precedence.
Please see the “Assigning Network and IP Addresses” appendix for more information.
Related Topics
• Default Delivery IP Interface, on page 746
• Possible Delivery Feature, on page 747
• Default Maximum Concurrency, on page 747
• deliveryconfig Example, on page 747
Default Delivery IP Interface
By default, the system uses an IP interface or IP interface group for email delivery. Any currently configured
IP interface or IP interface group can be set. If no specific interface is identified, AsyncOS will use the
hostname associated with the default delivery interface in the SMTP HELO command when communicating
with recipient hosts. To configure IP interfaces, use the interfaceconfig command.
These are the rules for using Auto selection of email delivery interfaces:
• If the remote email server is on the same subnet as one of the configured interfaces, then traffic will go
out on the matching interface.
• When set to auto-select, static routes you have configured using routeconfig take effect.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
746
Configuring Routing and Delivery Features
Possible Delivery Feature
• Otherwise, the interface that is on the same subnet as the default gateway will be used. If all of the IP
addresses have an equivalent route to the destination, then the system uses the most efficient interface
available.
Possible Delivery Feature
Caution If you enable this feature, message delivery will not be reliable and may lead to loss of messages. Also, your
email gateway will not be RFC 5321-compliant. For more information, see http://tools.ietf.org/html/
rfc5321#section-6.1..
When the Possible Delivery feature is enabled, AsyncOS treats any message that times-out after the body of
the message is delivered, but before recipient host acknowledges receipt of the message, as a “possible
delivery.” This functionality prevents recipients from receiving multiple copies of a message if continuous
errors at their recipient host prevent acknowledgment of receipt. AsyncOS logs this recipient as a possible
delivery in the mail logs and counts the message as completed.
Default Maximum Concurrency
You also specify the default maximum number of concurrent connections the email gateway makes for
outbound message delivery. (The system-wide default is 10,000 connections to separate domains.) The limit
is monitored in conjunction with the per-listener maximum outbound message delivery concurrency (the
default per listener is 600 connections for private listeners and 1000 connections for public listeners). Setting
the value lower than the default prevents the gateway from dominating weaker networks. For example, certain
firewalls do not support large numbers of connections, and this could induce Denial of Service (DoS) warnings
in these environments.
deliveryconfig Example
In the following example, the deliveryconfig command is used to set the default interface to “Auto” with
“Possible Delivery” enabled. The system-wide maximum outbound message delivery is set to 9000 connections.
mail3.example.com> deliveryconfig
Choose the operation you want to perform:
- SETUP - Configure mail delivery.
[]> setup
Choose the default interface to deliver mail.
1. Auto
2. PublicNet2 (192.168.3.1/24: mail4.example.com)
3. Management (192.168.42.42/24: mail3.example.com)
4. PrivateNet (192.168.1.1/24: mail3.example.com)
5. PublicNet (192.168.2.1/24: mail3.example.com)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
747
Configuring Routing and Delivery Features
deliveryconfig Example
[1]> 1
Enable "Possible Delivery"? [Y]> y
Please enter the default system wide maximum outbound message delivery
concurrency
[10000]> 9000
mail3.example.com>
Our Email Gateway configuration now looks like this:
Figure 51: Setting Destination and Delivery Parameters
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
748
Configuring Routing and Delivery Features
Configuring Mail Gateways for all Hosted Domains Using Virtual Gateway™ Technology
ConfiguringMailGatewaysforallHostedDomainsUsingVirtual
Gateway™ Technology
This section describes Cisco Virtual Gateway™ technology and its benefits, how to set up a Virtual Gateway
address, and how to monitor and manage Virtual Gateway addresses.
The Cisco Virtual Gateway technology allows you to configure enterprise mail gateways for all domains you
host — with distinct IP addresses, hostname and domains — and create separate corporate email policy
enforcement and anti-spam strategies for those domains, while hosted within the same physical email gateway.
The number of Virtual Gateway addresses available on all the email gateway models is 255.
Related Topics
• Overview, on page 749
• Setting Up Virtual Gateway Addresses, on page 749
• Monitoring the Virtual Gateway Addresses, on page 756
• Managing Delivery Connections per Virtual Gateway Address, on page 757
Overview
Cisco has developed a unique Virtual Gateway technology designed to help ensure that corporations can
reliably communicate with their customers via email. Virtual Gateway technology enables users to separate
the email gateway into multiple Virtual Gateway addresses from which to send and receive email. Each Virtual
Gateway address is given a distinct IP address, hostname and domain, and email queue.
Assigning a distinct IP address and hostname to each Virtual Gateway address ensures that email delivered
through the gateway will be properly identified by the recipient host and prevents critical email from being
blocked as spam. The email gateway has the intelligence to give the correct hostname in the SMTP HELO
command for each of the Virtual Gateway addresses. This ensures that if a receiving Internet Service Provider
(ISP) performs a reverse DNS look-up, the email gateway will match the IP address of the email sent through
that Virtual Gateway address. This feature is extremely valuable, because many ISPs use a reverse DNS
lookup to detect unsolicited email. If the IP address in the reverse DNS look-up does not match the IP address
of the sending host, the ISP may assume the sender is illegitimate and will frequently discard the email. The
Cisco Virtual Gateway technology ensures that reverse DNS look-ups will always match the sending IP
address, preventing messages from being blocked accidentally.
Messages in each Virtual Gateway address are also assigned to a separate message queue. If a certain recipient
host is blocking email from one Virtual Gateway address, messages intended for that host will remain in the
queue and eventually timeout. But messages intended for the same domain in a different Virtual Gateway
queue that is not being blocked will be delivered normally. While these queues are treated separately for
delivery purposes, the system administration, logging and reporting capability still provide a holistic view
into all Virtual Gateway queues as if they were one.
Setting Up Virtual Gateway Addresses
Before setting up the Cisco Virtual Gateway addresses, you must allocate a set of IP addresses that will be
used to send email from. (For more information, see the “Assigning Network and IP Addresses” appendix.)
You should also ensure proper configuration of your DNS servers so that the IP address resolves to a valid
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
749
Configuring Routing and Delivery Features
Creating New IP Interfaces for Use with Virtual Gateways
hostname. Proper configuration of DNS servers ensures that if the recipient host performs a reverse DNS
lookup, it will resolve to valid IP/hostname pairs.
Related Topics
• Creating New IP Interfaces for Use with Virtual Gateways, on page 750
• Mapping Messages to IP Interfaces for Delivery, on page 752
• Importing an altsrchost File, on page 753
• altsrchost Limits, on page 754
• Example Text File with Valid Mappings for the altsrchost Command, on page 754
• Adding an altsrchost Mapping through the CLI, on page 754
Creating New IP Interfaces for Use with Virtual Gateways
After the IP addresses and hostnames have been established, the first step in configuring the Virtual Gateway
addresses is to create new IP interfaces with the IP/hostname pairs using the Network > IP Interfaces page in
the GUI or the interfaceconfig command in the CLI.
Once the IP interfaces have been configured, you have the option to combine multiple IP interfaces into
interface groups; these groups can then be assigned to specific Virtual Gateways addresses which the system
cycles through in a “round robin” fashion when delivering email.
After creating the required IP interfaces, you have two options for setting up the Virtual Gateway addresses
and defining which email campaign will be sent from each IP interface or interface group:
• You can use the altsrchost command to map email from specific sender IP addresses or Envelope Sender
address information to a host IP interface (Virtual Gateway address) or interface group for delivery.
• Using message filters, you can set up specific filters to deliver flagged messages using a specific host IP
interface (Virtual Gateway address) or interface group. See Alter Source Host (Virtual Gateway address)
Action, on page 215. (This method is more flexible and powerful than the one above.)
For more information about creating IP interfaces, see the “Accessing the Email Gateway” appendix.
So far, we have been using an Email Gateway configuration with the following interfaces defined as shown
in the following figure.
Figure 52: Example Public and Private interfaces
In the following example, the IP Interfaces page confirms that these two interfaces (PrivateNet and PublicNet)
have been configured, in addition to the Management interface.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
750
Configuring Routing and Delivery Features
Creating New IP Interfaces for Use with Virtual Gateways
Figure 53: IP Interface Page
Next, the Add IP Interface page is used to create a new interface named PublicNet2 on the Data2 Ethernet
interface. The IP address of 192.168.2.2 is used, and the hostname of mail4.example.com is specified. The
services for FTP (port 21) and SSH (port 22) are then enabled.
Figure 54: Add IP Interface Page
Our Email Gateway configuration now looks like this:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
751
Configuring Routing and Delivery Features
Mapping Messages to IP Interfaces for Delivery
Figure 55: Adding Another Public Interface
Using Virtual Gateway addresses, a configuration like the one shown in the following figure is also possible.
Figure 56: Four Virtual Gateway Addresses on One Ethernet Interface
Note that four separate IP interfaces can be used to deliver mail, where only one public listener is configured
to accept messages from the Internet.
Mapping Messages to IP Interfaces for Delivery
The altsrchost command provides the simplest and most straightforward method to segment each email
gateway into multiple IP interfaces (Virtual Gateway addresses) from which to deliver email. However, users
requiring more power and flexibility in mapping messages to particular Virtual Gateways should investigate
the use of message filters. See Using Message Filters to Enforce Email Policies, on page 139for more
information.
The altsrchost command allows you to control which IP interface or interface group to use during email
delivery based on one of the following:
• the sender’s IP address
• the Envelope Sender address
To specify which IP interface or interface group the system will deliver email from, you create mapping keys
that pair either the sender’s IP address or the Envelope Sender address to an IP interface or interface group
(specified by interface name or group name).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
752
Configuring Routing and Delivery Features
Importing an altsrchost File
AsyncOS will compare both the IP address and Envelope Sender address to the mapping keys. If either the
IP address or Envelope Sender address matches one of the keys, the corresponding IP interface is used for
the outbound delivery. If there is no match, the default outbound interface will be used.
The system can match any of the following keys and take preference in the following order:
Sender’s IP address The IP address of the sender must match exactly.
Example: 192.168.1.5
Fully-formed Envelope The Envelope Sender must match the entire address exactly.
Sender
Example: [email protected]
Username The system will match username syntax against the Envelope Sender address
up to the @ sign. The @ sign must be included. Example: username@
Domain The system will match domain name syntax against the Envelope Sender address
starting with the @ sign. The @ sign must be included. Example: @example.com
Note A listener checks the information in the altsrchost table and directs the email to a particular interface after
checking the masquerading information and before message filters are checked.
Use these subcommands within the altsrchost command to create mappings in the Virtual Gateways via
the CLI:
Syntax Description
new Create a new mapping manually.
print Display the current list of mappings.
delete Remove one of the mappings from the table.
Importing an altsrchost File
Like the HAT, the RAT, smtproutes , and masquerading and alias tables, you can modify altsrchost entries
by exporting and importing a file.
Procedure
Step 1 Use the export subcommand of the altsrchost command to export the existing entries to a file (whose name
you specify).
Step 2 Outside of the CLI, get the file. (See FTP, SSH, and SCP Access, on page 1297 for more information.)
Step 3 With a text editor, create new entries in the file. The order that rules appear in the altsrchost table is important.
Step 4 Save the file and place it in the “altsrchost” directory for the interface so that it can be imported. (See FTP,
SSH, and SCP Access, on page 1297for more information.)
Step 5 Use the import subcommand of altsrchost to import the edited file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
753
Configuring Routing and Delivery Features
altsrchost Limits
altsrchost Limits
You can define up to 1,000 altsrchost entries.
Example Text File with Valid Mappings for the altsrchost Command
# Comments to describe the file
@example.com DemoInterface
paul@ PublicInterface
joe@ PublicInterface
192.168.1.5, DemoInterface
[email protected] PublicNet
The import and export subcommands operate on a line-by-line basis and map either the sender IP address
or the Envelope Sender address line to the interface name. The key must be the first block of non-space
characters followed by the interface name in the second block of non-space characters, separated by a comma
( , ) or space ( ). Comment lines start with a number sign ( # ) and will be ignored.
Adding an altsrchost Mapping through the CLI
In the following example, the altsrchost table is printed to show that there are no existing mappings. Two
entries are then created:
• Mail from the groupware server host named @exchange.example.com is mapped to the PublicNet interface.
• Mail from the sender IP address of 192.168.35.35 (for example, the marketing campaign messaging
system) is mapped to the PublicNe2t interface.
Finally, the altsrchost mappings are printed to confirm and the changes are committed.
mail3.example.com> altsrchost
There are currently no mappings configured.
Choose the operation you want to perform:
- NEW - Create a new mapping.
- IMPORT - Load new mappings from a file.
[]> new
Enter the Envelope From address or client IP address for which you want to set up a
Virtual Gateway mapping. Partial addresses such as "@example.com" or "user@" are
allowed.
[]> @exchange.example.com
Which interface do you want to send messages for @exchange.example.com from?
1. PublicNet2 (192.168.2.2/24: mail4.example.com)
2. Management (192.168.42.42/24: mail3.example.com)
3. PrivateNet (192.168.1.1/24: mail3.example.com)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
754
Configuring Routing and Delivery Features
Adding an altsrchost Mapping through the CLI
4. PublicNet (192.168.2.1/24: mail4.example.com)
[1]> 4
Mapping for @exchange.example.com on interface PublicNet created.
Choose the operation you want to perform:
- NEW - Create a new mapping.
- EDIT - Modify a mapping.
- DELETE - Remove a mapping.
- IMPORT - Load new mappings from a file.
- EXPORT - Export all mappings to a file.
- PRINT - Display all mappings.
- CLEAR - Remove all mappings.
[]> new
Enter the Envelope From address or client IP address for which you want to set up a
Virtual Gateway mapping. Partial addresses such as "@example.com" or "user@" are
allowed.
[]> 192.168.35.35
Which interface do you want to send messages for 192.168.35.35 from?
1. PublicNet2 (192.168.2.2/24: mail4.example.com)
2. Management (192.168.42.42/24: mail3.example.com)
3. PrivateNet (192.168.1.1/24: mail3.example.com)
4. PublicNet (192.168.2.1/24: mail4.example.com)
[1]> 1
Mapping for 192.168.35.35 on interface PublicNet2 created.
Choose the operation you want to perform:
- NEW - Create a new mapping.
- EDIT - Modify a mapping.
- DELETE - Remove a mapping.
- IMPORT - Load new mappings from a file.
- EXPORT - Export all mappings to a file.
- PRINT - Display all mappings.
- CLEAR - Remove all mappings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
755
Configuring Routing and Delivery Features
Monitoring the Virtual Gateway Addresses
1. 192.168.35.35 -> PublicNet2
2. @exchange.example.com -> PublicNet
Choose the operation you want to perform:
- NEW - Create a new mapping.
- EDIT - Modify a mapping.
- DELETE - Remove a mapping.
- IMPORT - Load new mappings from a file.
- EXPORT - Export all mappings to a file.
- PRINT - Display all mappings.
- CLEAR - Remove all mappings.
[]>
mail3.example.com> commit
Please enter some comments describing your changes:
[]> Added 2 altsrchost mappings
Do you want to save the current configuration for rollback? [Y]> n
Changes committed: Fri May 23 11:42:12 2014 GMT
An illustration of the configuration change in this example is shown in the following figure:
Figure 57: Example: Selecting an IP Interface or Interface Group to Use
Monitoring the Virtual Gateway Addresses
While each Virtual Gateway address has its own email queue for delivery purposes, the system administration,
logging, and reporting capabilities still provide a holistic view into all Virtual Gateway queues as if they were
one. To monitor the recipient host status for each Virtual Gateway queue, use the hoststatus and hostrate
command. See the “Reading the Available Components of Monitoring” section in the “Managing and
Monitoring Using the CLI” chapter.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
756
Configuring Routing and Delivery Features
Managing Delivery Connections per Virtual Gateway Address
The hoststatus command returns monitoring information about email operations relating to a specific recipient
host.
If you are using Virtual Gateway technology, information about each Virtual Gateway address is also displayed.
The command requires you to input the domain of the host information to be returned. DNS information stored
in the AsyncOS cache and the last error returned from the recipient host is also given. Data returned is
cumulative since the last resetcounters command.
The statistics returned are grouped into two categories: counters and gauges. In addition, other data returned
include: last activity, MX records, and last 5XX error.
Managing Delivery Connections per Virtual Gateway Address
Certain system parameters require settings at the system and Virtual Gateway address levels.
For example, some recipient ISPs limit the number of connections they allow for each client host. Therefore,
it is important to manage relationships with the ISPs, especially when email is being delivered over multiple
Virtual Gateway addresses.
See Controlling Email Delivery Using Destination Controls, on page 734for information about the destconfig
command and how Virtual Gateway addresses are affected.
When you create a “group,” of Virtual Gateway addresses, the good neighbor table settings for Virtual Gateway
are applied to the group, even if the group consists of 254 IP addresses.
For example, suppose you have created group of 254 outbound IP addresses set up as a group to cycle through
in a “round-robin” fashion, and suppose the good neighbor table for small-isp.com is 100 simultaneous
connections for the system and 10 connections for Virtual Gateway addresses. This configuration will never
open more than 10 connections total for all 254 IP addresses in that group; the group is treated as a single
Virtual Gateway address.
Using Global Unsubscribe
To ensure that specific recipients, recipient domains, or IP addresses never receive messages from the email
gateway, use the AsyncOS Global Unsubscribe feature. The unsubscribe command allows you to add and
delete addresses to a global unsubscribe list, as well as enable and disable the feature. AsyncOS checks all
recipient addresses against a list of “globally unsubscribed” users, domains, email addresses, and IP addresses.
If a recipient matches an address in the list, the recipient is either dropped or hard bounced, and the Global
Unsubscribe (GUS) counter is incremented. (Log files will note whether a matching recipient was dropped
or hard bounced.) The GUS check occurs immediately before an attempt to send email to a recipient, thus
inspecting all messages sent by the system.
Note Global Unsubscribe is not intended to replace the removal of names and general maintenance of mailing lists.
The feature is intended to act as a fail-safe mechanism to ensure email does not get delivered to inappropriate
entities.
Global Unsubscribe has a maximum limit of 10,000 addresses. Global Unsubscribe addresses can be in one
of four forms:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
757
Configuring Routing and Delivery Features
Adding a Global Unsubscribe Address Using The CLI
Table 64: Global Unsubscribe Syntax
[email protected] Fully-formed email address
This syntax is used to block a specific recipient at a
specific domain.
username@ Username
The username syntax will block all recipients with
the specified username at all domains. The syntax is
the username followed by an at sign ( @ ).
@example.com Domain
The domain syntax is used to block all recipients
destined for a particular domain. The syntax is the
specific domain, preceded by an at sign ( @ ).
@.example.com Partial Domain
The partial domain syntax is used to block all
recipients destined for a particular domain and all its
subdomains.
10.1.28.12 IP address
The IP address syntax is used to block all recipients
destined for a particular IP address. This syntax can
be useful if a single IP address is hosting multiple
domains. The syntax consists of a common dotted
octet IP address.
Related Topics
• Adding a Global Unsubscribe Address Using The CLI, on page 758
• Exporting and Importing a Global Unsubscribe File, on page 760
Adding a Global Unsubscribe Address Using The CLI
In this example, the address [email protected] is added to the Global Unsubscribe list, and the feature is
configured to hard bounce messages. Messages sent to this address will be bounced; the email gateway will
bounce the message immediately prior to delivery.
mail3.example.com> unsubscribe
Global Unsubscribe is enabled. Action: drop.
Choose the operation you want to perform:
- NEW - Create a new entry.
- IMPORT - Import entries from a file.
- SETUP - Configure general settings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
758
Configuring Routing and Delivery Features
Adding a Global Unsubscribe Address Using The CLI
[]> new
Enter the unsubscribe key to add. Partial addresses such as
"@example.com" or "user@" are allowed, as are IP addresses. Partial hostnames such as
"@.example.com" are allowed.
Email Address '[email protected]' added.
Global Unsubscribe is enabled.
Choose the operation you want to perform:
- NEW - Create a new entry.
- DELETE - Remove an entry.
- PRINT - Display all entries.
- IMPORT - Import entries from a file.
- EXPORT - Export all entries to a file.
- SETUP - Configure general settings.
- CLEAR - Remove all entries.
[]> setup
Do you want to enable the Global Unsubscribe feature? [Y]> y
Would you like matching messages to be dropped or bounced?
1. Drop
2. Bounce
[1]> 2
Global Unsubscribe is enabled. Action: bounce.
Choose the operation you want to perform:
- NEW - Create a new entry.
- DELETE - Remove an entry.
- PRINT - Display all entries.
- IMPORT - Import entries from a file.
- EXPORT - Export all entries to a file.
- SETUP - Configure general settings.
- CLEAR - Remove all entries.
[]>
mail3.example.com> commit
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
759
Configuring Routing and Delivery Features
Exporting and Importing a Global Unsubscribe File
Please enter some comments describing your changes:
[]> Added username “[email protected]” to global unsubscribe
Do you want to save the current configuration for rollback? [Y]> n
Changes committed: Fri May 23 11:42:12 2014 GMT
Exporting and Importing a Global Unsubscribe File
Like the HAT, the RAT, smtproutes , static masquerading tables, alias tables, domain map tables, and altsrchost
entries, you can modify global unsubscribe entries by exporting and importing a file.
Procedure
Step 1 Use the export subcommand of the unsubscribe command to export the existing entries to a file (whose name
you specify).
Step 2 Outside of the CLI, get the file. (See FTP, SSH, and SCP Access, on page 1297 for more information.)
Step 3 With a text editor, create new entries in the file.
Separate entries in the file by new lines. Return representations from all standard operating systems are
acceptable (<CR>, <LF>, or <CR><LF>). Comment lines start with a number sign ( # ) and are ignored. For
example, the following file excludes a single recipient email address ( [email protected] ), all recipients at
a particular domain ( @testdomain.com ), all users with the same name at multiple domains ( testuser@ ),
and any recipients at a specific IP address ( 11.12.13.14 ).
# this is an example of the global_unsubscribe.txt file
[email protected]
@testdomain.com
testuser@
11.12.13.14
Step 4 Save the file and place it in the configuration directory for the interface so that it can be imported. (See FTP,
SSH, and SCP Access, on page 1297 for more information.)
Step 5 Use the import subcommand of unsubscribe to import the edited file.
Review: Email Pipeline
The following tables provide an overview of how email is routed through the system, from reception to routing
to deliver. Each feature is processed in order (from top to bottom) and is briefly summarized. Shaded areas
in Table - Email Pipeline for the Cisco Secure Email Gateway: Routing and Delivery Features represent
processing that occurs in the Work Queue.
You can test most of the configurations of features in this pipeline using the trace command. For more
information, see “Debugging Mail Flow Using Test Messages: Trace” in the Troubleshooting chapter.
Note For outgoing mail, Data Loss Prevention scanning takes place after the Outbreak Filters stage.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
760
Configuring Routing and Delivery Features
Review: Email Pipeline
Table 65: Email Pipeline for the Cisco Secure Email Gateway: Receiving Email Features
Feature Description
Host Access Table (HAT) ACCEPT, REJECT, RELAY, or TCPREFUSE connections
Host DNS Sender Maximum outbound connections
Verification
Maximum concurrent inbound connections per IP address
Sender Groups
Maximum message size and messages per connection
Envelope Sender
Maximum recipients per message and per hour
Verification
TCP listen queue size
Sender Verification
Exception Table TLS: no/preferred/required
Mail Flow Policies SMTP AUTH: no/preferred/required
Drop email with malformed FROM headers
Always accept or reject mail from entries in the Sender Verification Exception Table.
SenderBase on/off (IP profiling/flow control)
Received Header Adds a received header to accepted email: on/off.
Default Domain Adds default domain for “bare” user addresses.
Bounce Verification Used to verify incoming bounce messages as legitimate.
Domain Map Rewrites the Envelope Recipient for each recipient in a message that matches a domain in the domain
map table.
Recipient Access Table (Public listeners only) ACCEPT or REJECT recipients in RCPT TO plus Custom SMTP Response.
(RAT) Allow special recipients to bypass throttling.
Alias tables Rewrites the Envelope Recipient. (Configured system-wide. aliasconfig is not a subcommand of
listenerconfig .)
LDAP Recipient LDAP validation for recipient acceptance occurs within the SMTP conversation. If the recipient is not
Acceptance found in the LDAP directory, the message is dropped or bounced. LDAP validation can be configured
to occur within the work queue instead.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
761
Configuring Routing and Delivery Features
Review: Email Pipeline
Table 66: Email Pipeline for the Email Security Appliance: Routing and Delivery Features
Work LDAP Recipient LDAP validation for recipient acceptance occurs within the
Queue Acceptance work queue. If the recipient is not found in the LDAP directory,
the message is dropped or bounced. LDAP validation can be
configured to occur within the SMTP conversation instead.
Masquerading Masquerading occurs in the work queue; it rewrites the
Envelope Sender, To:, From:, and/or CC: headers, from a static
or LDAP
table or via an LDAP query.
Masquerading
LDAP Routing LDAP queries are performed for message routing or address
rewriting. Group LDAP queries work in conjunction with
message filter rules mail-from-group and rcpt-to-group .
Message Filters* Message Filters are applied prior to message “splintering.” *
Can send messages to quarantines.
Anti-Spam** Per Anti-spam scanning engine examines messages and returns a
Recipient verdict for further processing.
Scanning
Anti-Virus* Anti-Virus scanning examines messages for viruses. Messages
are scanned and optionally repaired, if possible. * Can send
messages to quarantines.
Advanced Advanced Malware Protection performs file reputation scanning
Malware and file analysis, in order to detect malware in attachments.
Protection
Content Filters* Content Filters are applied. * Can send messages to quarantines.
Outbreak Filters* The Outbreak Filters feature helps protect against virus
outbreaks. * Can send messages to quarantines.
Virtual gateways Sends mail over particular IP interfaces or groups of IP
interfaces.
Delivery limits 1. Sets the default delivery interface.
2. Sets the total maximum number of outbound connections.
Domain-based Defines, per-domain: maximum outbound connections for each
Limits virtual gateway and for the entire system; the bounce profile
to use; the TLS preference for delivery: no/preferred/required
Domain-based Routes mail based on domain without rewriting Envelope
routing Recipient.
Global Drops recipients according to specific list (configured
unsubscribe system-wide).
Bounce profiles Undeliverable message handling. Configurable per listener, per
Destination Controls entry, and via message filters.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
762
Configuring Routing and Delivery Features
Review: Email Pipeline
* These features can send messages to special queues called Quarantines.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
763
Configuring Routing and Delivery Features
Review: Email Pipeline
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
764
CHAPTER 31
Integrating the Email Gateway with Cisco
Advanced Phishing Protection
This chapter contains the following sections:
• Overview of Cisco Advanced Phishing Protection, on page 765
• How to Integrate Email Gateway with the Cisco Advanced Phishing Protection Cloud Service, on page
766
• Advanced Phishing Protection and Clusters, on page 773
• Advanced Phishing Protection Report Page, on page 773
• Monitoring Message Metadata on the Cisco Advanced Phishing Protection Cloud Service, on page 774
• Displaying Messages Submitted to the Cisco Advanced Phishing Protection Cloud Service, on page 774
Overview of Cisco Advanced Phishing Protection
Cisco Advanced Phishing Protection provides Business Email Compromise (BEC) and phishing detection
capabilities. It detects identity deception-based threats by performing reputation checks on sender address by
using advanced machine learning techniques and added intelligence. This intelligence continuously adapts to
drive a real-time understanding of senders and provides enhanced protection.
The Advanced Phishing Protection engine on the email gateway checks the unique behavior of all legitimate
senders, based on the historic email traffic to your organization. The cloud service interface of the Cisco
Advanced Phishing Protection provides risk analysis to distinguish good messages from potentially malicious
messages.
The Cisco Advanced Phishing Protection cloud service relies on the email gateway as a sensor engine to
receive a copy of the message metadata sent inbound into your organization. This sensor engine collects
metadata such as message headers from the email gateway and relay them to the Cisco Advanced Phishing
Protection cloud service for analysis. After the analysis, potentially malicious messages are remediated from
the recipient mailbox automatically, based on the pre-configured policies on the Advanced Phishing Protection
cloud service.
The ability to use the email gateway as a sensor engine helps an organization to:
• Identify, investigate, and remediate threats observed on the message headers, from the recipient mailbox.
• View the reporting data of the metadata of the message from multiple email gateways in your organization.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
765
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Benefits of Cisco Advanced Phishing Protection
Benefits of Cisco Advanced Phishing Protection
The following are the benefits of deploying Cisco Advanced Phishing Protection on the email gateway:
• The Sensor-based solution can be rapidly deployed to ensure that your users are fully protected from
damaging breaches.
• Provides another layer of defense to more effectively secure your email environment.
• Gain a real-time understanding of senders, learn, and authenticate email identities and behavioral
relationships to protect against BEC attacks.
• Automatically remove malicious emails from the recipient’s inbox and calls out identity deception
techniques to prevent wire fraud or other advanced attacks.
• Get detailed visibility into email attack activity, including total messages secured and attacks prevented.
• Prevents the following:
• Attacks that use compromised accounts and social engineering.
• Phishing, ransomware, zero-day attacks and spoofing.
• BEC with no malicious payload or URL.
Workflow
1. Activate the license to access the Cisco Advanced Phishing Protection cloud service.
2. Set up the email gateway as a sensor engine on the Cisco Advanced Phishing Protection cloud service.
This deploys the email gateway as a lightweight sensor via the cloud or on-premise.
3. Register the sensor engine on the email gateway with the Cisco Advanced Phishing Protection cloud
service.
4. The sensor engine on the email gateway forwards the metadata of messages considered clean, to the Cisco
Advanced Phishing Protection cloud service.
5. The Cisco Advanced Phishing Protection cloud service determines if the message metadata is malicious.
6. Pre-configured policies on the Cisco Advanced Phishing Protection cloud service, when configured with
an 'Enforcement' sensor, blocks or redirects the message for further incident investigation.
How to Integrate Email Gateway with the Cisco Advanced
Phishing Protection Cloud Service
Perform these steps in the following order:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
766
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Prerequisites
Procedure
Command or Action Purpose
Step 1 Review the prerequsites. Prerequisites, on page 767
Step 2 Obtain the provisioning key from Cisco Obtaining the Provisioning Key from the Cisco
Advanced Phishing Protection cloud service. Advanced Phishing Protection Cloud Service,
on page 768
Step 3 Register your email gateway as a sensor engine Registering the Cisco Advanced Phishing
with the Cisco Advanced Phishing Protection Protection Sensor on the Email Gateway, on
cloud service. page 768
Step 4 Enable Advanced Phishing Protection on the Enabling Advanced Phishing Protection on the
email gateway. Email Gateway, on page 769
Step 5 Obtaining API Access Keys from the Cisco Obtaining API Access Keys from Cisco
Advanced Phishing Protection cloud service. Advanced Phishing Protection Cloud Service,
on page 770
Step 6 Configure incoming mail policies to enable Configuring Incoming Mail Policies to Enable
forwarding of message metadata. Forwarding of Message Metadata, on page 771
Step 7 Monitor metadata of message forwarded to the Monitoring Message Metadata on the Cisco
Advanced Phishing Protection Cloud Service. Advanced Phishing Protection Cloud Service,
on page 772
Prerequisites
• Activating the Account for Cisco Advanced Phishing Protection Cloud Service, on page 767
• Installing Sensors on the Cisco Advanced Phishing Protection Cloud Service, on page 767
Activating the Account for Cisco Advanced Phishing Protection Cloud Service
Make sure that you have:
• Obtained a license to access the Cisco Advanced Phishing Protection cloud service from the following
URL - https://www.cisco.com/c/en/us/buy.html.
• Activated your account using the activation link that you receive through an email notification to get
provisioned with the Cisco Advanced Phishing Protection cloud service.
Installing Sensors on the Cisco Advanced Phishing Protection Cloud Service
Make sure that you have setup your email gateway as sensor engine as per your organizational requirements.
For more information, see User Guide for Cisco Advanced Phishing Protection.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
767
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Obtaining the Provisioning Key from the Cisco Advanced Phishing Protection Cloud Service
Obtaining the Provisioning Key from the Cisco Advanced Phishing Protection
Cloud Service
Before you begin
Make sure that you have access to Cisco Advanced Phishing Protection cloud service with admin access
rights. For more information, see Prerequisites, on page 767. If you are unable to access the Cisco Advanced
Phishing Protection cloud service, contact Cisco TAC for assistance.
Procedure
Step 1 Log in to the Cisco Advanced Phishing Protection cloud service.
Step 2 Choose Manage > Sensors.
Step 3 Select Installation > Download Sensor Installer.
Step 4 From the drop-down, select the sensor installation script configured as per your organizational requirements.
For example: Cisco SEG.
For more information, see Installing Sensors on the Cisco Advanced Phishing Protection Cloud Service, on
page 767.
Step 5 Copy the 6-word provisioning key.
Use this provisioning key to configure the Cisco Email Security Gateway as a sensor.
Note To register the email gateway as a sensor, you must use the provisioning key within 7 days of
generation.
What to do next
Register your email gateway with the Cisco Advanced Phishing Protection cloud service. For more information,
see Registering the Cisco Advanced Phishing Protection Sensor on the Email Gateway, on page 768.
Registering the Cisco Advanced Phishing Protection Sensor on the Email
Gateway
Before you begin
Make sure that you have:
• A valid provisioning key to register your email gateway with the Advanced Phishing Protection cloud
service. For more information, see Obtaining the Provisioning Key from the Cisco Advanced Phishing
Protection Cloud Service, on page 768.
• Opened HTTPS (In and Out) 443 port on the firewall for the FQDNs to register your email gateway with
the Cisco Advanced Phishing Protection cloud service.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
768
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Enabling Advanced Phishing Protection on the Email Gateway
Procedure
Step 1 Log in to the email gateway.
Step 2 Go to Security Services > Advanced Phishing Protection.
Step 3 Click Register.
Step 4 From the URL drop-down, select the region of the Cisco Advanced Phishing Protection cloud service.
Step 5 Enter the 6-word provisioning key obtained from the Advanced Phishing Protection cloud service.
Step 6 Click Register to submit your changes.
The Cisco Advanced Phishing Protection cloud service generates a Universally Unique ID (UUID) after you
register your email gateway with the sensor.
Note After successful registration, the Cisco Advanced Phishing Protection cloud service identifies the
email gateway's hostname in the cloud service.
What to do next
Enable Cisco Advanced Phishing Protection engine on the email gateway. For more information, see Enabling
Advanced Phishing Protection on the Email Gateway, on page 769.
Enabling Advanced Phishing Protection on the Email Gateway
Before you begin
Make sure that you have registered your email gateway as a sensor on the Cisco Advanced Phishing Protection
cloud service. For more information, see Registering the Cisco Advanced Phishing Protection Sensor on the
Email Gateway, on page 768.
Procedure
Step 1 Log in to the email gateway.
Step 2 Go to Security Services > Advanced Phishing Protection.
Step 3 Click Enable.
Step 4 Commit your changes.
What to do next
Enable forwarding of message metadata to the Cisco Advanced Phishing Protection cloud service. For more
information, see Configuring Incoming Mail Policies to Enable Forwarding of Message Metadata, on page
771.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
769
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Obtaining API Access Keys from Cisco Advanced Phishing Protection Cloud Service
Obtaining API Access Keys from Cisco Advanced Phishing Protection Cloud
Service
You can use the API access keys to perform the following tasks in your email gateway:
• Send email notification alerts about APP license expiry details to users.
• View total number of messages that are sent from all email gateways at the organizational level to the
Cisco Advanced Phishing Protection cloud service in a dashboard widget. The dashboard widget is
available on the Advanced Phishing Protection report page of the new web interface.
Before you begin
Make sure that you have:
• Registered the email gateway as a sensor on the Cisco Advanced Phishing Protection cloud service. For
more information, see Registering the Cisco Advanced Phishing Protection Sensor on the Email Gateway,
on page 768.
• Enabled Advanced Phishing Protection on the email gateway. For more information, see Enabling
Advanced Phishing Protection on the Email Gateway, on page 769.
Procedure
Step 1 Log in to the Cisco Advanced Phishing Protection cloud service.
Step 2 Choose Manage > Users.
Step 3 Click the required username.
Step 4 Click Generate API Secret link to generate the API Access keys.
Step 5 Copy the API Access UID and API Access Secret keys locally on your system.
Note In case if you do not copy the API Access keys and close the Cisco Advanced Phishing Protection
cloud service, you need to follow steps 1-3 of the procedure and click Regenerate API Secret link
to obtain new API Access keys.
Step 6 Log in to the legacy web interface of your email gateway.
Step 7 Go to Security Services> Advanced Phishing Protection.
Step 8 Click Edit Settings under ‘Advanced Phishing Protection API Access’ section.
Step 9 Enter the API Access UID key in the ‘API Access UID’ field.
Step 10 Enter the API Access Secret key in the ‘API Access key field.
Step 11 Click Submit.
What to do next
Enable forwarding of message metadata to the Cisco Advanced Phishing Protection cloud service. For more
information, see Configuring Incoming Mail Policies to Enable Forwarding of Message Metadata, on page
771.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
770
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Configuring Incoming Mail Policies to Enable Forwarding of Message Metadata
ConfiguringIncomingMailPoliciestoEnableForwardingofMessageMetadata
You can configure mail policies to enable forwarding of message metadata to the Cisco Advanced Phishing
Protection cloud service.
When you enable the Cisco Advanced Phishing Protection cloud service on your email gateway, the following
message headers are shared with the Cisco Advanced Phishing Protection Cloud service :
• Authentication-Results
• Authentication-Results-original
• DMARC-result
• DKIM-domain
• DKIM-result
• DKIM-selector
• DKIM-signatures
• From-header
• Full-Header-From
• HELO_domain
• Last-Hop-IP-Address
• List-ID
• Mail-From
• Mailing-list
• Message-ID
• Rcpt-To
• Received-Header
• Received-SPF
• Received-Timestamps
• Reply-To
• SPF-result
• Subject-header
• To-header
• Originator-Return-Address
• X-Mailer
• X-Original-Authentication-Results
• X-Original-From
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
771
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Monitoring Message Metadata on the Cisco Advanced Phishing Protection Cloud Service
• X-Original-To
• X-Original-Sender
• X-Originating-IP
• X-OriginatorOrg
• X-Received
Before you begin
Make sure that you have:
• Registered the email gateway as a sensor on the Cisco Advanced Phishing Protection cloud service. For
more information, see Registering the Cisco Advanced Phishing Protection Sensor on the Email Gateway,
on page 768.
• Enabled Advanced Phishing Protection on the email gateway. For more information, see Enabling
Advanced Phishing Protection on the Email Gateway, on page 769.
Procedure
Step 1 Log in to the email security gateway.
Step 2 Go to Mail Policies > Incoming Mail Policies.
Step 3 Click the link below APP Filter.
Step 4 Select Enable Advanced Phishing Protection (Customize Settings) from the drop-down list.
Step 5 Select the check box for Enable Forwarding.
Step 6 Click Submit and commit your changes.
Monitoring Message Metadata on the Cisco Advanced Phishing Protection
Cloud Service
You can monitor metadata of the message that your email security gateway forwards to the Cisco Advanced
Phishing Protection cloud service. The Analyze > Messages page of the cloud service provides insights on
the source of the message and the risk associated with the message and the senders.
The metadata of the message on the Cisco Advanced Phishing Protection cloud service receives a trust score
based on the following:
• Message Authenticity
• Domain Reputation
• Sender Legitimacy
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
772
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Advanced Phishing Protection and Clusters
Advanced Phishing Protection and Clusters
If you use centralized management, you can enable the Advanced Phishing Protection at the cluster, group,
and machine level. If you have registered your email gateway with the Cisco Advanced Phishing Protection
cloud service in standalone mode, you can choose to join a cluster registered with the Cisco Advanced Phishing
Protection cloud service.
Note When you disable the Advanced Phishing Protection at the machine level, the same is disabled on the group
and cluster levels.
Advanced Phishing Protection Report Page
The Monitor > Advanced Phishing Protection report page displays the following:
• Total number of messages successfully forwarded to the Cisco Advanced Phishing Protection cloud
service.
• Total number of messages that are not forwarded to the Cisco Advanced Phishing Protection cloud
service.
Note If the forwarding of message metadata has failed, you must validate the
configurations of the Advanced Phishing Protection feature. For more information,
see How to Integrate Email Gateway with the Cisco Advanced Phishing Protection
Cloud Service, on page 766.
You can use the Advanced Phishing Protection report page to view:
• Total number of messages attempted to be forwarded to the Cisco Advanced Phishing Protection cloud
service, in a graphical format.
• Summary of messages forwarded to the Cisco Advanced Phishing Protection cloud service in a graphical
format.
To view the detailed information on the metadata of the message that is forwarded to the Cisco Advanced
Phishing Protection cloud service, click on the link and login to the Cisco Advanced Phishing Protection cloud
service. For more information, see Monitoring Message Metadata on the Cisco Advanced Phishing Protection
Cloud Service, on page 772.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
773
Integrating the Email Gateway with Cisco Advanced Phishing Protection
Monitoring Message Metadata on the Cisco Advanced Phishing Protection Cloud Service
Monitoring Message Metadata on the Cisco Advanced Phishing
Protection Cloud Service
You can monitor metadata of the message that your email security gateway forwards to the Cisco Advanced
Phishing Protection cloud service. The Analyze > Messages page of the cloud service provides insights on
the source of the message and the risk associated with the message and the senders.
The metadata of the message on the Cisco Advanced Phishing Protection cloud service receives a trust score
based on the following:
• Message Authenticity
• Domain Reputation
• Sender Legitimacy
DisplayingMessagesSubmittedtotheCiscoAdvancedPhishing
Protection Cloud Service
You can view the metadata of the message that you forward to the Cisco Advanced Phishing Protection cloud
service corresponding to the success and failure.
Before you begin
Make sure that you enable the Message Tracking feature on the email gateway. To enable Message Tracking,
go to Security Services > Centralized Services > Message Tracking page in the web interface.
Procedure
Step 1 Log in to the email security gateway.
Step 2 Go to Monitor > Message Tracking.
Step 3 Click Advanced.
Step 4 Check Advanced Phishing Protection Forwarding under Message Event.
Step 5 (Optional) Select Select Successful to view messages that are forwarded successfully to the Cisco Advanced
Phishing Protection cloud service.
Step 6 (Optional) Select Failed to view messages that are not forwarded to the Cisco Advanced Phishing Protection
cloud service.
Step 7 Click Search.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
774
CHAPTER 32
LDAP Queries
This chapter contains the following sections:
• Overview of LDAP Queries, on page 775
• Working with LDAP Queries, on page 785
• Using Acceptance Queries For Recipient Validation, on page 792
• Using Routing Queries to Send Mail to Multiple Target Addresses, on page 793
• Using Masquerading Queries to Rewrite the Envelope Sender, on page 794
• Using Group LDAP Queries to Determine if a Recipient is a Group Member, on page 796
• Using Domain-based Queries to Route to a Particular Domain, on page 799
• Using Chain Queries to Perform a Series of LDAP Queries, on page 801
• Using LDAP For Directory Harvest Attack Prevention, on page 802
• Configuring AsyncOS for SMTP Authentication, on page 804
• Configuring External LDAP Authentication for Users, on page 812
• Authenticating End-Users of the Spam Quarantine, on page 815
• Spam Quarantine Alias Consolidation Queries, on page 816
• Sample User Distinguished Name Settings, on page 818
• Configuring AsyncOS To Work With Multiple LDAP Servers, on page 818
• Testing Servers and Queries, on page 819
Overview of LDAP Queries
If you store user information within LDAP directories in your network infrastructure — for example, in
Microsoft Active Directory, SunONE Directory Server, or OpenLDAP directories — you can configure the
email gateway to query your LDAP servers to accept, route, and authenticate messages. You can configure
the email gateway to work with one or multiple LDAP servers.
The following section provides an overview on the types of LDAP queries you can perform; how LDAP
works with the email gateway to authenticate, accept, and route messages; and how to configure your email
gateway to work with LDAP.
Related Topics
• Understanding LDAP Queries, on page 776
• Understanding How LDAP Works with AsyncOS, on page 777
• Configuring the Email Gateway to Work with an LDAP Server, on page 778
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
775
LDAP Queries
Understanding LDAP Queries
• Creating LDAP Server Profiles to Store Information About the LDAP Server, on page 778
• Testing LDAP Servers, on page 780
• Enabling LDAP Queries to Run on a Particular Listener, on page 780
• Enhanced Support for Microsoft Exchange 5.5, on page 783
Understanding LDAP Queries
If you store user information within LDAP directories in your network infrastructure, you can configure the
email gateway to query your LDAP server for the following purposes:
• Acceptance Queries. You can use your existing LDAP infrastructure to define how the recipient email
address of incoming messages (on a public listener) should be handled. For more information, see Using
Acceptance Queries For Recipient Validation, on page 792.
• Routing (Aliasing). You can configure the email gateway to route messages to the appropriate address
and/or mail host based upon the information available in LDAP directories on your network. For more
information, see Using Routing Queries to Send Mail to Multiple Target Addresses, on page 793.
• Certificate Authentication. You can create a query that checks the validity of a client certificate in order
to authenticate an SMTP session between the user’s mail client and the email gateway. For more
information, see Checking the Validity of a Client Certificate, on page 825.
• Masquerading. You can masquerade Envelope Senders (for outgoing mail) and message headers (for
incoming mail, such as To:, Reply To:, From: or CC:). For more information about masquerading, see
Using Masquerading Queries to Rewrite the Envelope Sender, on page 794.
• Group Queries. You can configure the email gateway to perform actions on messages based on the
groups in the LDAP directory. You do this by associating a group query with a message filter. You can
perform any message action available for message filters on messages that match the defined LDAP
group. For more information, see Using Group LDAP Queries to Determine if a Recipient is a Group
Member, on page 796.
• Domain-based Queries. You can create domain-based queries to allow the email gateway to perform
different queries for different domains on a single listener. When the email gateway runs the domain-based
queries, it determines the query to use based on the domain, and it queries the LDAP server associated
with that domain.
• Chain Queries. You can create a chain query to enable the email gateway to perform a series of queries
in sequence. When you configure a chain query, the email gateway runs each query in sequence until
the LDAP appliance returns a positive result. For chained routing queries, the email gateway re-runs the
same configured chain query in sequence for each rewritten email address.
• Directory Harvest Prevention. You can configure the email gateway to combat directory harvest attacks
using your LDAP directories. You can configure directory harvest prevention during the SMTP
conversation or within the work queue. If the recipient is not found in the LDAP directory, you can
configure the system to perform a delayed bounce or drop the message entirely. Consequently, spammers
are not able to differentiate between valid and invalid email addresses. See Using LDAP For Directory
Harvest Attack Prevention, on page 802.
• SMTP Authentication. AsyncOS provides support for SMTP authentication. SMTP Auth is a mechanism
for authenticating clients connected to an SMTP server. You can use this functionality to enable users
at your organization to send mail using your mail servers even if they are connecting remotely (e.g. from
home or while traveling). For more information, see Configuring AsyncOS for SMTP Authentication,
on page 804.
• External Authentication. You can configure your email gateway to use your LDAP directory to
authenticate users logging in to the email gateway. For more information, see Configuring External
LDAP Authentication for Users, on page 812.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
776
LDAP Queries
Understanding How LDAP Works with AsyncOS
• Spam Quarantine End-User Authentication. You can configure your email gateway to validate users
when they log in to the end-user quarantine. For more information, see Authenticating End-Users of the
Spam Quarantine, on page 815.
• Spam Quarantine Alias Consolidation. If you use email notifications for spam, this query consolidates
the end-user aliases so that end-users do not receive quarantine notices for each aliased email address.
For more information, see Spam Quarantine Alias Consolidation Queries, on page 816.
Understanding How LDAP Works with AsyncOS
When you work with LDAP directories, the email gateway can be used in conjunction with an LDAP directory
server to accept recipients, route messages, and/or masquerade headers. LDAP group queries can also be used
in conjunction with message filters to create rules for handling messages as they are received by the email
gateway.
The following figure demonstrates how the email gateway works with LDAP:
Figure 58: LDAP Configuration
1. The sending MTA sends a message to the public listener “A” via SMTP.
2. The email gateway queries the LDAP server defined via the System Administration > LDAP page (or
by the global ldapconfig command).
3. Data is received from the LDAP directory, and, depending on the queries defined on the System
Administration > LDAP page (or in the ldapconfig command) that are used by the listener:
• the message is routed to the new recipient address, or dropped or bounced
• the message is routed to the appropriate mailhost for the new recipient
• From:, To:, and CC: message headers are re-written based upon the query
• further actions as defined by rcpt-to-group or mail-from-group message filter rules (used
in conjunction with configured group queries).
Note You can configure your email gateway to connect to multiple LDAP servers. When you do this, you can
configure the LDAP profile settings for load-balancing or failover. For more information about working with
multiple LDAP servers, see Configuring AsyncOS To Work With Multiple LDAP Servers, on page 818.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
777
LDAP Queries
Configuring the Email Gateway to Work with an LDAP Server
Configuring the Email Gateway to Work with an LDAP Server
When you configure your email gateway to work with an LDAP directory, you must complete the following
steps to configure your AsyncOS email gateway for acceptance, routing, aliasing, and masquerading:
Procedure
Step 1 Configure LDAP server profiles. The server profile contains information to enable AsyncOS to connect to
the LDAP server (or servers), such as:
• the name of the server (s) and port to send queries,
• the base DN, and
• the authentication requirements for binding to the server
For more information about configuring a server profile, see Creating LDAP Server Profiles to Store Information
About the LDAP Server, on page 778.
When you configure the LDAP server profile, you can configure AsyncOS to connect to one or multiple
LDAP servers.
For information about configuring AsyncOS to connect to multiple servers, see Configuring AsyncOS To
Work With Multiple LDAP Servers, on page 818.
Step 2 Configure the LDAP query. You configure the LDAP queries on the LDAP server profile. The query you
configure should be tailored to your particular LDAP implementation and schema.
For information on the types of LDAP queries you can create, see Understanding LDAP Queries, on page
776.
For information on writing queries, see Working with LDAP Queries, on page 785.
Step 3 Enable the LDAP server profile on a public listener or on a private listener. You must enable the LDAP
server profile on a listener to instruct the listener to run the LDAP query when accepting, routing, or sending
a message.
For more information, see Enabling LDAP Queries to Run on a Particular Listener, on page 780.
Note When you configure a group query, you need to take additional steps to configure AsyncOS to work
with the LDAP server. For information on configuring a group query, see Using Group LDAP
Queries to Determine if a Recipient is a Group Member, on page 796. When you configure an
end-user authentication or spam notification consolidation query, you must enable LDAP end-user
access to the Spam Quarantine. For more information on the Spam Quarantine, see the Spam
Quarantine chapter.
Creating LDAP Server Profiles to Store Information About the LDAP Server
When you configure AsyncOS to use LDAP directories, you create an LDAP server profile to store the
information about the LDAP server.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
778
LDAP Queries
Creating LDAP Server Profiles to Store Information About the LDAP Server
Procedure
Step 1 On the System Administration > LDAP page, click Add LDAP Server Profile.
Step 2 Enter a name for the server profile.
Step 3 Enter the host name for the LDAP server.
You can enter multiple host names to configure the LDAP servers for failover or load-balancing. Separate
multiple entries with commas. For more information, see Configuring AsyncOS To Work With Multiple
LDAP Servers, on page 818.
Step 4 Select an authentication method. You can use anonymous authentication or specify a username and passphrase.
Step 5 Select the LDAP server type: Active Directory, OpenLDAP, or Unknown or Other.
Step 6 Enter a port number.
The default port is 3268 without SSL and 3269 with SSL for Active Directory or any Unknown / Other server
types.
The default port is 389 without SSL and 636 with SSL, for Open LDAP server types.
Step 7 Enter a Base DN (distinguishing name) for the LDAP server.
If you authenticate with a username and a passphrase, the username must include the full DN to the entry that
contains the passphrase. For example, a user is a member of the marketing group with an email address of
[email protected]. The entry for this user would look like the following entry:
uid=joe, ou=marketing, dc=example dc=com
Step 8 Select whether to use SSL when communicating with the LDAP server.
Note [Optional - Only if the 'Validate LDAP Server Certificate' option is selected in the LDAP Global
Settings page and FQDN validation enabled in SSL Configuration settings page]: Check whether
the 'Common Name,' 'SAN: DNS Name' fields, or both present in the server certificate, are in the
FQDN format.
Note [Optional - Only if the 'Validate LDAP Server Certificate' option is selected in the LDAP Global
Settings page and X 509 validation enabled in SSL Configuration settings page]: Check for signature
algorithm of the server certificate.
Step 9 Under Advanced, enter cache time-to-live. This value represents the amount of time to retain caches.
Step 10 Enter the maximum number of retained cache entries.
Note This cache is maintained per LDAP server. If you are configuring more than one LDAP servers,
you must set a smaller LDAP cache value for better performance. Also, if the memory usage of
various processes in the email gateway is high, increasing this value may reduce the system
performance.
Step 11 Enter the number of simultaneous connections.
• If you configure the LDAP server profile for load balancing, these connections are distributed among
the listed LDAP servers. For example, if you configure 10 simultaneous connections and load balance
the connections over three servers, AsyncOS creates 10 connections to each server, for a total of 30
connections.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
779
LDAP Queries
Testing LDAP Servers
Note The maximum number of simultaneous connections includes LDAP connections used for
LDAP queries. However, the email gateway may open more connections if you use LDAP
authentication for the Spam Quarantine.
• You can configure the maximum time (in seconds) for which the connections to the LDAP server must
persist before the connections reset. Choose a value between 60 and 86400.
Step 12 Test the connection to the server by clicking the Test Server(s) button. If you specified multiple LDAP servers,
they are all tested. The results of the test appear in the Connection Status field. For more information, see
Testing LDAP Servers, on page 780.
Step 13 Create queries by marking the checkbox and completing the fields. You can select Accept, Routing, Masquerade,
Group, SMTP Authentication, External Authentication, Spam Quarantine End-User Authentication, and Spam
Quarantine Alias Consolidation.
Note To allow the email gateway to run LDAP queries when you receive or send messages, you must
enable the LDAP query on the appropriate listener. For more information, see Enabling LDAP
Queries to Run on a Particular Listener, on page 780.
Step 14 Test a query by clicking the Test Query button.
Enter the test parameters and click Run Test. The results of the test appear in the Connection Status field. If
you make any changes to the query definition or attributes, click Update. For more information, see Testing
LDAP Servers, on page 780.
Note If you have configured the LDAP server to allow binds with empty passphrases, the query can pass
the test with an empty passphrase field.
Step 15 Submit and commit your changes.
Note Although the number of server configurations is unlimited, you can configure only one recipient
acceptance, one routing, one masquerading, and one group query per server.
Testing LDAP Servers
Use the Test Server(s) button on the Add/Edit LDAP Server Profile page (or the test subcommand of the
ldapconfig command in the CLI) to test the connection to the LDAP server. AsyncOS displays a message
stating whether the connection to the server port succeeded or failed. If you configured multiple LDAP servers,
AsyncOS tests each server and displays individual results.
Enabling LDAP Queries to Run on a Particular Listener
To allow the email gateway to run LDAP queries when you receive or send messages, you must enable the
LDAP query on the appropriate listener.
Related Topics
• Configuring Global Settings for LDAP Queries, on page 781
• Example of Creating an LDAP Server Profile, on page 781
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
780
LDAP Queries
Configuring Global Settings for LDAP Queries
• Enabling LDAP Queries on a Public Listener, on page 782
• Enabling LDAP Queries on a Private Listener, on page 783
Configuring Global Settings for LDAP Queries
The LDAP global settings define how the email gateway handles all LDAP traffic.
Procedure
Step 1 On the System Administration > LDAP page, click Edit Settings.
Step 2 Select the IP interface to use for LDAP traffic. The email gateway automatically chooses an interface by
default.
Step 3 Select the TLS certificate to use for the LDAP interface (TLS certificates added via the Network > Certificates
page or the certconfig command in the CLI are available in the list, see Overview of Encrypting
Communication with Other MTAs, on page 675).
Step 4 Select appropriate option, if you want to validate the LDAP server certificate.
Step 5 Submit and commit your changes.
Example of Creating an LDAP Server Profile
In the following example, the System Administration > LDAP page is used to define an LDAP server for the
email gateway to bind to, and queries for recipient acceptance, routing, and masquerading are configured.
Note There is a 60 second connection attempt time-out for LDAP connections (which covers the DNS lookup, the
connection itself, and, if applicable, the authentication bind for the email gateway itself). After the first failure,
AsyncOS immediately starts trying other hosts in the same server (if you specified more than one in the comma
separated list). If you only have one host in the server, AsyncOS continues attempting to connect to it.
Figure 59: Configuring an LDAP Server Profile (1 of 2)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
781
LDAP Queries
Enabling LDAP Queries on a Public Listener
First, the nickname of “PublicLDAP” is given for the myldapserver.example.com LDAP server. The number
of connections is set to 10 (the default), and the multiple LDAP server (hosts) load balance option is left as
the default. You can specify multiple hosts here by providing a comma separated list of names. Queries are
directed to port 3268 (the default). SSL is not enabled as the connection protocol for this host. The base DN
of example.com is defined ( dc=example,dc=com ). The cache time-to-live is set to 900 seconds, the maximum
number of cache entries is 10000, and the authentication method is set to passphrase.
Queries for recipient acceptance, mail routing, and masquerading are defined. Remember that query names
are case-sensitive and must match exactly in order to return the proper results.
Figure 60: Configuring an LDAP Server Profile (2 of 2)
Enabling LDAP Queries on a Public Listener
In this example, the public listener “InboundMail” is updated to use LDAP queries for recipient acceptance.
Further, recipient acceptance is configured to happen during the SMTP conversation (for more information,
see Using Acceptance Queries For Recipient Validation, on page 792 for more information).
Figure 61: Enabling Acceptance and Routing Queries on a Listener
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
782
LDAP Queries
Enabling LDAP Queries on a Private Listener
Enabling LDAP Queries on a Private Listener
In this example, the private listener “OutboundMail” is updated to use LDAP queries for masquerading. The
masqueraded fields include: From, To, CC, and Reply-To.
Figure 62: Enabling a Masquerading Query on a Listener
Enhanced Support for Microsoft Exchange 5.5
AsyncOS includes a configuration option to provide support for Microsoft Exchange 5.5. If you use a later
version of Microsoft Exchange, you do not need to enable this option. When configuring an LDAP server,
you can elect to enable Microsoft Exchange 5.5 support by answering “y” when prompted in the ldapconfig
-> edit -> server -> compatibility subcommand (this is only available via the CLI):
mail3.example.com> ldapconfig
Current LDAP server configurations:
1. PublicLDAP: (ldapexample.com:389)
Choose the operation you want to perform:
- NEW - Create a new server configuration.
- EDIT - Modify a server configuration.
- DELETE - Remove a server configuration.
[]> edit
Enter the name or number of the server configuration you wish to edit.
[]> 1
Name: PublicLDAP
Hostname: ldapexample.com Port 389
Authentication Type: anonymous
Base: dc=ldapexample,dc=com
Choose the operation you want to perform:
- SERVER - Change the server for the query.
- LDAPACCEPT - Configure whether a recipient address should be accepted or
bounced/dropped.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
783
LDAP Queries
Enhanced Support for Microsoft Exchange 5.5
- LDAPROUTING - Configure message routing.
- MASQUERADE - Configure domain masquerading.
- LDAPGROUP - Configure whether a sender or recipient is in a specified group.
- SMTPAUTH - Configure SMTP authentication.
[]> server
Name: PublicLDAP
Hostname: ldapexample.com Port 389
Authentication Type: anonymous
Base: dc=ldapexample,dc=com
Microsoft Exchange 5.5 Compatibility Mode: Disabled
Choose the operation you want to perform:
- NAME - Change the name of this configuration.
- HOSTNAME - Change the hostname used for this query.
- PORT - Configure the port.
- AUTHTYPE - Choose the authentication type.
- BASE - Configure the query base.
- COMPATIBILITY - Set LDAP protocol compatibility options.
[]> compatibility
Would you like to enable Microsoft Exchange 5.5 LDAP compatibility mode? (This is not
recommended for versions of Microsoft Exchange later than 5.5, or other LDAP servers.)
[N]> y
Do you want to configure advanced LDAP compatibility settings? (Typically not required)
[N]>
Name: PublicLDAP
Hostname: ldapexample.com Port 389
Authentication Type: anonymous
Base: dc=ldapexample,dc=com
Microsoft Exchange 5.5 Compatibility Mode: Enabled (attribute "objectClass")
Choose the operation you want to perform:
- NAME - Change the name of this configuration.
- HOSTNAME - Change the hostname used for this query.
- PORT - Configure the port.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
784
LDAP Queries
Working with LDAP Queries
- AUTHTYPE - Choose the authentication type.
- BASE - Configure the query base.
- COMPATIBILITY - Set LDAP protocol compatibility options.
[]>
Working with LDAP Queries
You create an entry in the LDAP server profile for each type of LDAP query you want to perform. When you
create LDAP queries, you must enter the query syntax for your LDAP server. Please note that the queries you
construct should be tailored and specific to your particular implementation of LDAP directory services,
particularly if you have extended your directory with new object classes and attributes to accommodate the
unique needs of your directory.
Related Topics
• Types of LDAP Queries, on page 785
• Base Distinguishing Name (DN), on page 786
• LDAP Query Syntax, on page 786
• Secure LDAP (SSL), on page 787
• Routing Queries, on page 787
• Allowing Clients to Bind to the LDAP Server Anonymously , on page 787
• Testing LDAP Queries, on page 790
• Troubleshooting Connections to LDAP Servers, on page 791
Types of LDAP Queries
• Acceptance queries. For more information, see Using Acceptance Queries For Recipient Validation,
on page 792.
• Routing queries. For more information, see Using Routing Queries to Send Mail to Multiple Target
Addresses, on page 793.
• Certificate Authentication queries. For more information, see Checking the Validity of a Client
Certificate, on page 825.
• Masquerading queries. For more information, see Using Masquerading Queries to Rewrite the Envelope
Sender, on page 794.
• Group queries. For more information, see Using Group LDAP Queries to Determine if a Recipient is
a Group Member, on page 796.
• Domain-based queries. For more information, see Using Domain-based Queries to Route to a Particular
Domain, on page 799.
• Chain queries. For more information, see Using Chain Queries to Perform a Series of LDAP Queries,
on page 801.
You can also configure queries for the following purposes:
• Directory harvest prevention. For more information, see Understanding LDAP Queries, on page 776.
• SMTP authentication. For more information, see Configuring AsyncOS for SMTP Authentication, on
page 804.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
785
LDAP Queries
Base Distinguishing Name (DN)
• External authentication. For more information, Configuring External LDAP Authentication for Users,
on page 812.
• Spam quarantine end-user authentication query. For more information, see Authenticating End-Users
of the Spam Quarantine, on page 815.
• Spam quarantine alias consolidation query. For more information, see Spam Quarantine Alias
Consolidation Queries, on page 816.
The search queries you specify are available to all listeners you configure on the system.
Base Distinguishing Name (DN)
The root level of the directory is called the base. The name of the base is the DN (distinguishing name). The
base DN format for Active Directory (and the standard as per RFC 2247) has the DNS domain translated into
domain components (dc=). For example, example.com's base DN would be: dc=example, dc=com. Note that
each portion of the DNS name is represented in order. This may or may not reflect the LDAP settings for your
configuration.
If your directory contains multiple domains you may find it inconvenient to enter a single BASE for your
queries. In this case, when configuring the LDAP server settings, set the base to NONE. This will, however,
make your searches inefficient.
LDAP Query Syntax
Spaces are allowed in LDAP paths, and they do not need to be quoted. The CN and DC syntax is not
case-sensitive.
Cn=First Last,oU=user,dc=domain,DC=COM
The variable names you enter for queries are case-sensitive and must match your LDAP implementation in
order to work correctly. For example, entering mailLocalAddress at a prompt performs a different query
than entering maillocaladdress.
Related Topics
• Tokens:, on page 786
Tokens:
You can use the following tokens in your LDAP queries:
• {a} username@domainname
• {d} domainname
• {dn} distinguished name
• {g} groupname
• {u} username
• {f} MAIL FROM: address
Note The {f} token is valid in acceptance queries only.
For example, you might use the following query to accept mail for an Active Directory LDAP server:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
786
LDAP Queries
Secure LDAP (SSL)
(|(mail={a})(proxyAddresses=smtp:{a}))
Note Cisco Systems strongly recommends using the Test feature of the LDAP page (or the test subcommand of
the ldapconfig command) to test all queries you construct and ensure that expected results are returned
before you enable LDAP functionality on a listener. See Testing LDAP Queries, on page 790 for more
information.
Secure LDAP (SSL)
You can use instruct AsyncOS to use SSL when communicating with the LDAP server. If you configure your
LDAP server profile to use SSL:
• AsyncOS will use the LDAPS certificate configured via certconfig in the CLI (see Creating a Self-Signed
Certificate , on page 678).
You may have to configure your LDAP server to support using the LDAPS certificate.
• If an LDAPS certificate has not been configured, AsyncOS will use the demo certificate.
Routing Queries
There is no recursion limit for LDAP routing queries; the routing is completely data driven. However, AsyncOS
does check for circular reference data to prevent the routing from looping infinitely.
Allowing Clients to Bind to the LDAP Server Anonymously
You may need to configure your LDAP directory server to allow for anonymous queries. (That is, clients can
bind to the server anonymously and perform queries.) For specific instructions on configuring Active Directory
to allow anonymous queries, see the “Microsoft Knowledge Base Article - 320528” at the following URL:
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B320528
Alternately, you can configure one “user” dedicated solely for the purposes of authenticating and performing
queries instead of opening up your LDAP directory server for anonymous queries from any client.
A summary of the steps is included here, specifically:
• How to set up Microsoft Exchange 2000 server to allow “anonymous” authentication.
• How to set up Microsoft Exchange 2000 server to allow “anonymous bind.”
• How to set up AsyncOS to retrieve LDAP data from a Microsoft Exchange 2000 server using both
“anonymous bind” and “anonymous” authentication.
Specific permissions must be made to a Microsoft Exchange 2000 server in order to allow “anonymous” or
“anonymous bind” authentication for the purpose of querying user email addresses. This can be very useful
when an LDAP query is used to determine the validity of an income email message to the SMTP gateway.
Related Topics
• Anonymous Authentication Setup, on page 788
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
787
LDAP Queries
Anonymous Authentication Setup
• Anonymous Bind Setup for Active Directory, on page 789
• Notes for Active Directory Implementations, on page 790
Anonymous Authentication Setup
The following setup instructions allow you to make specific data available to unauthenticated queries of Active
Directory and Exchange 2000 servers in the Microsoft Windows Active Directory. If you wish to allow
“anonymous bind” to the Active Directory, see Anonymous Bind Setup for Active Directory, on page 789.
Procedure
Step 1 Determine required Active Directory permissions.
Using the ADSI Edit snap-in or the LDP utility, you must modify the permissions to the attributes of the
following Active Directory objects:
• The root of the domain naming context for the domain against which you want to make queries.
• All OU and CN objects that contain users against which you wish to query email information.
The following table shows the required permissions to be applied to all of the needed containers.
User Object Permissions Inheritance Permission Type
Everyone List Contents Container Objects Object
Everyone List Contents Organizational Unit Objects Object
Everyone Read Public Information User Objects Property
Everyone Read Phone and Mail Options User Objects Property
Step 2 Set Active Directory Permissions
• Open ADSIEdit form the Windows 2000 Support Tools.
• Locate the Domain Naming Context folder. This folder has the LDAP path of your domain.
• Right click the Domain Naming Context folder, and then click Properties.
• Click Security.
• Click Advanced.
• Click Add.
• Click the User Object Everyone, and then click OK.
• Click the Permission Type tab.
• Click Inheritance from the Apply onto box.
• Click to select the Allow check box for the Permission permission.
Step 3 Configure the Cisco Messaging Gateway
Use ldapconfig on the Command Line Interface (CLI) to create an LDAP server entry with the following
information.
• Hostname of an Active Directory or Exchange server
• Port 3268
• Base DN matching the root naming context of the domain
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
788
LDAP Queries
Anonymous Bind Setup for Active Directory
• Authentication type Anonymous
Anonymous Bind Setup for Active Directory
The following setup instructions allow you to make specific data available to anonymous bind queries of
Active Directory and Exchange 2000 servers in the Microsoft Windows Active Directory. Anonymous bind
of an Active Directory server will send the username anonymous with a blank passphrase.
Note If a passphrase is sent to an Active Directory server while attempting anonymous bind, authentication may
fail.
Procedure
Step 1 Determine required Active Directory permissions.
Using the ADSI Edit snap-in or the LDP utility, you must modify the permissions to the attributes of the
following Active Directory objects.
• The root of the domain naming context for the domain against which you want to make queries.
• All OU and CN objects that contain users against which you wish to query email information.
The following table shows the required permissions to be applied to all of the needed containers.
User Object Permissions Inheritance Permission Type
ANONYMOUS LOGON List Contents Container Objects Object
ANONYMOUS LOGON List Contents Organizational Unit Objects Object
ANONYMOUS LOGON Read Public Information User Objects Property
ANONYMOUS LOGON Read Phone and Mail Options User Objects Property
Step 2 Set Active Directory Permissions
• Open ADSIEdit form the Windows 2000 Support Tools.
• Locate the Domain Naming Context folder. This folder has the LDAP path of your domain.
• Right click the Domain Naming Context folder, and then click Properties.
• Click Security.
• Click Advanced.
• Click Add.
• Click the User Object ANONYMOUS LOGON, and then click OK.
• Click the Permission Type tab.
• Click Inheritance from the Apply onto box.
• Click to select the Allow check box for the Permission permission.
Step 3 Configure the Cisco Messaging Gateway
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
789
LDAP Queries
Notes for Active Directory Implementations
Use the System Administration > LDAP page (or ldapconfig in the CLI) to create an LDAP server entry
with the following information.
• Hostname of an Active Directory or Exchange server
• Port 3268
• Base DN matching the root naming context of the domain
• Authentication type passphrase based using cn=anonymous as the user with a blank passphrase
Notes for Active Directory Implementations
• Active Directory servers accept LDAP connections on ports 3268 and 389. The default port for accessing
the global catalog is port 3268.
• Active Directory servers accept LDAPS connections on ports 636 and 3269. Microsoft supports LDAPS
on Windows Server 2003 and higher.
• The email gateway should connect to a domain controller that is also a global catalog so that you can
perform queries to different bases using the same server.
• Within Active Directory, you may need to grant read permissions to the group “Everyone” to directory
objects to yield successful queries. This includes the root of the domain naming context.
• Generally, the value of the mail attribute entry in many Active Directory implementations has a matching
value “ProxyAddresses” attribute entry.
• Microsoft Exchange environments that are aware of each other within the infrastructure can usually route
mail between each other without involving a route back to the originating MTA.
Testing LDAP Queries
Use the Test Query button on the Add/Edit LDAP Server Profile page (or the test sub command in the CLI)
of each query type to test the query to the LDAP server you configured. In addition to displaying the result,
AsyncOS also displays the details on each stage of the query connection test. You can test each of the query
types.
The ldaptest command is available as a batch command, for example:
ldaptest LDAP.ldapaccept [email protected]
If you entered multiple hosts in the Host Name field of the LDAP server attributes, the email gateway tests
the query on each LDAP server.
Table 67: Testing LDAP Queries
Query type If a recipient matches (PASS)... If a recipient does not match (FAIL)...
Recipient Acceptance Accept the message. Invalid Recipient: Conversation or
(Accept, ldapaccept ) delayed bounce or drop the message
per listener settings. DHAP: Drop.
Routing Route based on the query settings. Continue processing the message.
(Routing, ldaprouting )
Masquerade (Masquerade, Alter the headers with the variable Continue processing the message.
masquerade ) mappings defined by the query.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
790
LDAP Queries
Troubleshooting Connections to LDAP Servers
Query type If a recipient matches (PASS)... If a recipient does not match (FAIL)...
Group Membership (Group, Return “true” for message filter rules. Return “false” for message filter rules.
ldapgroup )
SMTP Auth A passphrase is returned from the No passphrase match can occur;
LDAP server and is used for SMTP Authentication attempts fail.
(SMTP Authentication,
authentication; SMTP Authentication
smtpauth )
occurs.
External Authentication ( Individually returns a “match Individually returns a “match
externalauth ) positive” for the bind, the user record, negative” for the bind, the user record,
and the user’s group membership. and the user’s group membership.
Spam Quarantine End-User Returns a “match positive” for the No passphrase match can occur;
Authentication ( isqauth ) end-user account. End-User Authentication attempts fail.
Spam Quarantine Alias Returns the email address that the No consolidation of spam notifications
Consolidation ( isqalias ) consolidated spam notifications will can occur.
be sent to.
Note The variable names you enter for queries are case-sensitive and must match your LDAP implementation in
order to work correctly. For example, entering mailLocalAddress at a prompt performs a different query than
entering maillocaladdress. Cisco Systems strongly recommends using the test subcommand of the ldapconfig
command to test all queries you construct and ensure the proper results are returned.
Troubleshooting Connections to LDAP Servers
If the LDAP server is unreachable by the email gateway, one of the following errors will be shown:
• Error: LDAP authentication failed: <LDAP Error "invalidCredentials" [0x31]>
• Error: Server unreachable: unable to connect
• Error: Server unreachable: DNS lookup failure
Note that a server may be unreachable because the wrong port was entered in the server configuration, or the
port is not opened in the firewall. LDAP servers typically communicate over port 3268 or 389. Active Directory
uses port 3268 to access the global catalog used in multi-server environments (See the “Firewall Information”
appendix for more information.) In AsyncOS 4.0, the ability to communicate to the LDAP server via SSL
(usually over port 636) was added. For more information, see Secure LDAP (SSL), on page 787.
A server may also be unreachable because the hostname you entered cannot be resolved.
You can use the Test Server(s) on the Add/Edit LDAP Server Profile page (or the test subcommand of the
ldapconfig command in the CLI) to test the connection to the LDAP server. For more information, see Testing
LDAP Servers, on page 780.
If the LDAP server is unreachable:
• If LDAP Accept or Masquerading or Routing is enabled on the work queue, mail will remain within the
work queue.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
791
LDAP Queries
Using Acceptance Queries For Recipient Validation
• If LDAP Accept is not enabled but other queries (group policy checks, etc.) are used in filters, the filters
evaluate to false.
Using Acceptance Queries For Recipient Validation
You can use your existing LDAP infrastructure to define how the recipient email address of incoming messages
(on an public listener) should be handled. Changes to user data in your directories are updated the next time
the email gateway queries the directory server. You can specify the size of the caches and the amount of time
the email gateway stores the data it retrieves.
Note You may wish to bypass LDAP acceptance queries for special recipients (such as [email protected]
). You can configure this setting from the Recipient Access Table (RAT). For information about configuring
this setting, see the “Configuring the Gateway to Receive Email” chapter.
Related Topics
• Sample Acceptance Queries, on page 792
• Configuring Acceptance Queries for Lotus Notes, on page 793
Sample Acceptance Queries
The following table shows sample acceptance queries.
Table 68: Example LDAP Query Strings for Common LDAP Implementations: Acceptance
Query for: Recipient validation
OpenLDAP (mailLocalAddress={a})
(mail={a})
(mailAlternateAddress={a})
Microsoft Active Directory Address Book (|(mail={a})(proxyAddresses=smtp:{a}))
Microsoft Exchange
SunONE Directory Server (mail={a})
(mailAlternateAddress={a})
(mailEquivalentAddress={a})
(mailForwardingAddress={a})
(mailRoutingAddress={a})
Lotus NotesLotus Domino (|(|(mail={a})(uid={u}))(cn={u}))
(|(ShortName={u})(InternetAddress={a})(FullName={u}))
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
792
LDAP Queries
Configuring Acceptance Queries for Lotus Notes
You can also validate on the username (Left Hand Side). This is useful if your directory does not contain all
the domains you accept mail for. Set the Accept query to (uid={u}).
Configuring Acceptance Queries for Lotus Notes
Note that there is a potential complication with LDAPACCEPT and Lotus Notes. If Notes LDAP contains a
person with attributes like these:
[email protected]
cn=Joe User
uid=juser
cn=123456
location=New Jersey
Lotus accepts email for this person for various different forms of email addresses, other than what is specified,
such as “[email protected]” — which do not exist in the LDAP directory. So AsyncOS may not be
able to find all of the valid user email addresses for that user.
One possible solution is to try to publish the other forms of addresses. Please contact your Lotus Notes
administrator for more details.
Using Routing Queries to Send Mail to Multiple Target
Addresses
AsyncOS supports alias expansion (LDAP routing with multiple target addresses). AsyncOS replaces the
original email message with a new, separate message for each alias target (for example, [email protected]
might be replaced with new separate messages to [email protected] and
[email protected], etc.). Routing queries are sometimes known as aliasing queries on
other mail processing systems.
Related Topics
• Sample Routing Queries, on page 793
Sample Routing Queries
Table 69: Example LDAP Query Strings for Common LDAP Implementations: Routing
Query for: Route to another mailhost
OpenLDAP
(mailLocalAddress={a})
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
793
LDAP Queries
Routing: MAILHOST and MAILROUTINGADDRESS
Query for: Route to another mailhost
Microsoft Active Directory Address May not be applicable
Book
Microsoft Exchange
SunONE Directory Server
(mail={a})
(mailForwardingAddress={a})
(mailEquivalentAddress={a})
(mailRoutingAddress={a})
(otherMailbox={a})
(rfc822Mailbox={a})
a. Active Directory implementations can have multiple entries for the proxyAddresses attribute, but because
AD formats this attribute value as smtp:[email protected], that data cannot be used for LDAP routing/alias
expansion. Each target address must be in a separate attribute:value pair. Microsoft Exchange environments
that are aware of each other within the infrastructure can usually route mail between each other without
involving a route back to the originating MTA.
Related Topics
• Routing: MAILHOST and MAILROUTINGADDRESS, on page 794
Routing: MAILHOST and MAILROUTINGADDRESS
For Routing queries, the value of MAILHOST cannot be an IP address; it must be a resolvable hostname.
This usually requires the use of an Internal DNSconfig.
MAILHOST is optional for the routing query. MAILROUTINGADDRESS is mandatory if MAILHOST is
not set.
Using Masquerading Queries to Rewrite the Envelope Sender
Masquerading is a feature that rewrites the Envelope Sender (also known as the sender, or MAIL FROM) and
the To:, From:, and/or CC: headers on email based on queries you construct. A typical example implementation
of this feature is “Virtual Domains,” which allows you to host multiple domains from a single site. Another
typical implementation is “hiding” your network infrastructure by “stripping” the subdomains from strings
in email headers.
Related Topics
• Sample Masquerading Queries , on page 795
• Masquerading “Friendly Names”, on page 795
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
794
LDAP Queries
Sample Masquerading Queries
Sample Masquerading Queries
Table 70: Example LDAP Query Strings for Common LDAP Implementation: Masquerading
Query for: Masquerade
OpenLDAP
(mailRoutingAddress={a})
Microsoft Active Directory Address Book
(proxyaddresses=smtp:{a})
SunONE Directory Server
(mail={a})
(mailAlternateAddress={a})
(mailEquivalentAddress={a})
(mailForwardingAddress={a})
(mailRoutingAddress={a})
Masquerading “Friendly Names”
In some user environments, an LDAP directory server schema may store a “friendly name” in addition to a
mail routing address or a local mail address. AsyncOS allows you to masquerade Envelope Senders (for
outgoing mail) and message headers (for incoming mail, such as To:, Reply To:, From: or CC:) with this
“friendly address” — even if the friendly address contains special characters that are not normally permitted
in a valid email address (for example, quotation marks, spaces, and commas).
When using masquerading of headers via an LDAP query, you now have the option to configure whether to
replace the entire friendly email string with the results from the LDAP server. Note that even with this behavior
enabled, only the user@domain portion will be used for the Envelope Sender (the friendly name is illegal).
As with the normal LDAP masquerading, if empty results (zero length or entire white space) are returned
from the LDAP query, no masquerading occurs.
To enable this feature, answer “y” to the following question when configuring an LDAP-based masquerading
query for a listener (LDAP page or ldapconfig command):
Do you want the results of the returned attribute to replace the entire
friendly portion of the original recipient? [N]
For example, consider the following example LDAP entry:
Attribute Value
mailRoutingAddress admin\@example.com
mailLocalAddress joe.smith\@example.com
mailFriendlyAddress “Administrator for example.com,” <joe.smith\@example.com>
If this feature is enabled, an LDAP query of (mailRoutingAddress={a}) and a masquerading attribute of
(mailLocalAddress) would result in the following substitutions:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
795
LDAP Queries
Using Group LDAP Queries to Determine if a Recipient is a Group Member
Original Address (From, To, CC, Masqueraded Headers Masqueraded Envelope Sender
Reply-to)
[email protected] From: “Administrator for MAIL FROM:
example.com,” <[email protected]>
<[email protected]>
Using Group LDAP Queries to Determine if a Recipient is a Group
Member
You can define a query to your LDAP servers to determine if a recipient is a member of a group as defined
by your LDAP directory.
Procedure
Step 1 Create a message filter that uses a rcpt-to-group or mail-from-group rule to act upon the message.
Step 2 Then, use the System Administration > LDAP page (or the ldapconfig command) to define the LDAP
server for the email gateway to bind to and configure a query for a group membership.
Step 3 Use the Network > Listeners page (or the listenerconfig -> edit -> ldapgroup subcommand)
to enable the group query for the listener.
What to do next
Related Topics
• Sample Group Queries , on page 796
• Configuring a Group Query, on page 797
Sample Group Queries
Table 71: Example LDAP Query Strings for Common LDAP Implementation: Group
Query for: Group
OpenLDAP OpenLDAP does not support the memberOf attribute by default. Your
LDAP Administrator may add this attribute or a similar attribute to the
schema.
Microsoft Active Directory
(&(memberOf={g})(proxyAddresses=smtp:{a}))
SunONE Directory Server
(&(memberOf={g})(mailLocalAddress={a}))
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
796
LDAP Queries
Configuring a Group Query
For example, suppose that your LDAP directory classifies members of the “Marketing” group as ou=Marketing
. You can use this classification to treat messages sent to or from members of this group in a special way.
Step 1 creates a message filter to act upon the message, and Steps 2 and 3 enable the LDAP lookup mechanism.
Configuring a Group Query
In the following example, mail from members of the Marketing group (as defined by the LDAP group
“Marketing”) will be delivered to the alternate delivery host marketingfolks.example.com .
Procedure
Step 1 First, a message filter is created to act upon messages that match positively for group membership. In this
example, a filter is created that uses the mail-from-group rule. All messages whose Envelope Sender is found
to be in the LDAP group “marketing-group1” will be delivered with an alternate delivery host (the filters
alt-mailhost action).
The group membership field variable (groupName) will be defined in step 2. The group attribute “groupName”
is defined with the value marketing-group1 .
mail3.example.com> filters
Choose the operation you want to perform:
- NEW - Create a new filter.
- IMPORT - Import a filter script from a file.
[]> new
Enter filter script. Enter '.' on its own line to end.
MarketingGroupfilter:
if (mail-from-group == "marketing-group1") {
alt-mailhost ('marketingfolks.example.com');}
1 filters added.
Choose the operation you want to perform:
- NEW - Create a new filter.
- DELETE - Remove a filter.
- IMPORT - Import a filter script from a file.
- EXPORT - Export filters to a file
- MOVE - Move a filter to a different position.
- SET - Set a filter attribute.
- LIST - List the filters.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
797
LDAP Queries
Example: Using a Group Query to Skip Spam and Virus Checking
- DETAIL - Get detailed information on the filters.
- LOGCONFIG - Configure log subscriptions used by filters.
- ROLLOVERNOW - Roll over a filter log file.
[]>
For more information on the mail-from-group and rcpt-to-group message filter rules, see Message Filter
Rules, on page 140.
Step 2 Next, the Add LDAP Server Profile page is used to define an LDAP server for the email gateway to bind to,
and an initial query for a group membership is configured.
Step 3 Next, the public listener “InboundMail” is updated to use LDAP queries for group routing. The Edit Listener
page is used to enable the LDAP query specified above.
As a result of this query, messages accepted by the listener trigger a query to the LDAP server to determine
group membership. The PublicLDAP2.group query was defined previously via the System Administration
> LDAP page.
Figure 63: Specifying a Group Query on a Listener
Step 4 Submit and commit your changes.
Example: Using a Group Query to Skip Spam and Virus Checking
Because message filters occurs early in the pipeline, you can use a group query to skip virus and spam checking
for specified groups. For example, you want your IT group to receive all messages and to skip spam and virus
checking. In your LDAP record, you create a group entry that uses the DN as the group name. The group
name consists of the following DN entry:
cn=IT, ou=groups, o=sample.com
You create an LDAP server profile with the following group query:
(&(memberOf={g})(proxyAddresses=smtp:{a}))
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
798
LDAP Queries
Using Domain-based Queries to Route to a Particular Domain
You then enable this query on a listener so that when a message is received by the listener, the group query
is triggered.
To skip virus and spam filtering for members of the IT group, you create the following message filter to check
incoming messages against LDAP groups.
[]> - NEW - Create a new filter.
- IMPORT - Import a filter script from a file.
[]> new
Enter filter script. Enter '.' on its own line to end.
IT_Group_Filter:
if (rcpt-to-group == "cn=IT, ou=groups, o=sample.com"){
skip-spamcheck();
skip-viruscheck();
deliver();
.
1 filters added.
Note The rcpt-to-group in this message filter reflects the DN entered as the group name: cn=IT, ou=groups,
o=sample.com. Verify that you use the correct group name in the message filter to ensure that your filter
matches the name in your LDAP directory.
Messages accepted by the listener trigger a query to the LDAP server to determine group membership. If the
message recipient is a member of the IT group, the message filter skips both virus and spam checking and
delivers the message to the recipient. To enable the filter to check the results of the LDAP query, you must
create the LDAP query on the LDAP server and enable the LDAP query on a listener.
Using Domain-based Queries to Route to a Particular Domain
Domain-based queries are LDAP queries grouped by type, associated with a domain, and assigned to a
particular listener. You might want to use domain-based queries if you have different LDAP servers associated
with different domains but you want to run queries for all your LDAP servers on the same listener. For example,
the company “MyCompany” purchases company “HisCompany” and company “HerCompany” MyCompany
maintains its domain, MyCompany.example.com as well as domains for HisCompany.example.com and
HerCompany.example.com, and it maintains a different LDAP server for employees associated with each
domain. To accept mail for all three of these domains, MyCompany creates domain-based queries. This allows
MyCompany.example.com to accept emails for Mycompany.example.com, HisCompany.example.com, and
HerCompany.example.com on the same listener.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
799
LDAP Queries
Creating a Domain-Based Query
Procedure
Step 1 Create a server profile for each of the domains you want to use in the domain-based queries. For each of the
server profiles, configure the queries you want to use for a domain-based query (acceptance, routing, etc.).
For more information, see Creating LDAP Server Profiles to Store Information About the LDAP Server, on
page 778.
Step 2 Create the domain-based query. When you create the domain-based query, you select queries from each server
profile, and enable the email gateway to determine which query to run based on the domain in the Envelope
To field. For more information about creating the query, see Creating a Domain-Based Query, on page 800.
Step 3 Enable the domain-based query on the public or private listener. For more information about configuring
listeners, see the “Configuring the Gateway to Receive Mail” chapter.
Note You can also enable domain-based queries for LDAP end-user access or spam notifications for the
Spam Quarantine. For more information, see the Spam Quarantine chapter.
What to do next
Related Topics
• Creating a Domain-Based Query, on page 800
Creating a Domain-Based Query
You create a domain-based query from the System Administration > LDAP > LDAP Server Profiles page.
Procedure
Step 1 From the LDAP Server Profiles page, click Advanced.
Step 2 Click Add Domain Assignments.
Step 3 Enter a name for the domain-based query.
Step 4 Select the query type.
Note When you create domain-based queries, you cannot select different types of queries. Once you
select a query type, the email gateway populates the query field with queries of that type from the
available server profiles.
Step 5 In the Domain Assignments field, enter a domain.
Step 6 Select a query to associate with the domain.
Step 7 Continue to add rows until you have added all the domains to your query.
Step 8 You can enter a default query to run if all other queries fail. If you do not want to enter a default query, select
None.
Step 9 Test the query by clicking the Test Query button and entering a user login and passphrase or an email address
to test in the Test Parameters fields. The results appear in the Connection Status field.
Step 10 Optionally, if you use the {f} token in an acceptance query, you can add an envelope sender address to the
test query.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
800
LDAP Queries
Using Chain Queries to Perform a Series of LDAP Queries
Note Once you create the domain-based query, you need to associate it with a public or private listener.
Step 11 Submit and commit your changes.
Using Chain Queries to Perform a Series of LDAP Queries
A chain query is a series of LDAP queries that the email gateway attempts to run in succession. The email
gateway attempts to run each query in the “chain” until the LDAP server returns a positive response (or the
final query in the “chain” returns a negative response or fails). For chained routing queries, the email gateway
re-runs the same configured chain query in sequence for each rewritten email address. Chain queries can be
useful if entries in your LDAP directory use different attributes to store similar (or the same) values. For
example, you might have used the attributes maillocaladdress and mail to store user email addresses. To ensure
that your queries run against both these attributes, you can use chain queries.
Procedure
Step 1 Create server profiles for each of the queries you want to use in the chain queries. For each of the server
profiles, configure the queries you want to use for a chain query. For more information, see Creating LDAP
Server Profiles to Store Information About the LDAP Server, on page 778.
Step 2 Create the chain query. For more information, see Creating a Chain Query, on page 801.
Step 3 Enable the chain query on the public or private listener. For more information about configuring listeners,
see the “Configuring the Gateway to Receive Mail” chapter.
Note You can also enable domain-based queries for LDAP end-user access or spam notifications for the
Spam Quarantine. For more information, see the Spam Quarantine chapter.
What to do next
Related Topics
• Creating a Chain Query, on page 801
Creating a Chain Query
You create a chain query from the System Administration > LDAP > LDAP Server Profiles page.
Procedure
Step 1 From the LDAP Server Profiles page, click Advanced.
Step 2 Click Add Chain Query.
Step 3 Add a name for the chain query.
Step 4 Select the query type.
When you create chain queries, you cannot select different types of queries. Once you select a query type, the
email gateway populates the query field with queries of that type from available server profiles.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
801
LDAP Queries
Using LDAP For Directory Harvest Attack Prevention
Step 5 Select a query to add to the chain query.
The email gateway runs the queries in the order you configure them. Therefore, if you add multiple queries
to the chain query, you might want to order the queries so that more specific queries are followed by more
general queries.
Step 6 Test the query by clicking the Test Query button and entering a user login and passphrase or an email address
to test in the Test Parameters fields. The results appear in the Connection Status field.
Step 7 Optionally, if you use the {f} token in an acceptance query, you can add an envelope sender address to the
test query.
Note Once you create the chain query, you need to associate it with a public or private listener.
Step 8 Submit and commit your changes.
Using LDAP For Directory Harvest Attack Prevention
Directory Harvest Attacks occur when a malicious sender attempts to send messages to recipients with common
names, and the email gateway responds by verifying that a recipient has a valid mailbox at that location. When
performed on a large scale, malicious senders can determine who to send mail to by “harvesting” these valid
addresses for spamming.
The email gatewaycan detect and prevent Directory Harvest Attack (DHA) when using LDAP acceptance
validation queries. You can configure LDAP acceptance to prevent directory harvest attacks within the SMTP
conversation or within the work queue.
Related Topics
• Directory Harvest Attack Prevention within the SMTP Conversation, on page 802
• Directory Harvest Attack Prevention within the Work Queue, on page 803
Directory Harvest Attack Prevention within the SMTP Conversation
You can prevent DHAs by entering only domains in the Recipient Access Table (RAT), and performing the
LDAP acceptance validation in the SMTP conversation.
To drop messages during the SMTP conversation, configure an LDAP server profile for LDAP acceptance.
Then, configure the listener to perform an LDAP accept query during the SMTP conversation.
Figure 64: Configuring the Acceptance Query in the SMTP Conversation
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
802
LDAP Queries
Directory Harvest Attack Prevention within the Work Queue
Once you configure LDAP acceptance queries for the listener, you must configure DHAP settings in the mail
flow policy associated with the listener.
Figure 65: Configuring the Mail Flow Policy to Drop Connections in the SMTP Conversation
In the mail flow policy associated with the listener, configure the following Directory Harvest Attack Prevention
settings:
• Max. Invalid Recipients Per hour. The maximum number of invalid recipients per hour this listener
will receive from a remote host. This threshold represents the total number of RAT rejections combined
with the total number of messages to invalid LDAP recipients dropped in the SMTP conversation or
bounced in the work queue. For example, you configure the threshold as five, and the counter detects
two RAT rejections and three dropped messages to invalid LDAP recipients. At this point, the email
gateway determines that the threshold is reached, and the connection is dropped. By default, the maximum
number of recipients per hour for a public listener is 25. For a private listener, the maximum number of
recipients per hour is unlimited by default. Setting it to “Unlimited” means that DHAP is not enabled
for that mail flow policy.
• Drop Connection if DHAP Threshold is reached within an SMTP conversation. Configure the email
gateway to drop the connection if the Directory Harvest Attack Prevention threshold is reached.
• Max. Recipients Per Hour Code. Specify the code to use when dropping connections. The default code
is 550.
• Max. Recipients Per Hour Text. Specify the text to use for dropped connections. The default text is
“Too many invalid recipients.”
If the threshold is reached, the Envelope Sender of the message does not receive a bounce message when a
recipient is invalid.
Directory Harvest Attack Prevention within the Work Queue
You can prevent most DHAs by entering only domains in the Recipient Access Table (RAT), and performing
the LDAP acceptance validation within the work queue. This technique prevents the malicious senders from
knowing if the recipient is valid during the SMTP conversation. (When acceptance queries are configured,
the system accepts the message and performs the LDAP acceptance validation within the work queue.)
However, the Envelope Sender of the message will still receive a bounce message if a recipient is not valid.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
803
LDAP Queries
Configuring Directory Harvest Prevention in the Work Queue
Related Topics
• Configuring Directory Harvest Prevention in the Work Queue, on page 804
Configuring Directory Harvest Prevention in the Work Queue
To prevent Directory Harvest Attacks, you first configure an LDAP server profile, and enable LDAP Accept.
Once you have enabled LDAP acceptance queries, configure the listener to use the accept query, and to bounce
mail for non-matching recipients:
Next, configure the Mail Flow Policy to define the number of invalid recipient addresses the system will allow
per sending IP address for a specific period of time. When this number is exceeded, the system will identify
this condition as a DHA and send an alert message. The alert message will contain the following information:
LDAP: Potential Directory Harvest Attack from host=('IP-address', 'domain_name
'), dhap_limit=n, sender_group=sender_group,
listener=listener_name, reverse_dns=(reverse_IP_address, 'domain_name
', 1), sender=envelope_sender, rcpt=envelope_recipients
The system will bounce the messages up to the threshold you specified in the mail flow policy and then it will
silently accept and drop the rest, thereby informing legitimate senders that an address is bad, but preventing
malicious senders from determining which receipts are accepted.
This invalid recipients counter functions similarly to the way Rate Limiting is currently available in AsyncOS:
you enable the feature and define the limit as part of the mail flow policy in a public listener’s HAT (including
the default mail flow policy for the HAT).
You can also configure this in the command-line interface using the listenerconfig command.
This feature is also displayed when editing any mail flow policy in the GUI, providing that LDAP queries
have been configured on the corresponding listener:
Entering a number of invalid recipients per hour enables DHAP for that mail flow policy. By default, 25
invalid recipients per hour are allowed for public listeners. For private listeners, the maximum invalid recipients
per hour is unlimited by default. Setting it to “Unlimited” means that DHAP is not enabled for that mail flow
policy.
Configuring AsyncOS for SMTP Authentication
AsyncOS provides support for SMTP authentication. SMTP Auth is a mechanism for authenticating clients
connected to an SMTP server.
The practical use of this mechanism is that users at a given organization are able to send mail using that entity’s
mail servers even if they are connecting remotely (e.g. from home or while traveling). Mail User Agents
(MUAs) can issue an authentication request (challenge/response) when attempting to send a piece of mail.
Users can also use SMTP authentication for outgoing mail relays. This allows the email gateway to make a
secure connection to a relay server in configurations where the email gateway is not at the edge of the network.
AsyncOS supports two methods to authenticate user credentials:
• You can use an LDAP directory.
• You can use a different SMTP server (SMTP Auth forwarding and SMTP Auth outgoing).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
804
LDAP Queries
Configuring SMTP Authentication
Figure 66: SMTP Auth Support: LDAP Directory Store or SMTP Server
Configured SMTP Authentication methods are then used to create SMTP Auth profiles via the smtpauthconfig
command for use within HAT mail flow policies (see Enabling SMTP Authentication on a Listener, on page
808).
Related Topics
• Configuring SMTP Authentication, on page 805
• Configuring an SMTP Authentication Query, on page 806
• SMTP Authentication via Second SMTP Server (SMTP Auth with Forwarding), on page 807
• SMTP Authentication with LDAP, on page 807
• Authenticating SMTP Sessions Using Client Certificates, on page 811
• Outgoing SMTP Authentication, on page 811
• Logging and SMTP Authentication, on page 812
Configuring SMTP Authentication
If you are going to authenticate with an LDAP server, select the SMTPAUTH query type on the Add or Edit
LDAP Server Profile pages (or in the ldapconfig command) to create an SMTP Authentication query.
For each LDAP server you configure, you can configure a SMTPAUTH query to be used as an SMTP
Authentication profile.
There are two kinds of SMTP authentication queries: LDAP bind and passphrase as attribute. When you use
passphrase as attribute, the email gateway will fetch the passphrase field in the LDAP directory. The passphrase
may be stored in plain text, encrypted, or hashed. When you use LDAP bind, the email gateway attempts to
log into the LDAP server using the credentials supplied by the client.
Related Topics
• Specifying a Passphrase as Attribute, on page 805
Specifying a Passphrase as Attribute
The convention in OpenLDAP, based on RFC 2307, is that the type of coding is prefixed in curly braces to
the encoded passphrase (for example, “{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=”). In this example, the
passphrase portion is a base64 encoding of a plain text passphrase after application of SHA.
The email gateway negotiates the SASL mechanism with the MUA before getting the passphrase, and the
email gateway and the MUA decide on what method (LOGIN, PLAIN, MD5, SHA, SSHA, and CRYPT
SASL mechanisms are supported). Then, the appliance queries the LDAP database to fetch a passphrase. In
LDAP, the passphrase can have a prefix in braces.
• If there is no prefix, the email gateway assumes that the passphrase was stored in LDAP in plaintext.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
805
LDAP Queries
Configuring an SMTP Authentication Query
• If there is a prefix, the appliance will fetch the hashed passphrase, perform the hash on the username
and/or passphrase supplied by the MUA, and compare the hashed versions. The email gateway supports
SHA1 and MD5 hash types based on the RFC 2307 convention of prepending the hash mechanism type
to the hashed passphrase in the passphrase field.
• Some LDAP servers, like the OpenWave LDAP server, do not prefix the encrypted passphrase with the
encryption type; instead, they store the encryption type as a separate LDAP attribute. In these cases, you
can specify a default SMTP AUTH encryption method the email gateway will assume when comparing
the passphrase with the passphrase obtained in the SMTP conversation.
The email gateway takes an arbitrary username from the SMTP Auth exchange and converts that to an LDAP
query that fetches the clear or hashed passphrase field. It will then perform any necessary hashing on the
passphrase supplied in the SMTP Auth credentials and compare the results with what it has retrieved from
LDAP (with the hash type tag, if any, removed). A match means that the SMTP Auth conversation shall
proceed. A failure to match will result in an error code.
Configuring an SMTP Authentication Query
Table 72: SMTP Auth LDAP Query Fields
Name A name for the query.
Query String You can select whether to authenticate via LDAP bind or by fetching the passphrase as an attribute.
Bind: Attempt to log into the LDAP server using the credentials supplied by the client (this is called an
LDAP bind).
Specify the maximum number of concurrent connections to be used by the SMTP Auth query. This
number should not exceed the number specified in the LDAP server attributes above. Note, to avoid large
number of session time-outs for bind authentication, increase the maximum number of concurrent
connections here (typically nearly all of the connections can be assigned to SMTP Auth). A new connection
is used for each bind authentication. The remainder of the connections are shared by the other LDAP
query types.
Passphrase as Attribute: To authenticate by fetching passphrases, specify the passphrase in the SMTP
Auth passphrase attribute field below.
Specify the LDAP query to use for either kind of authentication.Active Directory example query:
(&(samaccountname={u})(objectCategory=person)(objectClass=user))
SMTP Auth Passphrase If you have selected “Authenticate by fetching the passphrase as an attribute,” you can specify the
Attribute passphrase attribute here.
In the following example, the System Administration > LDAP page is used to edit the LDAP configuration
named “PublicLDAP” to include an SMTPAUTH query. The query string ( uid={u} ) is constructed to match
against userPassword attribute.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
806
LDAP Queries
SMTP Authentication via Second SMTP Server (SMTP Auth with Forwarding)
Figure 67: SMTP Authentication Query
When an SMTPAUTH profile has been configured, you can specify that the listener uses that query for SMTP
authentication.
SMTP Authentication via Second SMTP Server (SMTP Auth with Forwarding)
You can configure the email gateway to verify the username and passphrase that have been provided to another
SMTP authenticated conversation with a different SMTP server.
The authenticating server is not the server that transfers mail; rather, it only responds to SMTP Authentication
requests. When authentication has succeeded, the SMTP transfer of mail with the dedicated mail server can
proceed. This feature is sometimes referred to as “SMTP Authentication with forwarding” because only the
credentials are forwarded (or “proxied”) to another SMTP server for authentication.
Procedure
Step 1 Choose Network > SMTP Authentication.
Step 2 Click Add Profile...
Step 3 Enter a unique name for the SMTP authentication profile.
Step 4 For the Profile Type, select Forward.
Step 5 Click Next.
Step 6 Enter the hostname/IP address and port of the forwarding server. Select a forwarding interface to use for
forwarding authentication requests. Specify the number of maximum simultaneous connections. Then, you
can configure whether TLS is required for connections from the email gateway to the forwarding server You
can also select a SASL method to use (PLAIN or LOGIN), if available. This selection is configured for each
forwarding server.
Step 7 Submit and commit your changes.
Step 8 After creating the authentication profile, you can enable the profile on a listener. See Enabling SMTP
Authentication on a Listener, on page 808 for more information.
SMTP Authentication with LDAP
To create an LDAP-based SMTP Authentication profile, you must have previously created an SMTP
Authentication query in conjunction with an LDAP server profile using the System Administration > LDAP
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
807
LDAP Queries
Enabling SMTP Authentication on a Listener
page. You can then use this profile to create an SMTP Authentication profile. For more information about
creating an LDAP profile, see Understanding LDAP Queries, on page 776.
Procedure
Step 1 Choose Network > SMTP Authentication.
Step 2 Click Add Profile.
Step 3 Enter a unique name for the SMTP authentication profile.
Step 4 For the Profile Type, select LDAP.
Step 5 Click Next.
Step 6 Select the LDAP query you would like to use for this authentication profile.
Step 7 Select a default encryption method from the drop-down menu. You can select from SHA, Salted SHA, Crypt,
Plain, or MD5. If your LDAP servers prefix an encrypted passphrase with the encryption type, leave ‘None’
selected. If your LDAP server saves the encryption type as a separate entity (OpenWave LDAP servers, for
example), then select an encryption method from the menu. The default encryption setting will not be used
if the LDAP query is using bind.
Step 8 Click Finish.
Step 9 Submit and commit your changes.
Step 10 After creating the authentication profile, you can enable the profile on a listener. See Enabling SMTP
Authentication on a Listener, on page 808 for more information.
What to do next
Related Topics
• Enabling SMTP Authentication on a Listener, on page 808
Enabling SMTP Authentication on a Listener
After using the Network > SMTP Authentication page to create an SMTP authentication “profile” that
specifies the type of SMTP authentication you want to perform (LDAP-based or SMTP forwarding-based),
you must associate that profile with a listener using the Network > Listeners page (or the listenerconfig
command).
Note An authenticated user is granted RELAY connection behavior within their current Mail Flow Policy.
You may specify more than one forwarding server in a profile. SASL mechanisms CRAM-MD5 and
DIGEST-MD5 are not supported between the email gateway and a forwarding server.
In the following example, the listener “InboundMail” is edited to use the SMTPAUTH profile configured via
the Edit Listener page:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
808
LDAP Queries
SMTP Authentication and HAT Policy Settings
Figure 68: Selecting an SMTP Authentication Profile via the Edit Listener page
Once a listener is configured to use the profile, the Host Access Table default settings can be changed so that
the listener allows, disallows, or requires SMTP Authentication:
Figure 69: Enabling SMTP Authentication on a Mail Flow Policy
Number Description
1. The SMTP Authentication field provides listener-level control for SMTP authentication. If you
select “No,” authentication will not be enabled on the listener, regardless of any other SMTP
authentication settings you configure.
2. If “Required” is selected in the second prompt (SMTP Authentication:), no AUTH keyword will
be issued until TLS is negotiated (after the client issues a second EHLO command).
Related Topics
• SMTP Authentication and HAT Policy Settings, on page 809
• HAT Delayed Rejection, on page 810
SMTP Authentication and HAT Policy Settings
Because senders are grouped into the appropriate sender group before the SMTP Authentication negotiation
begins, Host Access Table (HAT) settings, are not affected. When a remote mail host connects, the email
gateway first determines which sender group applies and imposes the Mail Policy for that sender group. For
example, if a remote MTA “suspicious.com” is in your SUSPECTLIST sender group, the THROTTLE policy
will be applied, regardless of the results of “suspicious.com’s” SMTPAUTH negotiation.
However, senders that do authenticate using SMTPAUTH are treated differently than “normal” senders. The
connection behavior for successful SMTPAUTH sessions changes to “RELAY,” effectively bypassing the
Recipient Access Table (RAT) and LDAPACCEPT. This allows the sender to relay messages through the
email gateway. As stated, any Rate Limiting or throttling that applies will remain in effect.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
809
LDAP Queries
HAT Delayed Rejection
HAT Delayed Rejection
When HAT Delayed Rejection is configured, connections that would get dropped based on the HAT Sender
Group and Mail Flow Policy configuration can still authenticate successfully and get the RELAY mail flow
policy granted.
Configure whether to perform HAT rejection at the message recipient level.By default, HAT rejected
connections will be closed with a banner message at the start of the SMTP conversation.
When an email is rejected due to HAT “Reject” settings, AsyncOS can perform the 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. For example, you can see the mail from address and each recipient address of
the message which is blocked. Delaying HAT rejections also makes it less likely that the sending MTA will
perform multiple retries.
When you enable HAT delayed rejection, the following behavior occurs:
• The MAIL FROM command is accepted, but no message object is created.
• All RCPT TO commands are rejected with text explaining that access to send e-mail is refused.
• If the sending MTA authenticates with SMTP AUTH, they are granted a RELAY policy and are allowed
to deliver mail as normal.
You can configure delayed rejection using the listenerconfig --> setup CLI command. This behavior is
disabled by default.
The following table shows how to configure delayed rejection for HAT.
example.com> listenerconfig
Currently configured listeners:
1. listener1 (on main, 172.22.138.17) QMQP TCP Port 628 Private
2. listener2 (on main, 172.22.138.17) SMTP TCP Port 25 Private
Choose the operation you want to perform:
- NEW - Create a new listener.
- EDIT - Modify a listener.
- DELETE - Remove a listener.
- SETUP - Change global settings.
[]> setup
Enter the global limit for concurrent connections to be allowed across all listeners.
[300]>
[...]
By default HAT rejected connections will be closed with a banner
message at the start of the SMTP conversation. Would you like to do the rejection at the
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
810
LDAP Queries
Authenticating SMTP Sessions Using Client Certificates
message recipient level instead for more detailed logging of rejected mail?
[N]> y
Do you want to modify the SMTP RCPT TO reject response in this case?
[N]> y
Enter the SMTP code to use in the response. 550 is the standard code.
[550]> 551
Enter your custom SMTP response. Press Enter on a blank line to finish.
Sender rejected due to local mail policy.
Contact your mail admin for assistance.
Authenticating SMTP Sessions Using Client Certificates
The email gatewaysupports the use of client certificates to authenticate SMTP sessions between the email
gateway and users’ mail clients.
When creating an SMTP authentication profile, you select the Certificate Authentication LDAP query to use
for verifying the certificate. You can also specify whether the email gateway falls back to the SMTP AUTH
command to authenticate the user if a client certificate isn’t available.
If your organization uses client certificates to authenticate users, you have the option of using the SMTP
Authentication query to check whether a user who doesn’t have a client certificate can send mail as long as
their record specifies that it’s allowed.
Outgoing SMTP Authentication
SMTP Authentication can also be used to provide validation for an outbound mail relay, using a username
and passphrase. Create an ‘outgoing’ SMTP authentication profile and then attach the profile to an SMTP
route for the ALL domain. On each mail delivery attempt, the email gateway will log on to the upstream mail
relay with the necessary credentials. SMTP authentication supports the following authorization protocols:
PLAIN and LOGIN.
Procedure
Step 1 Create an outgoing SMTP authentication profile.
a. Choose Network > SMTP Authentication.
b. Click Add Profile.
c. Enter a unique name for the SMTP authentication profile.
d. For the Profile Type, select Outgoing.
e. Click Next.
f. Enter an authentication username and passphrase for the authentication profile.
g. Click Finish.
Step 2 Configure SMTP routes to use the outgoing SMTP authentication profile that you created in Step 1.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
811
LDAP Queries
Logging and SMTP Authentication
a. Choose Network > SMTP Routes.
b. Click the All Other Domains link in the Receiving Domain column of the table.
c. Enter the name of the Destination Host for the SMTP route. This is the hostname of your external mail
relay used to deliver outgoing mail.
d. Select the outgoing SMTP authentication profile from the drop-down menu.
e. Submit and commit your changes.
Logging and SMTP Authentication
The following events will be logged in the mail logs when the SMTP Authentication mechanism (either
LDAP-based, SMTP forwarding server based, or SMTP outgoing) is configured on the email gateway:
• [Informational] Successful SMTP Authentication attempts — including the user authenticated and the
mechanism used. (No plaintext passphrases will be logged.)
• [Informational] Unsuccessful SMTP Authentication attempts — including the user authenticated and the
mechanism used.
• [Warning] Inability to connect to the authentication server — including the server name and the
mechanism.
• [Warning] A time-out event when the forwarding server (talking to an upstream, injecting email gateway)
times out while waiting for an authentication request.
Configuring External LDAP Authentication for Users
You can configure the email gateway to use an LDAP directory on your network to authenticate users by
allowing them to log in with their LDAP usernames and passphrases. After you configure the authentication
queries for the LDAP server, enable the email gateway to use external authentication on the System
Administration > Users page in the GUI (or use the userconfig command in the CLI).
Procedure
Step 1 Create a query to find user accounts. In an LDAP server profile, create a query to search for user accounts
in the LDAP directory.
Step 2 Create group membership queries. Create a query to determine if a user is a member of a directory group.
Step 3 Set up external authentication to use the LDAP server. Enable the email gateway to use the LDAP server
for user authentication and assign user roles to the groups in the LDAP directory. For more information, see
“Adding Users” in the “Distributing Administrative Tasks” chapter.
Note Use the Test Query button on the LDAP page (or the ldaptest command) to verify that your
queries return the expected results. For more information, see Testing LDAP Queries, on page 790.
What to do next
Related Topics
• User Accounts Query, on page 813
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
812
LDAP Queries
User Accounts Query
• Group Membership Queries, on page 813
User Accounts Query
To authenticate external users, AsyncOS uses a query to search for the user record in the LDAP directory and
the attribute that contains the user’s full name. Depending on the server type you select, AsyncOS enters a
default query and a default attribute. You can choose to have your email gateway deny users with expired
accounts if you have attributes defined in RFC 2307 in your LDAP user records ( shadowLastChange ,
shadowMax , and shadowExpire ). The base DN is required for the domain level where user records reside.
The following table shows the default query string and full username attribute that AsyncOS uses when it
searches for a user account on an Active Directory server.
Table 73: Default User Account Query String and Attribute: Active Directory
Server Type Active Directory
Base DN [blank] (You need to use a specific base DN to find the user
records.)
Query String (&(objectClass=user)(sAMAccountName={u}))
Attribute containing the user’s full name displayName
The following table shows the default query string and full username attribute that AsyncOS uses when it
searches for a user account on an OpenLDAP server.
Table 74: Default User Account Query String and Attribute: OpenLDAP
Server Type OpenLDAP
Base DN [blank] (You need to use a specific base DN to find the user
records.)
Query String (&(objectClass=posixAccount)(uid={u}))
Attribute containing the user’s full name gecos
Group Membership Queries
AsyncOS also uses a query to determine if a user is a member of a directory group. Membership in a directory
group membership determines the user’s permissions within the system. When you enable external
authentication on the System Administration > Users page in the GUI (or userconfig in the CLI), you assign
user roles to the groups in your LDAP directory. User roles determine the permissions that users have in the
system, and for externally authenticated users, the roles are assigned to directory groups instead of individual
users. For example, you can assign users in the IT directory group the Administrator role and users in the
Support directory group to the Help Desk User role.
If a user belongs to multiple LDAP groups with different user roles, AsyncOS grants the user the permissions
for the most restrictive role. For example, if a user belongs to a group with Operator permissions and a group
with Help Desk User permissions, AsyncOS grants the user the permissions for the Help Desk User role.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
813
LDAP Queries
Group Membership Queries
When you configure the LDAP profile to query for group membership, enter the base DN for the directory
level where group records can be found, the attribute that holds the group member’s username, and the attribute
that contains the group name. Based on the server type that you select for your LDAP server profile, AysncOS
enters default values for the username and group name attributes, as well default query strings.
Note For Active Directory servers, the default query string to determine if a user is a member of a group is
(&(objectClass=group)(member={u})) . However, if your LDAP schema uses distinguished names in the
“memberof” list instead of usernames, you can use {dn} instead of {u} .
The following table shows the default query strings and attributes that AsyncOS uses when it searches for
group membership information on an Active Directory server.
Table 75: Default Group Membership Query Strings and Attribute: Active Directory
Server Type Active Directory
Base DN [blank] (You need to use a specific base DN to find the group
records.)
Query string to determine if a user is a (&(objectClass=group)(member={u}))
member of a group
Note If your LDAP schema uses distinguished names in
the memberOf list instead of usernames, you can
replace {u} with {dn} .
Attribute that holds each member's member
username (or a DN for the user's record)
Attribute that contains the group name cn
The following table shows the default query strings and attributes that AsyncOS uses when it searches for
group membership information on an OpenLDAP server.
Table 76: Default Group Membership Query Strings and Attributes: OpenLDAP
Server Type OpenLDAP
Base DN [blank] (You need to use a specific base DN to find the group
records.)
Query string to determine if a user is a (&(objectClass=posixGroup)(memberUid={u}))
member of a group
Attribute that holds each member's memberUid
username (or a DN for the user's record)
Attribute that contains the group name cn
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
814
LDAP Queries
Authenticating End-Users of the Spam Quarantine
Authenticating End-Users of the Spam Quarantine
Spam quarantine end-user authentication queries validate users when they log in to the Spam Quarantine. The
token {u} specifies the user (it represents the user’s login name). The token {a} specifies the user’s email
address. The LDAP query does not strip "SMTP:" from the email address; AsyncOS strips that portion of the
address.
If you want the Spam Quarantine to use an LDAP query for end-user access, check the “Designate as the
active query” check box. If there is an existing active query, it is disabled. When you open the System
Administration > LDAP page, an asterisk (*) is displayed next to the active queries.
Based on the server type, AsyncOS uses one of the following default query strings for the end-user
authentication query:
• Active Directory: (sAMAccountName={u})
• OpenLDAP: (uid={u})
• Unknown or Other: [Blank]
By default, the primary email attribute is proxyAddresses for Active Directory servers and mail for OpenLDAP
servers. You can enter your own query and email attributes. To create the query from the CLI, use the isqauth
subcommand of the ldapconfig command.
Note If you want users to log in with their full email address, use (mail=smtp:{a}) for the Query String.
Related Topics
• Sample Active Directory End-User Authentication Settings, on page 815
• Sample OpenLDAP Alias Consolidation Settings, on page 817
• Configuring End-User Access to the Spam Quarantine , on page 966
Sample Active Directory End-User Authentication Settings
This section shows sample settings for an Active Directory server and the end-user authentication query. This
example uses passphrase authentication for the Active Directory server, the mail and proxyAddresses email
attributes, and the default query string for end-user authentication for Active Directory servers.
Table 77: Example LDAP Server and Spam Quarantine End-User Authentication Settings: Active Directory
Authentication Method Use Passphrase (Need to create a low-privilege user to bind for searching,
or configure anonymous searching.)
Server Type Active Directory
Port 3268
Base DN [Blank]
Connection Protocol [Blank]
Query String (sAMAccountName={u})
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
815
LDAP Queries
Sample OpenLDAP End-User Authentication Settings
Authentication Method Use Passphrase (Need to create a low-privilege user to bind for searching,
or configure anonymous searching.)
Email Attribute(s) mail,proxyAddresses
Sample OpenLDAP End-User Authentication Settings
This section shows sample settings for an OpenLDAP server and the end-user authentication query. This
example uses anonymous authentication for the OpenLDAP server, the mail and mailLocalAddress email
attributes, and the default query string for end-user authentication for OpenLDAP servers.
Table 78: Example LDAP Server and Spam Quarantine End-User Authentication Settings: OpenLDAP
Authentication Method Anonymous
Server Type OpenLDAP
Port 389
Base DN [Blank] (Some older schemas will want to use a specific Base DN.)
Connection Protocol [Blank]
Query String (uid={u})
Email Attribute(s) mail,mailLocalAddress
Spam Quarantine Alias Consolidation Queries
If you use spam notifications, the spam quarantine alias consolidation query consolidates the email aliases so
that recipients do not receive quarantine notices for each alias. For example, a recipient might receive mail
for the following email addresses: [email protected], [email protected], and [email protected].
When you use alias consolidation, the recipient receives a single spam notification at a chosen primary email
address for messages sent to all of the user’s aliases.
To consolidate messages to a primary email address, create a query to search for a recipient’s alternate email
aliases, and then enter the attribute for the recipient’s primary email address in the Email Attribute field.
If you want the Spam Quarantine to use an LDAP query for spam notifications, check the “Designate as the
active query” check box. If there is an existing active query, it is disabled. When you open the System
Administration > LDAP page, an asterisk (*) is displayed next to the active queries.
For Active Directory servers, the default query string is (|(proxyAddresses={a})(proxyAddresses=smtp:{a}))
and the default email attribute is mail . For OpenLDAP servers, the default query string is (mail={a}) and the
default email attribute is mail . You can define your own query and email attributes, including multiple
attributes separated by commas. If you enter more than one email attribute, Cisco recommends entering a
unique attribute that uses a single value, such as mail , as the first email attribute instead of an attribute with
multiple values that can change, such as proxyAddresses .
To create the query in the CLI, use the isqalias subcommand of the ldapconfig command.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
816
LDAP Queries
Sample Active Directory Alias Consolidation Settings
Related Topics
• Sample Active Directory Alias Consolidation Settings, on page 817
• Sample OpenLDAP Alias Consolidation Settings, on page 817
Sample Active Directory Alias Consolidation Settings
This section shows sample settings for an Active Directory server and the alias consolidation query. This
example uses anonymous authentication for the Active Directory server, a query string for alias consolidation
for Active Directory servers, and the mail email attribute.
Table 79: Example LDAP Server and Spam Quarantine Alias Consolidation Settings: Active Directory
Authentication Method Anonymous
Server Type Active Directory
Port 3268
Base DN [Blank]
Connection Protocol Use SSL
Query String
(
|(mail={a})(mail=smtp:{a})
)
Email Attribute mail
Note This example is for representational purposes only. Queries and OU or tree settings may vary depending on
the environment and configuration.
Sample OpenLDAP Alias Consolidation Settings
This section shows sample settings for an OpenLDAP server and the alias consolidation query. This example
uses anonymous authentication for the OpenLDAP server, a query string for alias consolidation for OpenLDAP
servers, and the mail email attribute.
Table 80: Example LDAP Server and Spam Quarantine Alias Consolidation Settings: OpenLDAP
Authentication Method Anonymous
Server Type OpenLDAP
Port 389
Base DN [Blank] (Some older schemas will want to use a specific Base DN.)
Connection Protocol Use SSL
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
817
LDAP Queries
Sample User Distinguished Name Settings
Authentication Method Anonymous
Query String (mail={a})
Email Attribute mail
Note This example is for representational purposes only. Queries and OU or tree settings may vary depending on
the environment and configuration.
Sample User Distinguished Name Settings
This section shows sample settings for an Active Directory server and the user distinguished name query.
This example uses anonymous authentication for the Active Directory server and a query string for user
distinguished name retrieval for Active Directory servers.
Table 81: Example LDAP Server and Spam Quarantine Alias Consolidation Settings: Active Directory
Authentication Method Anonymous
Server Type Active Directory
Port 3268
Base DN [Blank]
Connection Protocol Use SSL
Query String
(proxyAddresses=smtp:{a})
Note This example is for representational purposes only. Queries and OU or tree settings may vary depending on
the environment and configuration.
Configuring AsyncOS To Work With Multiple LDAP Servers
When you configure an LDAP profile, you can configure the email gateway to connect to a list of multiple
LDAP servers. To use multiple LDAP servers, you must configure LDAP servers to contain the same
information, use the same structure, and use the same authentication information. (third party products exist
that can consolidate the records).
When you configure the email gateway to connect to redundant LDAP servers, you can configure the LDAP
configuration for failover or load balancing.
You can use multiple LDAP servers to achieve the following results:
• Failover. When you configure the LDAP profile for failover, the email gateway fails over to the next
LDAP server in the list if it cannot connect to the first LDAP server.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
818
LDAP Queries
Testing Servers and Queries
• Load Balancing. When you configure the LDAP profile for load balancing, the email gateway distributes
connections across the list of LDAP servers when it performs LDAP queries.
You can configure redundant LDAP servers from the System Administration > LDAP page or from the CLI
ldapconfig command.
Testing Servers and Queries
Use the Test Server(s) button on the Add (or Edit) LDAP Server Profile page (or the test subcommand in
the CLI) to test the connection to an LDAP server. If you use multiple LDAP servers, AsyncOS tests each
server and displays individual results for each server. AsyncOS will also test the query on each LDAP server
and display the individual results.
Related Topics
• Failover, on page 819
• Load Balancing, on page 820
Failover
To ensure that LDAP queries are resolved, you can configure your LDAP profile for failover. If the connection
to the LDAP server fails, or the query returns certain error codes (for example, Unavailable or Busy), the
email gateway attempts to query the next LDAP server specified in the list.
The email gateway attempts to connect to the first server in the list of LDAP servers for a specified period of
time. If the email gateway cannot connect to the first LDAP server in the list, or the query returns certain error
codes (for example, Unavailable or Busy), the email gateway attempts to connect to the next LDAP server in
the list. By default, the email gateway always attempts to connect to the first server in the list, and it attempts
to connect to each subsequent server in the order they are listed. To ensure that the email gateway connects
to your primary LDAP server by default, ensure that you enter it as the first server in your list of LDAP servers.
If the email gateway connects to a second or subsequent LDAP server, it remains connected to that server
until it reaches a timeout period. After it reaches the timeout, it attempts to reconnect to the first server in the
list.
Note Only attempts to query a specified LDAP server fail over. Attempts to query referral or continuation servers
associated with the specified LDAP server do not fail over.
Related Topics
• Configuring the Email Gateway for LDAP Failover, on page 819
Configuring the Email Gateway for LDAP Failover
To configure the email gateway for LDAP failover, complete the following steps in the GUI:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
819
LDAP Queries
Load Balancing
Procedure
Step 1 From System Administration > LDAP, select the LDAP server profile you want to edit.
Step 2 From the LDAP server profile, configure the following settings:
Number Description
1 List LDAP Servers.
2 Configure Maximum Connections.
Step 3 Configure other LDAP settings and commit the changes.
Load Balancing
To distribute LDAP connections among a group of LDAP servers, you can configure your LDAP profile for
load balancing.
When you configure your LDAP profile for load balancing, the email gateway distributes connections among
the LDAP servers listed. If a connection fails or times out, the email gateway determines which LDAP servers
are available and reconnects to available servers. The email gateway determines the number of simultaneous
connections to establish based on the maximum number of connections you configure.
If one of the listed LDAP servers does not respond, the email gateway distributes the connection load among
the remaining LDAP servers.
Reliance Topics
• Configuring the Email Gateway for Load Balancing, on page 820
Configuring the Email Gateway for Load Balancing
Procedure
Step 1 From System Administration > LDAP, select the LDAP server profile you want to edit.
Step 2 From the LDAP server profile, configure the following settings:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
820
LDAP Queries
Configuring the Email Gateway for Load Balancing
Number Description
1 List LDAP Servers
2 Configure Maximum Connections
Step 3 Configure other LDAP settings and commit the changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
821
LDAP Queries
Configuring the Email Gateway for Load Balancing
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
822
CHAPTER 33
Authenticating SMTP Sessions Using Client
Certificates
This chapter contains the following sections:
• Overview of Certificates and SMTP Authentication, on page 823
• Checking the Validity of a Client Certificate, on page 825
• Authenticating a User Using an LDAP Directory, on page 826
• Authenticating an SMTP Connection Over TLS Using a Client Certificate, on page 827
• Establishing a TLS Connection from the Email Gateway, on page 827
• Updating a List of Revoked Certificates, on page 828
Overview of Certificates and SMTP Authentication
The email gateway supports the use of client certificates to authenticate SMTP sessions between the email
gateway and users’ mail clients. The email gateway can request a client certificate from a user’s mail client
when the application attempts to connect to the email gateway to send messages. When the email gateway
receives the client certificate, it verifies that the certificate is valid, has not expired, and has not been revoked.
If the certificate is valid, the email gateway allows an SMTP connection from the mail application over TLS.
Organizations that require their users to use a Common Access Card (CAC) for their mail clients can use this
feature to configure the email gateway to request a certificate that the CAC and ActivClient middleware
application will provide to the email gateway.
You can configure the email gateway to require users to provide a certificate when sending mail, but still
allow exceptions for certain users. For these users, you can configure the email gateway to use the SMTP
authentication LDAP query to authenticate the user.
Users must configure their mail client to send messages through a secure connection (TLS) and accept a server
certificate from the email gateway.
Related Topics
• How to Authenticate a User with a Client Certificate, on page 824
• How to Authenticate a User with an SMTP Authentication LDAP Query, on page 824
• How to Authenticate a User with an LDAP SMTP Authentication Query if the Client Certificate is Invalid,
on page 825
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
823
Authenticating SMTP Sessions Using Client Certificates
How to Authenticate a User with a Client Certificate
How to Authenticate a User with a Client Certificate
Table 82: How to Authenticate a User with a Client Certificate
Do This More Info
Step 1 Define a certificate query for your LDAP server. Checking the Validity of a Client
Certificate, on page 825
Step 2 Create a certificate-based SMTP authentication profile. Authenticating an SMTP Connection Over
TLS Using a Client Certificate, on page 827
Step 3 Configure a listener to use the certificate SMTP authentication profile. Listening for Connection Requests by
Creating a Listener Using Web Interface,
on page 83
Step 4 Modify the RELAYED mail flow policy to require TLS, a client Establishing a TLS Connection from the
certificate, and SMTP authentication. Email Gateway, on page 827
How to Authenticate a User with an SMTP Authentication LDAP Query
Table 83: How to Authenticate a User with an SMTP Authenticate LDAP Query
Do This More Info
Step 1 Define an SMTP authentication query for your server that Authenticating a User Using an LDAP Directory, on
uses an allowance query string and Bind for the page 826
authentication method.
Step 2 Create an LDAP-based SMTP authentication profile. Configuring AsyncOS for SMTP Authentication, on
page 804
Step 3 Configure a listener to use the LDAP SMTP If the user is not allowed to use LDAP-based SMTP
authentication profile. authentication for their connection, you can select
whether the email gateway rejects the connection or
temporarily allows it while logging all activity.
Step 4 Modify the RELAYED mail flow policy to require TLS Establishing a TLS Connection from the Email
and SMTP authentication. Gateway, on page 827
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
824
Authenticating SMTP Sessions Using Client Certificates
How to Authenticate a User with an LDAP SMTP Authentication Query if the Client Certificate is Invalid
How to Authenticate a User with an LDAP SMTP Authentication Query if the
Client Certificate is Invalid
Table 84: How to Authenticate a User with a Client Certificate or an LDAP SMTP Authentication Query
Do This More Info
Step 1 Define an SMTP authentication query for your server that Authenticating a User Using an LDAP Directory, on
uses an allowance query string and Bind for the page 826
authentication method.
Step 2 Define a certificate-based query for your LDAP server. Checking the Validity of a Client Certificate, on page
825
Step 3 Create a certificate-based SMTP authentication profile Authenticating an SMTP Connection Over TLS Using
a Client Certificate, on page 827
Step 4 Create an LDAP SMTP authentication profile. Configuring AsyncOS for SMTP Authentication, on page
804
Step 5 Configure a listener to use the certificate SMTP Listening for Connection Requests by Creating a Listener
authentication profile. Using Web Interface, on page 83
Step 6 1. Modify the RELAYED mail flow policy to use the Establishing a TLS Connection from the Email Gateway,
following settings: on page 827
2. TLS Preferred
3. SMTP authentication required
4. Require TLS for SMTP authentication
Checking the Validity of a Client Certificate
The Certificate Authentication LDAP query checks the validity of a client certificate in order to authenticate
an SMTP session between the user’s mail client and the email gateway. When creating this query, you select
a list of certificate fields for authentication, specify the User ID attribute (the default is uid ), and enter the
query string.
For example, a query string that searches for the certificate’s common name and serial number may look like
(&(objectClass-posixAccount)(caccn={cn})(cacserial={sn}). After you have created
the query, you can use it in a Certificate SMTP Authentication Profile. This LDAP query supports OpenLDAP,
Active Directory, and Oracle Directory.
See LDAP Queries, on page 775 for more information on configuring LDAP servers.
Procedure
Step 1 Select System Administration > LDAP.
Step 2 Create a new LDAP profile. See Creating LDAP Server Profiles to Store Information About the LDAP Server,
on page 778 for more information.
Step 3 Check the Certificate Authentication Query checkbox.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
825
Authenticating SMTP Sessions Using Client Certificates
Authenticating a User Using an LDAP Directory
Step 4 Enter the query name.
Step 5 Enter the query string to authenticate the user’s certificate. For example,
(&(objectClass=user)(cn={cn})) .
Step 6 Enter the user ID attribute, such as sAMAccountName .
Step 7 Submit and commit your changes.
Authenticating a User Using an LDAP Directory
The SMTP Authentication LDAP query has an Allowance Query String that allows the email gateway to
check whether the user’s mail client is allowed to send mail through the email gateway based on the user’s
record in the LDAP directory. This allows users who don’t have a client certificate to send mail as long as
their record specifies that it’s allowed.
You can also filter out results based on other attributes. For example, the query string
(&(uid={u})(|(!(caccn=*))(cacexempt=*)(cacemergency>={t}))) checks to see if any of the following
conditions are true for the user:
• CAC is not issued to the user ( caccn=* )
• CAC is exempt ( cacexempt=* )
• the time period that a user may temporarily send mail without a CAC expires in the future (
cacemergency>={t} )
See Configuring AsyncOS for SMTP Authentication, on page 804for more information on using the SMTP
Authentication query.
Procedure
Step 1 Select System Administration > LDAP.
Step 2 Define an LDAP profile. See Creating LDAP Server Profiles to Store Information About the LDAP Server,
on page 778 for more information.
Step 3 Define an SMTP authentication query for the LDAP profile.
Step 4 Check the SMTP Authentication Query checkbox.
Step 5 Enter the query name.
Step 6 Enter the string to query for the user’s ID. For example, (uid={u}).
Step 7 Select LDAP BIND for the authentication method.
Step 8 Enter an allowance query string. For example,
(&(uid={u})(|(!(caccn=*))(cacexempt=*)(cacemergency>={t}))) .
Step 9 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
826
Authenticating SMTP Sessions Using Client Certificates
Authenticating an SMTP Connection Over TLS Using a Client Certificate
Authenticating an SMTP Connection Over TLS Using a Client
Certificate
The certificate-based SMTP authentication profile allows the email gateway to authenticate an SMTP connection
over TLS using a client certificate. When creating the profile, you select the Certificate Authentication LDAP
query to use for verifying the certificate. You can also specify whether the email gateway falls back to the
SMTP AUTH command to authenticate the user if a client certificate is not available.
For information on authenticating an SMTP connection by using LDAP, see Configuring AsyncOS for SMTP
Authentication, on page 804.
Procedure
Step 1 Select Network > SMTP Authentication.
Step 2 Click Add Profile.
Step 3 Enter the name for the SMTP authentication profile.
Step 4 Select Certificate for the Profile Type.
Step 5 Click Next.
Step 6 Enter the profile name.
Step 7 Select the certificate LDAP query you want to use with this SMTP authentication profile.
Note Do not select the option to allow the SMTP AUTH command if a client certificate is not available.
Step 8 Click Finish.
Step 9 Submit and commit your changes.
Establishing a TLS Connection from the Email Gateway
The Verify Client Certificate option in the RELAYED mail flow policy directs the email gateway to establish
a TLS connection to the user’s mail application if the client certificate is valid. If you select this option for
the TLS Preferred setting, the email gateway still allows a non-TLS connection if the user doesn’t have a
certificate, but rejects a connection if the user has an invalid certificate. For the TLS Required setting, selecting
this option requires the user to have a valid certificate in order for the email gateway to allow the connection.
To authenticate a user’s SMTP session with a client certificate, select the following settings:
• TLS - Required
• Verify Client Certificate
• Require SMTP Authentication
Note Although SMTP authentication is required, the email gateway will not use the SMTP authentication LDAP
query because it is using certificate authentication.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
827
Authenticating SMTP Sessions Using Client Certificates
Updating a List of Revoked Certificates
To authenticate a user’s SMTP session using the SMTP authentication query instead of a client certificate,
select the following settings for the RELAYED mail flow policy:
• TLS - Required
• Require SMTP Authentication
If you require the email gateway to ask for a client certificate from certain users while allowing LDAP-based
SMTP authentication from others, select the following settings for the RELAYED mail flow policy:
• TLS - Preferred
• Require SMTP Authentication
• Require TLS to Offer SMTP Authentication
Updating a List of Revoked Certificates
The Email Security appliance checks a list of revoked certificates (called a Certificate Revocation List) as
part of its certificate verification to make sure that the user’s certificate hasn’t been revoked. You keep an
up-to-date version of this list on a server and the email gateway downloads it on a schedule that you create.
Procedure
Step 1 Go to Network > CRL Sources.
Step 2 Enable CRL checking for SMTP TLS connections:
a) Click Edit Settings under Global Settings.
b) (Optional) Select the Global Settings checkbox if you want to select all options:
• CRL check for inbound SMTP TLS.
• CRL check for outbound SMTP TLS
• CRL Check for Web Interface
c) Select the checkbox for either ‘CRL check for inbound SMTP TLS’, ‘CRL check for outbound SMTP
TLS’ or ‘CRL Check for Web Interface’ options.
d) Submit your change.
Step 3 Click Add CRL Source.
Step 4 Enter a name for the CRL source.
Step 5 Select the file type. This can be either ASN.1 or PEM.
Step 6 Enter the URL for the primary source for the file, including the filename. For example,
https://crl.example.com/certs.crl
Step 7 Optionally, enter the URL for a secondary source in case the email gateway cannot contact the primary source.
Step 8 Specify a schedule for downloading the CRL source.
Step 9 Enable the CRL source.
Step 10 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
828
Authenticating SMTP Sessions Using Client Certificates
Authenticating a User’s SMTP Session With a Client Certificate
Authenticating a User’s SMTP Session With a Client Certificate
Procedure
Step 1 Go to System Administration > LDAP to configure an LDAP server profile.s
Step 2 Define a certificate query for the LDAP profile.
a) Enter the query name.
b) Choose the certificate fields to authenticate, such as the serial number and common name.
c) Enter the query string. For example, (&(caccn={cn})(cacserial={sn})).
d) Enter the user ID field, such as uid.
e) Submit your changes.
Step 3 Go to Network > SMTP Authentication to configure a Certificate SMTP authentication profile.
a) Enter the profile name.
b) Select the certificate LDAP query you want to use.
c) Do not select the option to allow the SMTP AUTH command if a client certificate is not available.
d) Submit your changes.
Step 4 Go to Network > Listeners to configure a listener to use the certificate SMTP authentication profile that you
created.
Step 5 Modify the RELAYED mail flow policy to require TLS and a client certificate, as well as require SMTP
authentication.
Note Although SMTP authentication is required, the email gateway will not use the SMTP AUTH
command because it is using certificate authentication. The email gatewaywill require a client
certificate from the mail application to authenticate the user.
Step 6 Submit and commit your changes.
Authenticating a User’s SMTP Session with the SMTP AUTH Command
The email gateway can use the SMTP AUTH command to authenticate a user’s SMTP session instead of a
client certificate. If you user is not allowed to use SMTP AUTH for their connection, you can select whether
the email gateway rejects the connection or temporarily allows it while logging all activity.
Procedure
Step 1 Go to System Administration > LDAP to configure an LDAP server profile.
Step 2 Define an SMTP authentication query for the LDAP profile.
a) Enter the query name.
b) Enter the query string. For example, (uid={u}).
c) Select LDAP Bind for the authentication method.
d) Enter an allowance query string. For example,
(&(uid={u})(|(!(caccn=*))(cacexempt=*)(cacemergency>={t}))) .
e) Submit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
829
Authenticating SMTP Sessions Using Client Certificates
Authenticating a User’s SMTP Session with Either a Client Certificate or SMTP AUTH
Step 3 Go to Network > SMTP Authentication to configure an LDAP SMTP authentication profile.
a) Enter the profile name.
b) Select the SMTP authentication LDAP query you want to use.
c) Select the Check with LDAP if user is allowed to use SMTP AUTH Command and choose to monitor
and report the user’s activity.
d) Submit your changes.
Step 4 Go to Network > Listeners to configure a listener to use the LDAP SMTP authentication profile that you
created.
Step 5 Modify the RELAYED mail flow policy to require TLS and SMTP authentication.
Step 6 Submit and commit your changes.
Authenticating a User’s SMTP Session with Either a Client Certificate or SMTP
AUTH
This configuration requires the email gateway to ask for a client certificate from users with a client certificate
while allowing SMTP AUTH for users without one, or who cannot use one for sending email.
Any attempt to use the SMTP AUTH command by a user who is not allowed will be prohibited.
Procedure
Step 1 Go to System Administration > LDAP to configure an LDAP server profile.
Step 2 Define an SMTP authentication query for the profile.
a) Enter the query name.
b) Enter the query string. For example, (uid={u}).
c) Select LDAP Bind for the authentication method.
d) Enter an allowance query string. For example,
(&(uid={u})(|(!(caccn=*))(cacexempt=*)(cacemergency>={t}))) .
Step 3 Define a certificate query for the LDAP profile.
a) Enter the query name.
b) Choose the client certificate fields to authenticate, such as the serial number and common name.
c) Enter the query string. For example, (&(caccn={cn})(cacserial={sn})).
d) Enter the user ID field, such as uid .
e) Submit your changes.
Step 4 Go to Network > SMTP Authentication to configure an LDAP SMTP authentication profile.
a) Enter the profile name.
b) Select the SMTP authentication LDAP query you want to use.
c) Select the Check with LDAP if user is allowed to use SMTP AUTH Command and choose to reject the
connection.
d) Enter a custom SMTP AUTH response. For example, 525, “Dear user, please use your CAC to send
email.”
e) Submit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
830
Authenticating SMTP Sessions Using Client Certificates
Authenticating a User’s SMTP Session with Either a Client Certificate or SMTP AUTH
Step 5 Configure a Certificate SMTP authentication profile.
a) Enter the profile name.
b) Select the certificate LDAP query you want to use.
c) Select the option to allow the SMTP AUTH command if a client certificate is not available.
d) Select your LDAP SMTP authentication profile for the email gateway to use if the user does not have a
client certificate.
e) Submit your changes.
Step 6 Go to Network > Listeners to configure a listener to use the certificate SMTP authentication profile you
created.
Step 7 Modify the RELAYED mail flow policy to select the following options:
• TLS Preferred
• SMTP authentication required
• Require TLS for SMTP Authentication
Step 8 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
831
Authenticating SMTP Sessions Using Client Certificates
Authenticating a User’s SMTP Session with Either a Client Certificate or SMTP AUTH
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
832
CHAPTER 34
Using Email Security Monitor
This chapter contains the following sections:
• Email Security Monitor Overview, on page 833
• Email Security Monitor Pages, on page 834
• Email Security Monitor Pages on the New Web Interface, on page 867
• Reporting Overview, on page 908
• Managing Reports, on page 909
• Troubleshooting Email Reports, on page 912
Email Security Monitor Overview
The Email Security Monitor feature collects data from every step in the email delivery process. The database
identifies and records each email sender by IP address, while interfacing with the IP Reputation Service for
real-time identity information. You can instantly report on any email sender’s local mail flow history and
show a profile that includes the sender’s global record on the Internet. The Email Security Monitor feature
allows your security team to “close the loop” on who is sending mail to your users, the amount of mail sent
from and received by your users, and the effectiveness of your security policies.
This chapter explains how to:
• Access the Email Security Monitor feature to monitor inbound and outbound message flow.
• Make mail flow policy decisions (update allowed lists, blocked lists, and greylists) by querying for a
sender’s IP Reputation Score. You can query on network owners, domains, and even individual IP
addresses.
• Report on mail flow, system status, and mail sent to and from your network.
For any given email sender for incoming mail, the Email Security Monitor database captures critical parameters
such as:
• Message volume
• Connection history
• Accepted vs. rejected connections
• Acceptance rates and throttle limits
• Sender reputation filter matches
• Number of anti-spam messages for suspected spam and positively identified spam
• Number of virus-positive message detected by anti-virus scanning
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
833
Using Email Security Monitor
Email Security Monitor and Centralized Management
See Managing Spam and Graymail, on page 383 for more information on Anti-Spam scanning and Anti-Virus,
on page 365 for more information on anti-virus scanning.
The Email Security Monitor feature also captures information on which content filter a particular message
triggers, including the internal user (email recipient) to or from which the message was sent.
The Email Security Monitor feature is available in the GUI only, and provides a view into your email traffic
and the status of your email gateway (including quarantines, work queues, and outbreaks). The email gateway
identifies when a sender falls outside of the normal traffic profile. Senders that do are highlighted in the
interface, allowing you to take corrective action by assigning that sender to a sender group or refining the
access profile of the sender; or, you can let AsyncOS’s security services continue to react and respond.
Outbound mail has a similar monitoring capability, providing you a view into the top domains in the mail
queue and the status of receiving hosts (see Delivery Status Details Page, on page 849).
Note Information for messages present in the work queue when the email gateway is rebooted is not reported by
the Email Security Monitor feature.
Related Topics
• Email Security Monitor and Centralized Management, on page 834
Email Security Monitor and Centralized Management
To view aggregated report data, deploy a Cisco Secure Email and Web Manager.
You cannot aggregate Email Security Monitor reports of clustered appliances. All reports are restricted to
machine level. This means they cannot be run at the group or cluster levels — only on individual machines.
The same is true of the Archived Reports page — each machine in effect has its own archive. Thus, the
“Generate Report” feature runs on the selected machine.
The Scheduled Reports page is not restricted to machine level; therefore, settings can be shared across multiple
machines. Individual scheduled reports run at machine level just like interactive reports, so if you configure
your scheduled reports at cluster level, every machine in the cluster will send its own report.
The “Preview This Report” button always runs against the login-host.
Email Security Monitor Pages
The Email Security Monitor feature is comprised of all the pages available on the Monitor menu except the
Quarantines pages.
You use these pages in the GUI to monitor domains that are connecting to the appliance’s listeners. You can
monitor, sort, analyze, and classify the “mail flow” of your email gateway and differentiate between
high-volume senders of legitimate mail and potential “spammers” (senders of high-volume, unsolicited
commercial email) or virus senders. These pages can also help you troubleshoot inbound connections to the
system (including important information such as IP Reputation score and most recent sender group match for
domains).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
834
Using Email Security Monitor
Email Security Monitor Pages
These pages help you classify mail relative to the email gateway, and also relative to the services that exist
beyond the scope of the gateway, such as the IP Reputation Service, the Anti-Spam scanning service, the
Anti-Virus scanning security services, content filters, and Outbreak Filters.
You can generate a printer-friendly formatted .PDF version of any of the Email Security Monitor pages by
clicking on the Printable PDF link at the top-right of the page. For information about generating PDFs in
languages other than English, see the Notes on Reports, on page 909.
You can export graphs and other data to CSV (comma separated values) format via the Export link.
The exported CSV data will display all message tracking and reporting data in GMT regardless of what is set
on the email gateway. The purpose of the GMT time conversion is to allow data to be used independently
from the email gateway or when referencing data from appliances in multiple time zones.
Note If you export localized CSV data, the headings may not render properly in some browsers. This occurs because
some browsers may not use the correct character set for the localized text. To work around this problem, you
can save the file to disk, and open the file using File > Open. When you open the file, select the character set
to display the localized text.
For more information about automating the export of report data, see Retrieving CSV Data, on page 865).
List of Email Security Monitor Pages
• My Dashboard Page , on page 837
• Overview Page, on page 838
• Incoming Mail Page, on page 841
• Outgoing Destinations, on page 847
• Outgoing Senders, on page 847
• Delivery Status Page, on page 848
• Internal Users Page, on page 849
• DLP Incidents Page, on page 850
• Content Filters Page, on page 851
• DMARC Verification Page, on page 852
• Outbreak Filters Page, on page 853
• Virus Types Page, on page 855
• URL Filtering Page , on page 855
• Web Interaction Tracking Page, on page 856
• File Reputation and File Analysis Reports, on page 857
• TLS Connections Page, on page 857
• Inbound SMTP Authentication Page, on page 858
• Rate Limits Page , on page 859
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
835
Using Email Security Monitor
Searching and Email Security Monitor
• System Capacity Page, on page 859
• System Status Page, on page 862
• High Volume Mail Page, on page 864
• Message Filters Page, on page 864
• Geo Distribution Page , on page 848
• Safe Print Page , on page 865
Searching and Email Security Monitor
Many of the Email Security Monitor pages include a search form. You can search for different types of items:
• IP Address (IPv4 and IPv6)
• domain
• network owner
• internal users
• destination domain
• internal sender domain
• internal sender IP address
• outgoing domain deliver status
For domain, network owner, and internal user searches, choose whether to exactly match the search text or
look for items starting with the entered text (for instance, starts with “ex” will match “example.com”).
For IPv4 address searches, the entered text is always interpreted as the beginning of up to four IP octets in
dotted decimal format. For instance, “17” will search in the range 17.0.0.0 through 17.255.255.255, so it will
match 17.0.0.1 but not 172.0.0.1. For an exact match search, simply enter all four octets. IP address searches
also support CIDR format (17.16.0.0/12).
For IPv6 address searches, AsyncOS supports the following formats:
• 2001:db8:2004:4202::0-2001:db8:2004:4202::ff
• 2001:db8:2004:4202::
• 2001:db8:2004:4202::23
• 2001:db8:2004:4202::/64
All searches are bounded by the time range currently selected on the page.
Viewing Details of Messages Included in Reports
This functionality works only if reporting and tracking are both local (not centralized on a Cisco Secure Email
and Web Manager.)
Procedure
Step 1 Click any blue number in a table on a report page.
(Not all tables have these links.)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
836
Using Email Security Monitor
My Dashboard Page
The messages included in that number are displayed in Message Tracking.
Step 2 Scroll down to see the list.
What to do next
Related Topics
• Working with Message Tracking Search Results , on page 921
My Dashboard Page
You can create a custom email securityreport page by assembling charts (graphs) and tables from existing
report pages.
To Do This
Add modules to your custom 1. Go to Monitor > My Dashboard and delete any sample modules that
report page you do not need by clicking the [X] in the top right corner of the module.
2. Do one of the following:
• Click the [+] button on a module in a report page under the Monitor
menu to add it to your custom report.
• Go to Monitor > My Dashboard, click the [+] button in one of the
sections, then select the report module that you want to add. You
may need to check the + Report Module in each section to find the
report that you are looking for.
3. Modules are added with default settings. If you add a module that you
have customized (for example, by adding, deleting, or reordering columns
), customize these modules again after adding them. Time range of the
original module is not maintained.
4. If you add a chart that includes a separate legend (for example, a graph
from the Overview page), add the legend separately. If necessary, drag
and drop it into position beside the data it describes.
Notes:
• Some modules on some report pages are available only using one of the
above methods. If you cannot add a module using one method, try the
other method.
• You can add each module only once; if you have already added a
particular module to your report, the option to add it will not be available.
View your custom report 1. Choose Monitor > My Dashboard
page
2. For reports in the Time Range section: The time range selected for all
report pages applies to all modules on the My Dashboard page. Select the
time range to view.
Newly-added modules appear at the top of the relevant section.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
837
Using Email Security Monitor
Overview Page
To Do This
Rearrange modules on your Drag and drop modules into the desired location.
custom report page
Delete modules from your Click the [X] in the top right corner of the module.
custom report page
Overview Page
The Overview page provides a synopsis of the message activity of your email gateway, including an overview
of your quarantines and Outbreak Filters status (in the System Overview section of the page). The Overview
page also includes graphs and detailed message counts for incoming and outgoing messages. You can use
this page to monitor the flow of all mail into and out of your gateway.
The Overview page highlights how the email gateway is integrated with the IP Reputation Service for incoming
mail (messages stopped by reputation filtering, for example). On the Overview page, you can:
• View a mail trend graph of all mail “flowing” into or out of your gateway.
• View a graph showing the number of attempted messages, messages stopped by IP reputation filtering,
messages with invalid reipients, messages marked as spam, messages marked as virus positive, and clean
messages, over time.
• View the summary of the system status and local quarantines.
• See current virus and non-virus outbreak information based on information available at the Threat
Operations Center (TOC).
The Overview page is divided into two sections: System Overview and Incoming and Outgoing Mail graphs
and summary.
Related Topics
• System Overview, on page 838
• Incoming and Outgoing Summary and Graph, on page 839
• Categorizing Email, on page 840
• How Messages are Categorized, on page 841
System Overview
The System Overview section of the Overview page serves as a system dashboard, providing details about
the email gateway including system and work queue status, quarantine status, and outbreak activity.
Related Topics
• Status, on page 838
• System Quarantines, on page 839
• Virus Threat Level, on page 839
Status
This section provides an overview of the current state of the email gateway and inbound mail processing.
System Status: One of the following states:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
838
Using Email Security Monitor
System Quarantines
• Online
• Resource Conservation
• Delivery Suspended
• Receiving Suspended
• Work Queue Paused
• Offline
See the Managing and Monitoring Using the CLI, on page 1091 for more information.
Incoming Messages: The average rate of incoming mail per hour.
Work Queue: The number of messages awaiting processing in the work queue.
Click the System Status Details link to navigate to the System Status page.
System Quarantines
This section displays information about the top three quarantines by disk usage on the email gateway, including
the name of the quarantine, how full the quarantine is (disk space), and the number of messages currently in
the quarantine.
Click the Local Quarantines link to navigate to the Local Quarantines page.
Virus Threat Level
This section shows the Outbreak status as reported by the Threat Operations Center (TOC). Also shown is
the status of the Outbreak quarantine, including how full it is (disk space) and the number of messages in the
quarantine. The Outbreak quarantine is only displayed if you have enabled the Outbreak Filters feature on
your email gateway.
Note In order for the Threat Level indicator to function, you need to have port 80 open on your firewall to
“downloads.ironport.com.” Alternatively, if you have specified a local update server, the Threat Level
indicator will attempt to use that address. The Threat Level indicator will also update correctly if you have
configured a proxy for downloads via the Service Updates page. For more information, see Service Updates
, on page 1026.
Click the Outbreak Details link to view the external Threat Operations Center web site. Note that in order for
this link to work, your email gateway must be able to access the Internet. Note that the Separate Window icon
indicates that a link will open in a separate window when clicked. You may need to configure your browser’s
pop-up blocker settings to allow these windows.
Incoming and Outgoing Summary and Graph
The Incoming and Outgoing summary sections provide access to real-time activity of all mail activity on your
system and is comprised of the Incoming and Outgoing Mail Graphs and Mail Summaries. You can select
the time frame on which to report via the Time Range menu. The time range you select is used throughout all
of the Email Security Monitor pages. The explanations of each type or category of message are below (see
Categorizing Email, on page 840).
While the mail trend graph displays a visual representation of the mail flow, the summary table provides a
numeric breakdown of the same information. The summary table includes the percentage and actual number
of each type of message, including the total number of attempted, threat, and clean messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
839
Using Email Security Monitor
Notes on Counting Messages in Email Security Monitor
The outgoing graph and summary show similar information for outbound mail.
Related Topics
• Notes on Counting Messages in Email Security Monitor, on page 840
Notes on Counting Messages in Email Security Monitor
The method Email Security Monitor uses to count incoming mail depends on the number of recipients per
message. For example, an incoming message from example.com sent to three recipients would count as three
messages coming from that sender.
Because messages blocked by sender reputation filtering do not actually enter the work queue, the email
gateway does not have access to the list of recipients for an incoming message. In this case, a multiplier is
used to estimate the number of recipients. This multiplier was determined by Cisco and based upon research
of a large sampling of existing customer data.
Categorizing Email
Messages reported in the Overview and Incoming Mail pages are categorized as follows:
• Stopped by IP Reputation Filtering: All connections blocked by HAT policies multiplied by a fixed
multiplier (see Notes on Counting Messages in Email Security Monitor, on page 840) plus all recipients
blocked by recipient throttling.
• Stopped by Domain Reputation Filtering: The total count of messages blocked based on the reputation
verdict of the sender domain.
• Invalid Recipients: All recipients rejected by conversational LDAP rejection plus all RAT rejections.
• Spam Messages Detected: The total count of messages detected by the anti-spam scanning engine as
positive or suspect and also those that were both spam and virus positive.
• Virus Messages Detected: The total count and percentage of messages detected as virus positive and
not also spam.
Note If you have configured your anti-virus settings to deliver unscannable or encrypted
messages, these messages will be counted as clean messages and not virus positive.
Otherwise, the messages are counted as virus positive.
• Detected by Advanced Malware Protection: A message attachment was found to be malicious by file
reputation filtering. This value does not include verdict updates or files found to be malicious by file
analysis.
• Messages with Malicious URLs: One or more URLs in the message were found to be malicious by
URL filtering.
• Stopped by Content Filter: The total count of messages that were stopped by a content filter.
• Stopped by DMARC: The total count of messages that were stopped after DMARC verification.
• S/MIME Verification/Decryption Failed: The total count of messages that failed S/MIME verification,
decryption, or both.
• S/MIME Verification/Decryption Successful: The total count of messages that were successfully
verified, decrypted, or decrypted and verified using S/MIME.
• Clean Messages: Mail that is accepted and is deemed to be virus and spam free — the most accurate
representation of clean messages accepted when taking per-recipient scanning actions (such as splintered
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
840
Using Email Security Monitor
How Messages are Categorized
messages being processed by separate mail policies) into account. However, because messages that are
marked as spam or virus positive and still delivered are not counted, the actual number of messages
delivered may differ from the clean message count.
• Graymail Messages
• Marketing Messages: The total count of advertising messages sent by professional marketing
groups, for example Amazon.com.
• Social Networking Messages: The total count of notification messages from social networks, dating
websites, forums, and so on. Examples include LinkedIn and CNET forums.
• Bulk Messages: The total count of advertising messages sent by unrecognized marketing groups,
for example, TechTarget, a technology media company.
Click on the number corresponding to any of the above mentioned graymail categories to view a list of
messages belonging to that category using Message Tracking.
Note Messages that match a message filter and are not dropped or bounced by the filter
are treated as clean. Messages dropped or bounced by a message filter are not
counted in the totals.
How Messages are Categorized
As messages proceed through the email pipeline, they can apply to multiple categories. For example, a message
can be marked as spam, virus, or malware positive, and it can also match a content filter. The various verdicts
follow these rules of precedence: Outbreak Filters quarantining (in this case the message is not counted until
it is released from the quarantine and again processed through the work queue), followed by spam positive,
virus positive, malware positive, and matching a content filter.
For example, if a message is marked as spam positive, and the anti-spam settings are set to drop spam positive
messages, the message is dropped and the spam counter is incremented. Further, if the anti-spam settings are
set to let the spam positive message continue on in the pipeline, and a subsequent content filter drops, bounces,
or quarantines the message, the spam count is still incremented. The content filter count is only incremented
if the message is not spam, virus, or malware positive.
Incoming Mail Page
The Incoming Mail page provides a mechanism to report on the real-time information being collected by the
Email Security Monitor feature for all remote hosts connecting to your email gateway. This allows you to
gather more information about an IP address, domain, and organization (network owner) sending mail to you.
You can perform a Sender Profile search on IP addresses, domains, or organizations that have sent mail to
you.
The Incoming Mail page has three views: Domain, IP Address, and Network Owner and provides a snapshot
of the remote hosts connecting to the system in the context of the selected view.
It displays a table (Incoming Mail Details) of the top domains (or IP addresses, or network owners, depending
on the view) that have sent mail to all public listeners configured on the email gateway. You can monitor the
flow of all mail into your gateway. You can click on any domain/IP/network owner to drill down to access
details about this sender on a Sender Profile page (this is an Incoming Mail page, specific to the
domain/IP/network owner you clicked on).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
841
Using Email Security Monitor
Incoming Mail
Not all available columns are displayed by default. You can show a different set of information by clicking
the Columns link below the table. For example, you can show the "Detected by Advanced Malware Protection"
column, which is hidden by default.
The Incoming Mail page extends to include a group of pages (Incoming Mail, Sender Profiles, and the Sender
Group Report). From the Incoming Mail pages, you can:
• Perform a search on IP addresses, domains, or organizations (network owners) that have sent mail to
you.
• View the Sender Groups report to see connections via a specific sender group and mail flow policy
actions. See Sender Groups Report, on page 846 for more information.
• See detailed statistics on senders which have sent mail to you, including the number of attempted messages
broken down by security service (sender reputation filtering, anti-spam, anti-virus, graymail, and so on).
• Sort by senders who have sent you a high volume of spam or virus email, as determined by anti-spam
or anti-virus security services.
• Use the IP Reputation service to drill down on and examine the relationship between specific IP addresses,
domains, and organizations to obtain more information about a sender.
• Drill down on specific senders to obtain more information about a sender from the IP Reputation Service,
including a sender’s IP Reputation Score and which sender group the domain matched most recently.
Add senders to sender groups.
• Drill down on a specific sender who sent a high volume of spam or virus email, as determined by the
anti-spam or anti-virus security services.
• Once you have gathered information on a domain, you can add the IP address, domain, or organization
to an existing sender group (if necessary) by clicking “Add to Sender Group” from a domain, IP address,
or network owner profile page. See Configuring the Gateway to Receive Email, on page 77.
Related Topics
• Incoming Mail, on page 842
• Incoming Mail Details Listing, on page 843
• Reporting Pages Populated with Data: Sender Profile Pages, on page 845
• Sender Groups Report, on page 846
Incoming Mail
The Incoming Mail page provides access to real-time activity of all public listeners configured on your system
and is comprised of two main sections: the mail trend graphs summarizing the top sender domains received
(by total threat messages, total clean messages, and total graymail messages) and the Incoming Mail Details
listing.
See Incoming Mail Details Listing, on page 843 for an explanation of the data included in the Incoming Mail
Details listing.
Related Topics
Notes on Time Ranges in the Mail Trend Graph, on page 842
Notes on Time Ranges in the Mail Trend Graph
The Email Security Monitor feature constantly records data about the mail flowing into your gateway. The
data are updated every 60 seconds, but the display shown is delayed by 120 seconds behind the current system
time. You can specify the time range to include in the results shown. Because the data is monitored in real
time, information is periodically updated and summarized in the database.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
842
Using Email Security Monitor
Incoming Mail Details Listing
Choose from the time range options in the following table.
Table 85: Time Ranges Available in the Email Security Monitor Feature
This time range selected in the GUI ...is defined as:
Hour the last 60 minutes + up to 5 minutes
Day the last 24 hours + the last 60 minutes
Week the last 7 days + the elapsed hours of the current day
30 days the last 30 days + the elapsed hours of the current day
90 days the last 90 days + the elapsed hours of the current day
Yesterday 00:00 to 23:59 (midnight to 11:59 PM)
Previous Calendar Month 00:00 of the first day of the month to 23:59 of the last day of the
month
Custom Range the range enclosed by the start date and hour and the end date and
hour that you specify
The time range options that you see will differ if you have enabled Centralized Reporting. For details, see
information about Centralized Reporting Mode in Centralizing Services on a Cisco Secure Email and Web
Manager (M-Series), on page 1285
Incoming Mail Details Listing
The top senders which have connected to public listeners of the email gateway are listed in the External
Domains Received listing table at the bottom of the Incoming Mail page, based on the view selected. Click
the column headings to sort the data. See Categorizing Email, on page 840 for an explanation of the various
categories.
The system acquires and verifies the validity of the remote host’s IP address (that is, the domain) by performing
a double DNS lookup . For more information about double DNS lookups and sender verification, see Configuring
the Gateway to Receive Email, on page 77.
The Sender Detail listing has two views, Summary and All.
The default Sender Detail view shows the total number of attempted messages for each sender, and includes
a breakdown by category (the same categories as the Incoming Mail Summary graph on the Overview page.
The value for Stopped by IP Reputation Filtering is calculated based on several factors:
• Number of “throttled” messages from this sender.
• Number of rejected or TCP refused connections (may be a partial count).
• A conservative multiplier for the number of messages per connection.
When the email gateway is under heavy load, an exact count of rejected connections is not maintained on a
per-sender basis. Instead, rejected connections counts are maintained only for the most significant senders in
each time interval. In this situation, the value shown can be interpreted as a “floor”; in other words, at least
this many messages were stopped.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
843
Using Email Security Monitor
“No Domain Information”
Note The Stopped by IP Reputation Filtering total on the Overview page is always based on a complete count of
all rejected connections. Only the per-sender connection counts are ever limited due to load.
Additional columns that you can display are:
Connections Rejected: All connections blocked by HAT policies. When the email gateway is under heavy
load, an exact count of rejected connections is not maintained on a per-sender basis. Instead, rejected connections
counts are maintained only for the most significant senders in each time interval.
Connections Accepted: All connections accepted
Stopped by Domain Reputation Filtering: All messages blocked by the reputation verdict of the sender
domain.
Stopped by Recipient Throttling: This is a component of Stopped by Reputation Filtering. It represents the
number of recipient messages stopped because any of the following HAT limits have been exceeded: maximum
recipients per hour, maximum recipients per message, or maximum messages per connection. This is summed
with an estimate of the recipient messages associated with rejected or TCP refused connections to yield Stopped
by Reputation Filtering.
Detected by Advanced Malware Protection: Messages with attachments that were found to be malicious
by file reputation filtering. This value does not include verdict updates or files found to be malicious by file
analysis.
Total Threat: Total number of threat messages (stopped by sender reputation, stopped as invalid recipient,
spam, plus virus).
Show or hide columns by clicking the Column link at the bottom of the table.
Sort the listing by clicking the column header links. A small triangle beside the column header indicates the
column by which the data is currently sorted.
Related Topics
• “No Domain Information”, on page 844
• Querying for More Information, on page 844
“No Domain Information”
Domains which have connected to the email gateway and could not be verified with a double-DNS lookup
are automatically grouped into the special domain “No Domain Information.” You can control how these
types of unverified hosts are managed via Sender Verification. See Configuring the Gateway to Receive Email,
on page 77.
You can select the number of senders to show in the listing via the Items Displayed menu.
Querying for More Information
For senders listed in the Email Security Monitor table, click the sender (or “No Domain Information” link)
to drill down for more information on the particular sender. The results are displayed on a Sender Profile page
which includes real-time information from the IP Reputation Service. From the Sender Profile page, you can
drill down for more information on specific IP addresses or network owners (see Reporting Pages Populated
with Data: Sender Profile Pages, on page 845).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
844
Using Email Security Monitor
Reporting Pages Populated with Data: Sender Profile Pages
You can also view another report, the Sender Groups report, by clicking the Sender Groups report link at the
bottom of the Incoming Mail page. For more information about Sender Groups reports, see Sender Groups
Report, on page 846.
Reporting Pages Populated with Data: Sender Profile Pages
If you clicked a sender in the Incoming Mail Details table on an Incoming Mail page, the resulting Sender
Profile page is listed with data for the particular IP address, domain, or organization (network owner). Sender
Profile pages show detailed information for the sender. You can access a Sender Profile page for any network
owner, domain, or IP address by clicking on the specified item in the Incoming Mail or other Sender Profile
pages. Network owners are entities that contain domains; domains are entities that contain IP addresses. For
more information on this relationship and how it relates to the IP Reputation Service, see Configuring the
Gateway to Receive Email, on page 77.
The Sender Profile pages displayed for IP addresses, network owners, and domains vary slightly. For each,
the page contains a graph and summary table for incoming mail from this sender. Below the graph is a table
listing domains or IP addresses associated with the sender (the Sender Profile page for individual IP addresses
does not contain the detailed listing) and an information section with the current SenderBase, sender group,
and network information for the sender.
• Network Owner profile pages contain information for the network owner, as well as the domains and IP
addresses associated with that network owner.
• Domain profile pages contain information for the domains and IP addresses associated with that domain.
• IP address profile pages contain information about the IP address only.
Each sender profile page contains the following data in the Current Information table at the bottom of
the page:
• The Global information from the IP Reputation Service, including:
• IP Address, Domain Name, and/or Network Owner
• Network Owner Category (Network Owner Only)
• CIDR Range (IP addresses only)
• Daily Magnitude and Monthly Magnitude for the IP address, Domain, and/or Network Owner
• Days since the first message was received from this sender
• Last sender group and whether DNS verified (IP Address sender profile page only)
Daily magnitude is a measure of how many messages a domain has sent over the last 24 hours. Similar
to the Richter scale used to measure earthquakes, SenderBase magnitude is a measure of message volume
calculated using a log scale with a base of 10. The maximum theoretical value of the scale is set to 10,
which equates to 100% of the world's email message volume (approximately 10 billion messages/day).
Using the log scale, a one-point increase in magnitude equates to a 10x increase in actual volume.
Monthly magnitude is calculated using the same approach as daily magnitude, except the percentages
are calculated based on the volume of email sent over the last 30 days.
• Average Magnitude (IP addresses only)
• Lifetime Volume / 30 Day Volume (IP address profile pages only)
• Bonded Sender Status (IP address profile pages only)
• IP Reputation Score (IP address profile pages only)
• Days Since First Message (network owner and domain profile pages only)
• Number of Domains Associated with this Network Owner (network owner and domain profile pages
only)
• Number of IP Addresses in this Network Owner (network owner and domain profile pages only)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
845
Using Email Security Monitor
Sender Profile Search
• Number of IP Addresses used to Send Email (network owner pages only)
Click the “More from SenderBase” link to see a page with all information supplied by the IP Reputation
Service.
• The Mail Flow Statistics information, with Email Security Monitor information collected about the
sender over the time range that you specify.
• Details about the domains and IP addresses controlled by this network owner are displayed on network
owner profile pages. Details about the IP addresses in the domain are displayed on domain pages.
From a domain profile page, you can drill down to a specific IP address, or drill up to view an organization
profile page. You can also display the DNS Verified status, IP Reputation Score, and Last Sender Group
for each sender address in the IP Addresses table by clicking the Columns link at the bottom of that table.
You can also hide any columns in that table.
From a network owner profile page, you can display information such as Connections Rejected,
Connections Accepted, Stopped by Recipient Throttling, and Detected by Advanced Malware Protection
for each domain in the Domains table by clicking the Columns link at the bottom of that table. You can
also hide any columns in that table.
If you are an administrator of the system, on each of these pages, you can choose to add the network
owner, domain, or IP address to a sender group by clicking the check box for the entity (if necessary)
and then clicking Add to Sender Group.
You can also add a sender to a sender group by clicking the Add to Sender Group link below the Sender
Group Information in the Current Information table for the sender and clicking Add to Sender Group.
For more information about adding senders to sender groups, see Configuring the Gateway to Receive
Email, on page 77. Of course, you do not have to make any changes — you can let the security services
handle incoming mail.
Related Topics
• Sender Profile Search, on page 846
Sender Profile Search
Type an IP address, a domain, or an organization name in the Quick Search box to search for a specific sender.
A Sender Profile page is displayed with the information for sender. See Reporting Pages Populated with Data:
Sender Profile Pages, on page 845.
Sender Groups Report
The Sender Groups report provides a summary of connections by sender group and mail flow policy action,
allowing you to review SMTP connection and mail flow policy trends. The Mail Flow by Sender Group listing
shows the percentage and number of connections for each sender group. The Connections by Mail Flow Policy
Action chart shows the percentage of connections for each mail flow policy action. This page provides an
overview of the effectiveness of your Host Access Table (HAT) policies. For more information about the
HAT, see Configuring the Gateway to Receive Email, on page 77.
Sender Domain Reputation Page
You can use the Sender Domain Reputation report page to view:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
846
Using Email Security Monitor
Outgoing Destinations
• Incoming messages based on the verdict received from the SDR service in graphical format.
• Summary of incoming messages based on the threat category and verdict received from the SDR service
in tabular format.
• Incoming messages based on the threat category received from the SDR service in graphical format.
Note Only the messages whose SDR verdict is 'awful' or 'poor' are classified under the
SDR threat category, such as, 'spam,' 'malicious,' etc.
• Summary of incoming messages based on the threat category received from the SDR service in tabular
format.
In the Summary of Incoming Messages handled by SDR section, you can click on the number of messages
corresponding to a particular verdict to view the related messages in Message Tracking.
Outgoing Destinations
The Outgoing Destinations page provides information about the domains your company sends mail to. The
page consists of two section. The top half of the page consists of graphs depicting the top destinations by
outgoing threat messages and top destinations by outgoing clean messages on the top half of the page. The
bottom half of the page displays a chart showing all the columns sorted by total recipients (default setting).
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link.
The Outgoing Destinations page can be used to answer the following types of questions:
• What domains is the email gateway sending mail to?
• How much mail is sent to each domain?
• How much of that mail is clean, spam-positive, virus-positive, malware or stopped by a content filter?
• How many messages are delivered and how many messages are hard-bounced by the destination server?
Outgoing Senders
The Outgoing Senders page provides information about the quantity and type of mail being sent from IP
addresses and domains in your network. You can view the results by domain or IP address when you view
this page. You might want to view the results by domain if you want to see what volume of mail is being sent
by each domain, or you might want to view the results by IP address if you want see which IP addresses are
sending the most virus messages or triggering content filters.
The page consists of two sections. On the left side of the page is a graph depicting the top senders by total
threat messages. Total threat messages include messages that are spam-positive, virus-positive, malware or
triggered a content filter. On the right side of the page is a graph displaying top senders by clean messages
on the top half of the page. The bottom half of the page displays a chart showing all the columns sorted by
total messages (default setting).
Note This page does not display information about message delivery. Delivery information, such as how many
messages from a particular domain were bounced can be tracked using the Delivery Status page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
847
Using Email Security Monitor
Geo Distribution Page
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link.
The Outgoing Senders page can be used to answer the following types of questions:
• Which IP addresses are sending the most virus-positive, spam-positive or malware email?
• Which IP addresses trigger content filters the most frequently?
• Which domains are sending the most mail?
Geo Distribution Page
You can use the Geo Distribution report page to view:
• Top incoming mail connections based on country of origin in graphical format.
• Total incoming mail connections based on country of origin in tabular format.
You can click on the number of incoming mail connections of a specific geolocation to view the related
messages in Message Tracking.
The "Total Messages" column only displays those messages that are accepted at the SMTP connection level.
Note During report generation:
• If one or more incoming mail connections are detected as private IP address, the incoming mail connections
are categorized as “Private IP Addresses” in the report.
• If one or more incoming mail connections are detected as not a valid IP Reputation score, the incoming
mail connections are categorized as ‘No Country Info’ in the report.
Delivery Status Page
If you suspect delivery problems to a specific recipient domain or if you want to gather information on a
Virtual Gateway address, the Monitor > Delivery Status Page provides monitoring information about email
operations relating to a specific recipient domain.
The Delivery Status Page displays the same information as the tophosts command within the CLI. (For more
information, see “Determining the Make-up of the Email Queue” in Managing and Monitoring Using the CLI,
on page 1091)
This page displays a list of the top 20, 50, or 100 recipient domains for messages delivered by the system
within the last three hours. You can sort by latest host status, active recipients (the default), connections out,
delivered recipients, soft bounced events, and hard bounced recipients by clicking the links in the column
heading for each statistic.
• To search for a specific domain, type the name of the domain in the Domain Name: field and click Search.
• To drill down on a domain shown, click the domain name link.
The results are shown in an Delivery Status Details Page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
848
Using Email Security Monitor
Retrying Delivery
Note Any activity for a recipient domain results in that domain being “active” and thus present in the overview
page. For example, if mail remains in the outbound queue due to delivery problems, that recipient domain
continues to be listed in the outgoing mail overview.
Related Topics
• Retrying Delivery, on page 849
• Delivery Status Details Page, on page 849
Retrying Delivery
Messages that are scheduled for later delivery can be immediately retried by clicking Retry All Delivery.
Retry All Delivery allows you to reschedule messages in the queue for immediate delivery. All domains that
are marked as “down” and any scheduled or soft bounced messages are queued for immediate delivery.
To retry delivery to a specific destination domain, click the domain name link. On the Delivery Status Details
page, click Retry Delivery.
You can also use the delivernow command in the CLI to reschedule messages for immediate delivery. For
more information, see Scheduling Email for Immediate Delivery, on page 1112.
Delivery Status Details Page
Use the Delivery Status Details Page to look up statistics on a specific recipient domain. This page displays
the same information as the hoststatus command within the CLI: Mail Status, Counters and Gauges. (For
more information, see Managing and Monitoring Using the CLI, on page 1091) To search for a specific domain,
type the name of the domain in the Domain Name: field and click Search. Virtual Gateway address information
appears if you are using the altsrchost feature.
Internal Users Page
The Internal Users page provides information about the mail sent and received by your internal users, per
email address (a single user may have multiple email addresses listed — the email addresses are not combined
in the report).
The page consists of two sections:
• Graphs depicting the top users by clean incoming and outgoing messages and top users receiving graymail.
• User mail flow details
You can select a time range on which to report (hour, day, week, or month). As with all reports, you can export
the data for the graphs or the details listing to CSV format via the Export link. You can also display hidden
table columns or hide default columns by clicking the Columns link below the table.
The User Mail Flow Details listing breaks down the mail received and sent by each email address into clean,
spam (incoming only), virus, malware, content filter matches, and graymail (incoming only). You can sort
the listing by clicking on the column headers.
Using the Internal Users report, you can answer these kinds of questions:
• Who is sending the most external email?
• Who receives the most clean email?
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
849
Using Email Security Monitor
Internal User Details
• Who receives the most number of graymail messages?
• Who receives the most spam?
• Who is triggering which content filters?
• Whose email is getting caught by content filters?
Inbound Internal Users are the users for which you received email, based on the Rcpt To: address. Outbound
Internal Users are based on the Mail From: address and are useful when tracking the types of email that senders
on your internal network are sending.
Note that some outbound mail (like bounces) have a null sender. They are counted under outbound and
“unknown.”
Click on an internal user to view the Internal User detail page for that user.
Click the Columns link below the table to show columns that are hidden by default, such as the Incoming
Detected by Advanced Malware Protection column or Outgoing Detected by Advanced Malware Protection
column.
Related Topics
• Internal User Details, on page 850
• Searching for a Specific Internal User, on page 850
Internal User Details
The Internal User detail page shows detailed information about the specified user, including a breakdown of
incoming and outgoing messages showing the number of messages in each category (spam detected, virus
detected, detected by Advanced Malware Protection, stopped by content filter, graymail detected, and clean).
Optionally, for incoming messages, you can click the Columns link below the table to show the Incoming
Detected by Advanced Malware Protection column. This value reflects the number messages that contained
attachments that were determined by file reputation filtering to be malicious. It does not include verdict updates
or files found to be malicious by file analysis. Incoming and outgoing content filter and DLP policy matches
are also shown.
Click on a content filter name to view detailed information for that filter in the corresponding content filter
information page (see Content Filters Page, on page 851). You can use this method to get a list of users who
also sent or received mail that matched that particular content filter.
Searching for a Specific Internal User
You can search for a specific internal user (email address) via the search form at the bottom of the Internal
Users page and the Internal User detail page. Choose whether to exactly match the search text or look for
items starting with the entered text (for instance, starts with “ex” will match “example.com”).
DLP Incidents Page
The DLP Incidents page shows information on the incidents of data loss prevention (DLP) policy violations
occurring in outgoing mail. The email gateway uses the DLP email policies enabled in the Outgoing Mail
Policies table to detect sensitive data sent by your users. Every occurrence of an outgoing message violating
a DLP policy is reported as an incident.
Using the DLP Incidents report, you can answer these kinds of questions:
• What type of sensitive data is being sent by your users?
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
850
Using Email Security Monitor
DLP Incidents Details
• How severe are these DLP incidents?
• How many of these messages are being delivered?
• How many of these messages are being dropped?
• Who is sending these messages?
The DLP Incidents page is comprised of two main sections:
• the DLP incident trend graphs summarizing the top DLP incidents by severity (Low, Medium, High,
Critical) and policy matches, and
• the DLP Incidents Details listing.
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link or PDF format
by clicking the Printable (PDF) link. For information about generating PDFs in languages other than English,
see the Notes on Reports, on page 909.
Click on the name of a DLP policy to view detailed information on the DLP incidents detected by the policy.
You can use this method to get a list of users who sent mail that contained sensitive data detected by the
policy.
Related Topics
• DLP Incidents Details, on page 851
• DLP Policy Detail Page, on page 851
DLP Incidents Details
The DLP policies currently enabled in the email gateway's outgoing mail policies are listed in the DLP Incidents
Details table at the bottom of the DLP Incidents page. Click on the name of a DLP policy to view more detailed
information.
The DLP Incidents Details table shows the total number of DLP incidents per policy, with a breakdown by
severity level. The severity level also includes the number of bounced messages and the number of messages
delivered in the clear, delivered encrypted, or dropped. Click on the column headings to sort the data.
DLP Policy Detail Page
If you clicked the name of a DLP policy in the DLP Incidents Details table, the resulting DLP Policy Detail
page displays the DLP incidents data for the policy. The page displays graphs on the DLP incidents based on
severity.
The page also includes an Incidents by Sender listing at the bottom of the page that lists each internal user
who has sent a message that violated the DLP policy. The listing also shows the total number of DLP incidents
for this policy per user, with a breakdown by severity level, and whether any of the messages were delivered
in the clear, delivered encrypted, or dropped. You can use the Incidents by Sender listing to find out which
users may be sending your organization’s sensitive data to people outside your network.
Clicking on the sender name opens up the Internal Users page. See Internal Users Page, on page 849 for more
information.
Content Filters Page
The Content Filters page shows information about the top incoming and outgoing content filter matches (which
content filter had the most matching messages) in two forms: a bar chart and a listing. Using the Content
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
851
Using Email Security Monitor
Content Filter Details
Filters page, you can review your corporate policies on a per-content filter or per-user basis and answer
questions like:
• Which content filter is being triggered the most by incoming or outgoing mail?
• Who are the top users sending or receiving mail that is triggering a particular content filter?
You can click the name of the content filter in the listing to view more information about that filter on the
Content Filter detail page.
Related Topics
• Content Filter Details, on page 852
Content Filter Details
The Content Filter detail page displays matches for that filter over time, as well as matches by internal user.
In the Matches by Internal User section, you can click the name of a user to view that internal user’s (email
address) Internal User details page (see Internal User Details, on page 850).
DMARC Verification Page
The DMARC Verification page shows the top domains that failed DMARC verification and the details of
actions AsyncOS performed on the messages that failed DMARC verification. You can use this report to
fine-tune your DMARC settings and answer these kinds of questions:
• Which are the domains that sent maximum number of messages that are not DMARC compliant?
• For each domain, what are the actions AsyncOS performed on the messages that failed DMARC
verification?
The DMARC Verification page contains:
• A bar chart showing top domains by DMARC verification failures.
• Tabular representation of the following, for each domain:
• Number of messages that were rejected, quarantined, or accepted without taking any action. Click
on the number to view a list of messages under the selected category.
• Number messages that passed DMARC verification.
• Total number of DMARC verification attempts.
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link or PDF format
by clicking the Printable (PDF) link.
Macro Detection Page
You can use the Macro Detection report page to view:
• Top Incoming Macro-Enabled Attachments by File Type in graphical and tabular format.
• Top Outgoing Macro-Enabled Attachments by File Type in graphical and tabular format.
You can click on the number of macro-enabled attachments to view the related messages in Message Tracking.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
852
Using Email Security Monitor
External Threat Feeds Page
Note During report generation:
• If one or more macros are detected within an archive file, the Archive Files file type is incremented by
one. The number of macro-enabled attachments within an archive file are not counted.
• If one or more macros are detected within an embedded file, the parent file type is incremented by one.
The number of macro-enabled attachments within an embedded file are not counted.
External Threat Feeds Page
You can use the External Threat Feeds report page to view:
• Top ETF sources used to detect threats in messages in graphical format
• Summary of ETF sources used to detect threats in messages in tabular format.
• Top IOCs that matched threats detected in messages in graphical format.
• Top ETF sources used to filter malicious incoming mail connections in graphical format.
• Summary of ETF sources used to filter malicious incoming mail connections in tabular format.
In the ‘Summary of External Threat Feed Sources’ section:
• You can click on the number of messages for a particular ETF source to view the related messages in
Message Tracking.
• You can click on a particular threat feed source to view the distribution of the ETF source based on the
IOCs.
In the ‘Summary of Indicator of Compromise (IOC) Matches’ section:
• You can click on the number of IOCs for a particular ETF source to view the related messages in Message
Tracking.
• You can click on a particular IOC to view the distribution of the IOC based on the ETF sources.
Outbreak Filters Page
The Outbreak Filters page shows the current status and configuration of Outbreak Filters on your email gateway
as well as information about recent outbreaks and messages quarantined due to Outbreak Filters. You can use
this page to monitor your defense against targeted virus, scam, and phishing attacks.
The Threats By Type section shows the different types of threat messages received by the email gateway.
The Threat Summary section shows a breakdown of the threat messages by Malware, Phish, Scam, and Virus.
Click on the number to view a list of all the messages that are included in that number using Message Tracking.
The Past Year Outbreak Summary lists global as well as local outbreaks over the past year, allowing you to
compare local network trends to global trends. The listing of global outbreaks is a superset of all outbreaks,
both viral and non-viral, whereas local outbreaks are limited to virus outbreaks that have affected your email
gateway. Local outbreak data does not include non-viral threats. Global outbreak data represents all outbreaks
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
853
Using Email Security Monitor
Outbreak Filters Page
detected by the Threat Operations Center which exceeded the currently configured threshold for the outbreak
quarantine. Local outbreak data represents all virus outbreaks detected on this appliance which exceeded the
currently configured threshold for the outbreak quarantine. The Total Local Protection Time is always based
on the difference between when each virus outbreak was detected by the Threat Operations Center and the
release of an anti-virus signature by a major vendor. Note that not every global outbreak affects your email
gateway. A value of “--” indicates either a protection time does not exist, or the signature times were not
available from the anti-virus vendors (some vendors may not report signature times). This does not indicate
a protection time of zero, rather it means that the information required to calculate the protection time is not
available.
The Quarantined Messages section summarizes Outbreak Filters quarantining, and is a useful gauge of how
many potential threat messages Outbreak Filters are catching. Quarantined messages are counted at time of
release. Typically, messages will be quarantined before anti-virus and anti-spam rules are available. When
released, they will be scanned by the anti-virus and anti-spam software and determined to be positive or clean.
Because of the dynamic nature of Outbreak tracking, the rule under which a message is quarantined (and even
the associated outbreak) may change while the message is in the quarantine. Counting the messages at the
time of release (rather than the time of entry into the quarantine) avoids the confusion of having counts that
increase and decrease.
The Threat Details listing displays information about specific outbreaks, including the threat category (virus,
scam, or phishing), threat name, a description of the threat, and the number of messages identified. For virus
outbreaks, the Past Year Virus Outbreaks include the Outbreak name and ID, time and date a virus outbreak
was first seen globally, the protection time provided by Outbreak filters, and the number of quarantined
messages. You can select either global or local outbreaks as well as the number of messages to display via
the menu on the left. You can sort the listing by clicking on the column headers. Click on the number to view
a list of all the messages that are included in that number using Message Tracking.
The First Seen Globally time is determined by the Threat Operations Center, based on data from SenderBase,
the world’s largest email and web traffic monitoring network. The Protection Time is based on the difference
between when each threat was detected by the Threat Operations Center and the release of an anti-virus
signature by a major vendor.
A value of “--” indicates either a protection time does not exist, or the signature times were not available from
the anti-virus vendors (some vendors may not report signature times). This does not indicate a protection time
of zero. Rather, it means that the information required to calculate the protection time is not available.
Hit Messages from Incoming Messages section shows the percentage and number of viral attachment, other
threats (non-viral), and clean incoming messages.
Hit Messages by Threat Level section shows the percentage and number of incoming threat messages (viral
and non-viral) based on threat levels (Level 1 through 5).
Messages resided in Outbreak Quarantine section shows the number of threat messages resided in the Outbreak
Quarantine based on the duration.
Top URL's Rewritten section shows the list of top 10 URLs that were rewritten based on the number of
occurrences. Use the Items Displayed drop-down to view more rewritten URLs. Click on the number to view
a list of all the messages that contain the selected rewritten URL on the Message Tracking page.
Using the Outbreak Filters page, you can answer questions like:
• How many messages are being quarantined and what type of threats were they?
• How much lead time has the Outbreak Filter feature been providing for virus outbreaks?
• How do my local virus outbreaks compare to the global outbreaks?
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
854
Using Email Security Monitor
Virus Types Page
Virus Types Page
The Virus Types page provides an overview of the viruses entering and being sent from your network. The
Virus Types page displays the viruses that have been detected by the virus scanning engines running on your
email gateway. You might want to use this report to take a specific action against a particular virus. For
example, if you see that you are receiving a high volume of a viruses known to be embedded in PDF files,
you might want to create a filter action to quarantine messages with PDF attachments.
If you run multiple virus scanning engines, the Virus Types page includes results from all enabled virus
scanning engines. The name of the virus displayed on the page is a name determined by the virus scanning
engines. If more than one scanning engine detects a virus, it is possible to have more than one entry for the
same virus.
The Virus Types page gives you an overview of the viruses entering or being sent from or to your network.
The Top Incoming Virus Detected section shows a chart view of the viruses that have been sent to your
network in descending order. The Top Outgoing Virus Detected section shows a chart view of the viruses
that have been sent from your network in descending order.
Note To see which hosts sent virus-infected messages to your network, you can go to the Incoming Mail page,
specify the same reporting period and sort by virus-positive. Similarly, to see which IP addresses have sent
virus-positive email within your network, you can view the Outgoing Senders page and sort by virus-positive
messages.
The VirusTypes Details listing displays information about specific viruses, including the infected incoming
and outgoing messages, and the total infected messages. The details listing for infected incoming messages
displays the name of the virus and the number of incoming messages infected with this virus. Similarly, the
outgoing messages displays the name of the virus and the number of outgoing messages infected with the
virus. You can sort the Virus Type details by Incoming Messages, Outgoing Messages, or Total Infected
Messages.
URL Filtering Page
• URL Filtering report modules are populated only if URL filtering is enabled.
• URL Filtering reports are available for incoming and outgoing messages.
• Only messages that are scanned by the URL filtering engine (either as part of anti-spam/outbreak filter
scanning or through message/content filters) are included in these modules. However, not all of the results
are necessarily specifically attributable to the URL Filtering feature.
• The Top URL Categories module includes all categories found in messages that have been scanned,
whether or not they match a content or message filter.
• Each message can be associated with only one URL reputation level. For messages with multiple URLs,
the statistics reflect the lowest reputation of any URL in the message.
• URLs in the global allowed list configured at Security Services > URL Filtering are not included in
reports.
URLs in allowed lists used in individual filters are included in reports.
• Malicious URLs are URLs that Outbreak Filters have determined to have poor reputation. Neutral URLs
are those that Outbreak Filters have determined to require click-time protection. Neutral URLs have
therefore been rewritten to redirect them to the Cisco Web Security proxy.
• Results of URL category-based filters are reflected in content and message filter reports.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
855
Using Email Security Monitor
Web Interaction Tracking Page
• Results of click-time URL evaluations by the Cisco Web Security proxy are not reflected in reports.
Web Interaction Tracking Page
• Web Interaction Tracking report modules are populated only if the web interaction tracking feature is
enabled.
• Web Interaction Tracking report modules are not updated in real-time and are refreshed every 30 minutes.
Also, after clicking a rewritten URL, it may take up to two hours for the Web Interaction Tracking report
to report this event.
• Web Interaction Tracking report is not updated in real-time. After clicking a cloud re-directed rewritten
URL, it may take up to two hours for the Web Interaction Tracking report to report this event.
• Web Interaction Tracking reports are available for incoming and outgoing messages.
• Only cloud re-directed rewritten URLs (either by policy or Outbreak Filter) clicked by the end users are
included in these modules.
• Web Interaction Tracking page includes the following reports:
Top Rewritten Malicious URLs clicked by End Users. Click on a URL to view a detailed report that contains
the following information:
• A list of end users who clicked on the rewritten malicious URL.
• Date and time at which the URL was clicked.
• Whether the URL was rewritten by a policy or an outbreak filter.
• Action taken (allow, block, or unknown) when the rewritten URL was clicked. Note that, if a URL was
rewritten by outbreak filter and the final verdict is unavailable, the status is shown as unknown.
Top End Users who clicked on Rewritten Malicious URLs
Web Interaction Tracking Details. Includes the following information:
• A list of all the cloud re-directed rewritten URLs (malicious and unmalicious). Click on a URL to view
a detailed report.
• Action taken (allow, block, or unknown) when a cloud re-directed rewritten URL was clicked.
For the data to show up, perform the following:
• Choose Incoming Mail Policies > Outbreak Filters to configure an outbreak filter and enable message
modification and URL rewriting.
• Configure a content filter with the "Redirect to Cisco Security Proxy" action.
Note that, if the verdict of a URL (clean or malicious) was unknown at the time when the end user clicked it,
the status is shown as unknown. This could be because the URL was under further scrutiny or the web server
was down or not reachable at the time of the user click.
• The number of times end users clicked on a rewritten URL. Click on a number to view a list of all the
messages that contain the clicked URL.
• While using Web Interaction Tracking reports, keep in mind the following limitations:
• If you have configured a content or message filter to deliver messages after rewriting malicious
URLs and notify another user (for example, an administrator), the web interaction tracking data of
the original recipient is incremented even if the notified user clicks on the rewritten URLs.
• If you are sending a copy of quarantined messages containing rewritten URLs to a user (for example,
an administrator) using web interface, the web interaction tracking data of the original recipient is
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
856
Using Email Security Monitor
Forged Email Matches Report
incremented even if the user (to whom the copy of the messages were sent) clicks on the rewritten
URLs.
• At any point, if you plan to modify the time of your email gateway, make sure that the system time
is synchronized with Coordinated Universal Time (UTC).
Forged Email Matches Report
See Monitoring Forged Email Detection Results, on page 641.
File Reputation and File Analysis Reports
For the following reports, see File Reputation and File Analysis Reporting and Tracking , on page 502:
• Advanced Malware Protection
• File Analysis
• AMP Verdict Updates
Mailbox Auto Remediation Report
You can view the details of the mailbox remediation results using the Mailbox Auto Remediation report page
(Monitor > Mailbox Auto Remediation). Use this report to view details such as:
• Remedial actions taken on messages
• The filenames associated with a SHA-256 hash
• A list of profile names defined for the recipients for whom the mailbox remediation was successful or
unsuccessful
• Reason for the remediation failure
• No profile mapped to the domain
Click on a SHA-256 hash to view the related messages in Message Tracking.
For more information, see Remediating Messages in Mailboxes, on page 577
TLS Connections Page
The TLS Connections pages shows the overall usage of TLS connections for sent and received mail. The
report also shows details for each domain sending mail using TLS connections.
The TLS Connections page can be used to determine the following information:
• Overall, what portion of incoming and outgoing connections use TLS?
• What partners do I have successful TLS connections with?
• What partners do I have unsuccessful TLS connections with?
• What partners do I have successful TLS connections with DANE support?
• What partners do I have unsuccessful TLS connections with DANE support?
• What partners have issue with their TLS certificates?
• What percent of overall mail with a partner uses TLS?
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
857
Using Email Security Monitor
Inbound SMTP Authentication Page
• What percent of outgoing TLS connections with DANE support are successful?
• What percent of outgoing connections with DANE support are unsuccessful?
The TLS Connections page is divided into a section for incoming connections and a section for outgoing
connections. Each section includes a graph, summaries, and a table with details.
The graph displays a view of incoming or outgoing TLS-encrypted and non-encrypted connections over the
time range you specify. The graph displays the total volume of messages, the volume of encrypted and
unencrypted messages, the volume of successful and failed TLS encrypted messages and the volume of
successful and failed DANE connections. The graphs distinguish between connections in which TLS was
required and connections in which TLS was merely preferred.
The table displays details for domains sending or receiving encrypted messages. For each domain, you can
view the number of required and preferred TLS connections that were successful and that failed, the total
number of TLS connections attempted (whether successful or failed), the total number of unencrypted
connections, and the total number of unencrypted connections, and the total number of DANE connections
(depending on whether successful or failed). You can also view the percentage of all connections in which
TLS was attempted, and the total number of encrypted messages sent successfully, regardless of whether TLS
was preferred or required. You can show or hide columns by clicking the Columns link at the bottom of this
table.
Inbound SMTP Authentication Page
The Inbound SMTP Authentication page shows the use of client certificates and the SMTP AUTH command
to authenticate SMTP sessions between the email gateway and users’ mail clients. If the email gateway accepts
the certificate or SMTP AUTH command, it will establish a TLS connection to the mail client, which the
client will use to send a message. Since it is not possible for the email gateway to track these attempts on a
per-user basis, the report shows details on SMTP authentication based on the domain name and domain IP
address.
Use this report to determine the following information:
• Overall, how many incoming connection use SMTP authentication?
• How many connections use a client certificated?
• How many connections use SMTP AUTH?
• What domains are failing to connect when attempting to use SMTP authentication?
• How many connections are successfully using the fall-back when SMTP authentication fails?
The Inbound SMTP Authentication page includes a graph for received connections, a graph for mail recipients
who attempted an SMTP authentication connection, and a table with details on the attempts to authenticate
connections.
The Received Connections graph shows the incoming connections from mail clients that attempt to
authentication their connections using SMTP authentication over the time range you specify. The graph
displays the total number of connections the email gateway received, the number that did not attempt to
authenticate using SMTP authentication, the number that failed and succeeded to authenticate the connection
using a client certificate, and the number that failed and succeeded to authenticate using the SMTP AUTH
command.
The Received Recipients graph displays the number of recipients whose mail clients attempted to authenticate
their connections to the email gateways to send messages using SMTP authentication. The graph also show
the number of recipients whose connections were authenticated and the number of recipients whose connections
were not authenticated.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
858
Using Email Security Monitor
Rate Limits Page
The SMTP Authentication details table displays details for the domains whose users attempt to authenticate
their connections to the email gateway to send messages. For each domain, you can view the number of
connection attempts using a client certificate that were successful or failed, the number of connection attempts
using the SMTP AUTH command that were successful or failed, and the number that fell back to the SMTP
AUTH after their client certificate connection attempt failed. You can use the links at the top of the page to
display this information by domain name or domain IP address.
Rate Limits Page
Rate Limiting by envelope sender allows you to limit the number of email message recipients per time interval
from an individual sender, based on the mail-from address. The Rate Limits report shows you the senders
who most egregiously exceed this limit.
Use this report to help you identify the following:
• Compromised user accounts that might be used to send spam in bulk.
• Out-of-control applications in your organization that use email for notifications, alerts, automated
statements, etc.
• Sources of heavy email activity in your organization, for internal billing or resource-management purposes.
• Sources of large-volume inbound email traffic that might not otherwise be considered spam.
Note that other reports that include statistics for internal senders (such as Internal Users or Outgoing Senders)
measure only the number of messages sent; they do not identify senders of a few messages to a large number
of recipients.
The Top Offenders by Incident chart shows the envelope senders who most frequently attempted to send
messages to more recipients than the configured limit. Each attempt is one incident. This chart aggregates
incident counts from all listeners.
The Top Offenders by Rejected Recipients chart shows the envelope senders who sent messages to the largest
number of recipients above the configured limit. This chart aggregates recipient counts from all listeners.
To configure rate limiting by envelope sender or modify the existing rate limit, see Defining Rules for Incoming
Messages Using a Mail Flow Policy, on page 115.
System Capacity Page
The System Capacity page provides a detailed representation of the system load, including messages in the
work queue, average time spent in the work queue, incoming and outgoing messages (volume, size, and
number), overall CPU usage, CPU usage by function, and memory page swapping information.
The system capacity page can be used to determine the following information:
• Identify when an email gateway is exceeding recommended capacity and configuration optimization or
additional email gateways are needed.
• Identify historical trends in system behavior which point to upcoming capacity issues.
• Identify which part of the system is using the most resources to assist with troubleshooting.
It is important to monitor your email gateway to ensure that your capacity is appropriate to your message
volumes. Over time, volume will inevitably rise and appropriate monitoring will ensure that additional capacity
or configuration changes can be applied proactively. The most effective way to monitor system capacity is to
track overall volume, messages in the work queue and incidents of Resource Conservation Mode.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
859
Using Email Security Monitor
System Capacity- Workqueue
• Volume: It is important to have an understanding of the “normal” message volume and the “usual” spikes
in your environment. Track this data over time to measure volume growth. You can use the Incoming
Mail and Outgoing Mail pages to track volume over time. For more information, see System Capacity-
Incoming Mail, on page 861 and System Capacity-Outgoing Mail, on page 861.
• Work Queue: The work queue is designed to work as a “shock absorber”-- absorbing and filtering spam
attacks and processing unusual increases in ham messages. However, the work queue is also the best
indicator of a system under stress, prolonged and frequent work queue backups may indicate a capacity
problem. You can use the WorkQueue page to track the average time messages spend in the work queue
and the activity in your work queue. For more information, see System Capacity- Workqueue, on page
860.
• Resource Conservation Mode: When an email gateway becomes overloaded, it will enter “Resource
Conservation Mode” (RCM) and send a CRITICAL system alert. This is designed to protect the device
and allow it to process any backlog of messages. Your email gateway should enter RCM infrequently
and only during a very large or unusual increase in mail volume. Frequent RCM alerts may be an indication
that the system is becoming overloaded. See System Capacity-System Load, on page 861.
Related Topics
• System Capacity- Workqueue, on page 860
• System Capacity- Incoming Mail, on page 861
• System Capacity-Outgoing Mail, on page 861
• System Capacity-System Load, on page 861
• Note about Memory Page Swapping, on page 862
• System Capacity- All, on page 862
System Capacity- Workqueue
The Workqueue page shows the average time a message spends in the work queue, excluding any time spent
in the Spam quarantine or in a policy, virus, or outbreak quarantine. You can view time periods from an hour
up to one month. This average can help in identifying both short term events delaying mail delivery and
identify long term trends in the workload on the system.
Note If a message is released from the quarantine into the work queue, the “average time in work queue” metric
ignores this time. This prevents double-counting and distorted statistics due to extended time spent in a
quarantine.
The report also shows the volume of messages in the work queue over a specified time period, and it shows
the maximum messages in the work queue over the same time period. The graphical representation of the
maximum messages in the work queue also shows the work queue threshold level.
Occasional spikes in the Workqueue graphs are normal and expected. If the messages in the work queue
remain higher than the configured threshold for a long duration, this may indicate a capacity issue. In this
scenario, consider tuning the threshold level or review the system configuration.
For instructions to change the work queue threshold level, see Setting Thresholds for System Health Parameters,
on page 1041.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
860
Using Email Security Monitor
System Capacity- Incoming Mail
Tip When reviewing the work queue page, you may want to measure the frequency of work queue backups, and
take note of work queue backups that exceed 10,000 messages.
System Capacity- Incoming Mail
The incoming mail page shows incoming connections, the total number of incoming messages, the average
message size, and the total incoming message size. You can limit the results to the time range that you specify.
It is important to have an understanding of the trends of normal message volume and spikes in your environment.
You can use the incoming mail page to help track volume growth over time and plan for system capacity.
You might also want to compare the Incoming Mail data with the Sender Profile data to view the trends in
volumes of emails that are being sent from specific domains to your network.
Note An increased number of incoming connections may not necessarily affect system load.
System Capacity-Outgoing Mail
The outgoing mail page shows outgoing connections, the total number of outgoing messages, the average
message size, and the total outgoing message size. You can limit the results to the time range that you specify.
It is important to have an understanding of the trends of normal message volume and spikes in your environment.
You can use the outgoing mail page to help track volume growth over time and plan for system capacity. You
might also want to compare the Outgoing Mail data with the Outgoing Destinations data to view the trends
in volumes of emails that are being sent from specific domains or IP addresses.
System Capacity-System Load
The system load report shows the following:
• Overall CPU Usage
• Memory Page Swapping
• Resource Conservation Activity
Overall CPU Usage
The email gateway is optimized to use idle CPU resources to improve message throughput. High CPU usage
may not indicate a system capacity problem. If the high CPU usage is coupled with consistent, high-volume
memory page swapping, you may have a capacity problem.
Note This graph also shows the threshold level for CPU usage. If you want to change the threshold level, use the
System Administration > System Health page in web interface or healthconfig command in CLI. See
Setting Thresholds for System Health Parameters, on page 1041.
This page also shows a graph that displays the amount of CPU used by different functions, including mail
processing, spam and virus engines, reporting, and quarantines. The CPU-by-function graph is a good indicator
of which areas of the product use the most resources on your system. If you need to optimize your email
gateway, this graph can help you determine which functions may need to be tuned or disabled.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
861
Using Email Security Monitor
Note about Memory Page Swapping
Memory Page Swapping
The memory page swapping graph shows how frequently the system must page to disk. This graph also shows
the threshold level for memory page swapping. If you want to change the threshold level, use the System
Administration > System Health page in web interface or healthconfig command in CLI. See Setting
Thresholds for System Health Parameters, on page 1041.
Resource Conservation Activity
The resource conservation activity graph shows the number of times the email gateway entered Resource
Conservation Mode (RCM). For example, if the graph shows n times, it means that the email gateway has
entered RCM n times and exited at least n-1 times.
Your email gateway should enter RCM infrequently and only during a very large or unusual increase in mail
volume. If the Resource Conservation Activity graph shows that your email gateway is entering RCS frequently,
it may be an indication that the system is becoming overloaded.
Note about Memory Page Swapping
The system is designed to swap memory regularly, so some memory swapping is expected and is not an
indication of problems with your email gateway. Unless the system consistently swaps memory in high
volumes, memory swapping is normal and expected behavior, especially on C170 and C190 appliances. To
improve performance, you may need to add email gateways to your network or tune your configuration to
ensure maximum throughput.
System Capacity- All
The All page consolidates all the previous system capacity reports onto a single page so you can view the
relationship between the different reports. For example, you might view the message queue is high at the same
time that excessive memory swapping takes place. This might be an indication that you have a capacity
problem. You may want to save this page as PDF to preserve a snapshot of system performance for later
reference (or to share with support staff). For information about generating PDFs in languages other than
English, see the Notes on Reports, on page 909.
System Status Page
The System Status page provides a detailed representation of all real-time mail and DNS activity for the
system. The information displayed is the same information that is available by using the status detail and
dnsstatus commands in the CLI. For more information, see “Monitoring Detailed Email Status” for the
status detail command and “Checking the DNS Status” for the dnsstatus command in Managing and
Monitoring Using the CLI, on page 1091
The System Status page is comprised of four sections: System Status, Gauges, Rates, and Counters.
Related Topics
• System Status, on page 863
• Gauges, on page 863
• Rates, on page 863
• Counters, on page 864
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
862
Using Email Security Monitor
System Status
System Status
The system status section shows Mail System Status and Version Information.
Related Topics
• Mail System Status, on page 863
• Version Information, on page 863
Mail System Status
The Mail System Status section includes:
• System Status (for more information about system status, see Status, on page 838)
• The last time the status was reported.
• The uptime for the email gateway.
• The oldest message in the system, including messages that have not yet been queued for delivery.
Version Information
The Version Information section includes:
• The email gateway model name.
• The version and build date of the AsyncOS operating system installed.
• The installation date of the AsyncOS operating system.
• The serial number of the system to which you are connected.
This information is useful if you are contacting Cisco Customer Support. (See Working with Technical Support,
on page 1269.)
Gauges
The Gauges section shows queue and resource utilization.
• Mail Processing Queue
• Active Recipients in Queue
• Queue Space
• CPU Utilization
Mail Gateway Appliance refers to the percentage of the CPU that AsyncOS processes are consuming. CASE
refers to several items, including the Anti-Spam scanning engine and Outbreak Filters processes.
• General Resource Utilization
• Logging Disk Utilization
Rates
The Rates section shows rate handling for recipients.
• Mail Handling Rates
• Completion Rates
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
863
Using Email Security Monitor
Counters
Counters
You can reset the cumulative email monitoring counters for system statistics and view the last time the counters
were reset. The reset affects system counters as well as per-domain counters. The reset does not affect the
counters on messages in the delivery queue related to retry schedules.
Note Only user accounts that are in the administrator or operator group have access to reset the counters. User
accounts you create in the guest group will not be able to reset the counters. For more information, see Working
with User Accounts, on page 977.
Click Reset Counters to reset the counters. This button offers the same functionality as the resetcounters
command in the CLI. For more information, see Resetting Email Monitoring Counters, on page 1106.
• Mail Handling Events
• Completion Events
• Domain Key Events
• DNS Status
High Volume Mail Page
Note The High Volume Mail page shows data only from message filters that use Header Repeats rule.
The High Volume Mail page contains the following reports in the form of bar charts:
• Top Subjects. You can use this chart to understand the top subjects of messages that AsyncOS received.
• Top Envelope Senders. You can use this chart to understand the top envelope senders of messages that
AsyncOS received.
• Top Message Filters by Number of Matches. You can use this chart to understand the top message
filter (that uses Header Repeats rule) matches.
The High Volume Mail page also provides a tabular representation of the top message filters and the number
of matches for the respective message filters. Click on the number to view a list of all the messages that are
included in that number using Message Tracking.
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link or PDF format
by clicking the Printable (PDF) link.
Message Filters Page
The Message Filters page shows information about the top message filter matches (which message filter had
the most matching messages) in two forms: a bar chart and a tabular representation.
Using the bar chart, you can find the message filters that are being triggered the most by incoming and outgoing
messages. The tabular representation shows the top message filters and the number of matches for the respective
message filters. Click on the number to view a list of all the messages that are included in that number using
Message Tracking.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
864
Using Email Security Monitor
Safe Print Page
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link or PDF format
by clicking the Printable (PDF) link.
Safe Print Page
You can use the Safe Print report page to view:
• Number of safe-printed attachments based on the file type in graphical format.
• Summary of safe-printed attachments based on the file type in tabular format.
In the ‘Summary of Safe Print File Types’ section, click the total number of safe-printed attachments to view
the message details in Message Tracking.
Retrieving CSV Data
You can retrieve the data used to build the charts and graphs in the Email Security Monitor in CSV format.
The CSV data can be accessed in two ways:
• CSV reports delivered via email. You can generate a CSV report that is delivered via email or archived.
This delivery method is useful when you want separate reports for each table represented on an Reports
page, or when you want to send CSV data to users who do not have access to internal networks.
The comma-separated values (CSV) Report Type is an ASCII text file which contains the tabular data
of the scheduled report. Each CSV file may contain up to 100 rows. If a report contains more than one
type of table, a separate CSV file will be created for each table. Multiple CSV files for a single report
will be compressed into a single .zip file for the archived file storage option or will all be attached to
separate e-mail messages for e-mail delivery.
• CSV files retrieved via HTTP. You can retrieve the data used to build the charts and graphs in the Email
Security Monitor feature via HTTP. This delivery method is useful if you plan to perform further analysis
on the data via other tools. You can automate the retrieval of this data, for example, by an automatic
script that will download raw data, process, and then display the results in some other system.
Related Topics
• Retrieving CSV Data Via Automated Processes, on page 865
Retrieving CSV Data Via Automated Processes
The easiest way to get the HTTP query you will need is to configure one of the Email Security Monitor pages
to display the type of data you want. You can then copy the Export link. This is the download URL. When
automating data retrieval like this it is important to note which parameters in the download URL should be
fixed and which should change (see below).
The download URL is encoded in such a way that it can be copied to an external script that can execute the
same query (using proper HTTP authentication) and get a similar data set. The script can use Basic HTTP
Authentication or cookie authentication. Keep the following in mind when retrieving CSV data via automated
processes:
• Time range selection (past hour, day, week, etc) in relation to when the URL is used again. If you copy
the URL to retrieve a CSV data set for “Past Day,” the next time you use that URL you will get a new
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
865
Using Email Security Monitor
Sample URL
data set that covers the “Past Day” from the time you send the URL again. The date range selection is
retained, and appears in the CSV query string (e.g. date_range=current_day ).
• Filtering and grouping preferences for the data set. Filters are retained and appear in the query string.
Note that filters in reports are rare — one example is the “Global / Local” outbreaks selector in the
Outbreaks report.
• The CVS download returns all rows of data in the table for the selected time range.
• The CSV download returns the rows of data in the table ordered by timestamp and key. You can perform
further sorting in a separate step such as via a spreadsheet application.
• The first row contains column headers that match the display names shown in the report. Note that
timestamps (see Timestamps, on page 866) and keys (see Keys, on page 867) also appear.
Related Topics
• Sample URL, on page 866
• Adding Basic HTTP Authentication credentials, on page 866
• File Format, on page 866
• Timestamps, on page 866
• Keys, on page 867
• Streaming, on page 867
Sample URL
http://example.com/monitor/content_filters?format=csv&sort_col_ss_0_0_0=
MAIL_CONTENT_FILTER_INCOMING.RECIPIENTS_MATCHED§ion=ss_0_0_0
&date_range=current_day&sort_order_ss_0_0_0=desc&report_def_id=mga_content_filters
Adding Basic HTTP Authentication credentials
To specify basic HTTP Authentication credentials to the URL:
http://example.com/monitor/
becomes:
http://username:[email protected]/monitor/
File Format
The downloaded file is in CSV format and has a .csv file extension. The file header has a default filename,
which starts with the name of the report, then the section of the report.
Timestamps
Exports that stream data show begin and end timestamps for each raw “interval” of time. Two begin and two
end timestamps are provided — one in numeric format and the other in human-readable string format. The
timestamps are in GMT time, which should make log aggregation easier if you have email gateways in multiple
time zones.
Note that in some rare cases where the data has been merged with data from other sources, the export file
does not include timestamps. For example, the Outbreak Details export merges report data with Threat
Operations Center (TOC) data, making timestamps irrelevant because there are no intervals.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
866
Using Email Security Monitor
Keys
Keys
Exports also include the report table key(s), even in cases where the keys are not visible in the report. In cases
where a key is shown, the display name shown in the report is used as the column header. Otherwise, a column
header such as “key0,” “key1,” etc. is shown.
Streaming
Most exports stream their data back to the client because the amount of data is potentially very large. However,
some exports return the entire result set rather than streaming data. This is typically the case when report data
is aggregated with non-report data (e.g. Outbreaks Detail.)
Email Security Monitor Pages on the New Web Interface
To access the new web interface, click the Secure Email Gateway is getting a new look. Try it!! link on
the leagcy web interface. For more information, see Accessing the Web-Based Graphical User Interface (GUI),
on page 38.
You can view the reports for the email gateway using the Reports drop-down as shown in the following
figure:
Note The Mail Flow Summary report page is the landing page (the page displayed after login).
Figure 70: Reports Drop-down
You use these pages in the GUI to monitor domains that are connecting to the email gateway listeners. You
can monitor, sort, analyze, and classify the “mail flow” of your email gateway and differentiate between
high-volume senders of legitimate mail and potential “spammers” (senders of high-volume, unsolicited
commercial email) or virus senders. These pages can also help you troubleshoot inbound connections to the
system (including important information such as IP Reputation score and most recent sender group match for
domains).
These pages help you classify mail relative to the email gateway, and also relative to the services that exist
beyond the scope of the gateway, such as the IP Reputation Service, the Anti-Spam scanning service, the
Anti-Virus scanning security services, content filters, and Outbreak Filters.
You can export graphs and other data to CSV (comma separated values) format via the Export link.
The exported CSV data will display all message tracking and reporting data in GMT regardless of what is set
on the email gateway. The purpose of the GMT time conversion is to allow data to be used independently
from the email gateway or when referencing data from email gateways in multiple time zones.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
867
Using Email Security Monitor
Email Security Monitor Pages on the New Web Interface
Note If you export localized CSV data, the headings may not render properly in some browsers. This occurs because
some browsers may not use the correct character set for the localized text. To work around this problem, you
can save the file to disk, and open the file using File > Open. When you open the file, select the character set
to display the localized text.
For more information about automating the export of report data, see Retrieving CSV Data, on page 865).
List of Email Security Monitor Pages
• My Favorite Reports Page, on page 870
• Mail Flow Summary Page, on page 872
• System Capacity Page, on page 859
• Advanced Malware Protection Page , on page 881
• Virus Filtering Page, on page 885
• Macro Detection Page, on page 886
• DMARC Verification Page, on page 886
• Outbreak Filtering Page, on page 887
• URL Filtering Page , on page 887
• Forged Email Detection Page, on page 889
• Sender Domain Reputation Page, on page 889
• External Threat Feeds Page, on page 890
• Mail Flow Details Page, on page 890
• Sender Groups Report, on page 898
• Outgoing Destinations, on page 898
• TLS Encryption Page, on page 898
• Inbound SMTP Authentication Page, on page 899
• Rate Limits Page , on page 900
• Connections by Country Page , on page 900
• User Mail Summary Page, on page 901
• DLP Incident Summary Page, on page 902
• Web Interaction Page, on page 903
• Message Filters Page, on page 905
• High Volume Mail Page, on page 906
• Content Filters Page, on page 906
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
868
Using Email Security Monitor
Searching and the Interactive Email Report Pages
• Advanced Phishing Protection Report Page, on page 907
• Mail Policy Details Report Page, on page 907
Searching and the Interactive Email Report Pages
Many of the interactive email reporting pages include a ‘Search For:’ drop-down menu at the bottom of the
page.
From the drop-down menu, you can search for several types of criteria, including the following:
• IP address
• Domain
• Network owner
• Internal user
• Destination domain
• Internal sender domain
• Internal sender IP address
• Incoming TLS domain
• Outgoing TLS domain
• SHA-256
For most searches, choose whether to exactly match the search text or look for items starting with the entered
text (for example, starts with “ex” will match “example.com”).
For IPv4 searches, the entered text is always interpreted as the beginning of up to four IP octets in dotted
decimal format. For example, ‘17.*’ will search in the range 17.0.0.0 through 17.255.255.255, so it will match
17.0.0.1 but not 172.0.0.1. For an exact match search, enter all four octets. IP address searches also support
Classless Inter-Domain Routing (CIDR) format (17.16.0.0/12).
For IPv6 searches, you can enter addresses using the formats in the following examples:
• 2001:db8:2004:4202::0-2001:db8:2004:4202::ff
• 2001:db8:2004:4202::
• 2001:db8:2004:4202::23
• 2001:db8:2004:4202::/64
Viewing Details of Messages Included in Reports
This functionality works only if reporting and tracking are both local (not centralized on a Cisco Secure Email
and Web Manager.)
Procedure
Step 1 Click any blue number in a table on a report page.
(Not all tables have these links.)
The messages included in that number are displayed in Message Tracking.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
869
Using Email Security Monitor
Time Range for Reports
Step 2 Scroll down to see the list.
What to do next
Related Topics
• Working with Message Tracking Search Results , on page 921
Time Range for Reports
The Email Security Monitor feature constantly records data about the mail flowing into your gateway. The
data are updated every 60 seconds, but the display shown is delayed by 120 seconds behind the current system
time. You can specify the time range to include in the results shown. Because the data is monitored in real
time, information is periodically updated and summarized in the database.
Choose from the time range options in the following table.
Table 86: Time Ranges Available in the Email Security Monitor Feature
This time range selected in the GUI ...is defined as:
Hour the last 60 minutes + up to 5 minutes
Day the last 24 hours + the last 60 minutes
Week the last 7 days + the elapsed hours of the current day
30 days the last 30 days + the elapsed hours of the current day
90 days the last 90 days + the elapsed hours of the current day
Yesterday 00:00 to 23:59 (midnight to 11:59 PM)
Previous Calendar Month 00:00 of the first day of the month to 23:59 of the last day of the
month
Custom Range the range enclosed by the start date and hour and the end date and
hour that you specify
My Favorite Reports Page
You can create a custom report page by assembling charts (graphs) and tables from all your existing email
security reports, on the My Reports page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
870
Using Email Security Monitor
Modules That Cannot Be Added to the My Reports Page
To Do This
Add modules to My Favorite Reports page See:
• Modules That Cannot Be Added to the My Reports Page,
on page 871
• Adding Reports on the My Favorite Reports Page, on page
872
View My Favorite Reports page 1. Select My Favorite Reports from the Reports drop-down.
2. Select the time range to view. The time range selected
applies to all reports, including all modules on the My
Favorite Reports page.
Newly-added modules appear at the top of the custom report.
Note The report modules that you add on the My Favorite
Reports page of the new web interface differs from
the report modules added on the legacy web interface.
It can also differ based on the User roles that you
assign.
Rearrange modules on the My Favorite On the My Favorite Reports page, drag and drop the modules
Reports page into the desired location.
Delete modules from the My Favorite You can delete the report modules from the My Favorite Reports
Reports page page in any one of the following ways:
• Click the in the top right corner of the required report
module.
• Go to the My Favorite Reports page and select Manage
Favorites to remove the required report module.
Modules That Cannot Be Added to the My Reports Page
• All modules on the System Status page.
• All modules on the Reporting Data Availability page.
• All modules on the Message Tracking Data Availability page.
• The following per-domain modules from the Sender Profile detail report page: Current Information from
SenderBase, Sender Group Information, and Network Information.
• The Past Year Virus Outbreak Summary chart and Past Year Virus Outbreaks table on the Outbreak
Filters report page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
871
Using Email Security Monitor
Adding Reports on the My Favorite Reports Page
Adding Reports on the My Favorite Reports Page
Before you begin
• Ensure that the modules that you want to add can be added. See Modules That Cannot Be Added to the
My Reports Page, on page 871.
• Click on the top right corner of a module to delete any default modules that you do not need.
Procedure
Step 1 You can add a report module on the My Favorite Reports page in any one of the following ways:
Note Some modules are available only using one of these methods. If you cannot add a module using
one method, try another method.
• Go to the report page under the Reports drop-down and click on the top of the report module.
• From the Reports drop-down, select My Reports and click Manage Favorites.
The report modules are listed as per the tables and charts on email report pages. Select the required report
modules and click Add to add to the My Favorite Reports page. If you do not want any reports to be
displayed on the My Favorite Report page, select the report module and click Remove.
You can add each module only once; if you have already added a particular module to your report, the
option to add it will not be available.
Note You can add a maximum of 10 report modules on the My Favorite Reports page.
Step 2 If you add a report module that you have customized (for example, by adding, deleting, or reordering columns,
or by displaying non-default data in the chart), customize the modules on the My Favorite Reports page.
Modules are added with default settings. Time range of the original module is not maintained.
Step 3 If you add a chart that includes a separate legend (for example, a graph from the Mail Flow Summary page),
add the legend separately. If necessary, drag and drop it into position beside the data it describes.
Mail Flow Summary Page
The Mail Flow Summary report page provides a synopsis of the email message activity from your email
gateway. The Mail Flow Summary report page includes graphs and summary tables for the incoming and
outgoing messages.
The Mail Flow Summary: Incoming report page shows the incoming mail graphs for the total number of
messages that are processed and blocked by the email gateway, as well as the summary of the incoming mails.
You can use the mail trend graphs on this page to monitor the flow of all the incoming mails that are processed
and blocked by your email gateways, based on the selected time range. For more information, see Time Range
for Reports, on page 870.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
872
Using Email Security Monitor
Mail Flow Summary Page
To search for specific information within your data, see Searching and the Interactive Email Report Pages ,
on page 869
The following mail trend graphs provide a visual representation of the incoming mail flow:
• Threat Detection Summary
• Content Summary
You can view the mail trend of the incoming messages based on the required counters for the respective
categories. For more information, see Using Counters to Filter Data on the Trend Graphs, on page 878.
The Mail Flow Summary: Outgoing report page shows the outgoing mail graphs for the total number of
messages that are processed and delivered by the email gateway, as well as the summary of the outgoing mail.
You can use the mail trend graphs on this page to monitor the flow of all the outgoing mails that are processed
and delivered by your email gateways, based on the selected time range. For more information, see Time
Range for Reports, on page 870.
The following mail trend graphs provide a visual representation of the mail flow of the Outgoing Mails.
You can view the mail trend of the outgoing messages based on the required counters of the processed messages.
For more information, see Using Counters to Filter Data on the Trend Graphs, on page 878.
The following list explains the various sections on the Mail Flow Summary report page:
Table 87: Details on the Mail Flow Summary Page
Section Description
Mail Flow Summary: Incoming
Number of Messages The Number of Messages graph provides a visual representation of the
total number of messages processed, including the messages that are
processed as threat messages.
Threat Messages The Threat Messages graph provides a visual representation of the total
number of messages that are blocked by the email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
873
Using Email Security Monitor
Mail Flow Summary Page
Section Description
Threat Detection Summary The Threat Detection Summary mail trend graph provides a visual
representation based on the following categories:
• Connection and IP Reputation Filtering: Messages that are
categorized as threat by the IP Reputation Filtering and Invalid
Recipients.
• Spam Detection: Messages that are categorized as threat by the
Anti-spam scanning engine.
• Email Spoofing: Messages which are categorized as threat due
to DMARC Verification failure.
• Outbreak Threat Summary: Messages which are categorized
as phishing, scam, virus or malware, by the Outbreak Filtering
engine.
• Attachment and Malware Detection: Messages that are
categorized as threat by the Anti-virus and AMP engines.
• All Categories: All the messages that are categorized as threat.
Content Summary The Content Summary mail trend graph provides a visual representation
based on the following categories:
• Graymail: Messages that are categorized as marketing, bulk or
social networking.
• Content Filters: Messages that are categorized by the content
filters.
• All Categories: All the messages that are categorized by graymail
engines and content filters.
Mail Flow Summary: Outgoing
Number of Messages The Number of Messages graph provides a visual representation of the
total number of messages processed, including the messages that are
processed as clean.
Message Delivery The Message Delivery graph provides a visual representation of the
total number of messages that are delivered, including hard bounces.
Outgoing Mails The Outgoing Mails trend graph provides a visual representation based
on the following categories:
• Spam Detected
• Virus Detected
• Detected by AMP
• Stopped by Content Filters
• Stopped by DLP
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
874
Using Email Security Monitor
How Email Messages Are Categorized by the Email Gateways
Related Topics
• How Email Messages Are Categorized by the Email Gateways, on page 875
• Incoming and Outgoing Summary and Graph, on page 839
• Categorizing Email Messages on the Mail Flow Summary Page, on page 876
• Using Counters to Filter Data on the Trend Graphs, on page 878
How Email Messages Are Categorized by the Email Gateways
As messages proceed through the email pipeline, they can apply to multiple categories. For example, a message
can be marked as spam or virus positive; it can also match a content filter. The precedence of the various
filters and scanning activities greatly impacts the results of message processing.
In the example above, the various verdicts follow these rules of precedence:
• Spam positive
• Virus positive
• Matching a content filter
Following these rules, if a message is marked as spam positive, and your anti-spam settings are set to drop
spam positive messages, the message is dropped and the spam counter is incremented.
Further, if your anti-spam settings are set to let the spam positive message continue on in the email pipeline,
and a subsequent content filter drops, bounces, or quarantines the message, the spam count is still incremented.
The content filter count is only incremented if the message is not spam or virus positive.
Alternately, if the message were quarantined by Outbreak Filters, it would not be counted until it was released
from the quarantine and again processed through the work queue.
For complete information about message processing precedence, see the chapter about the email pipeline in
the online help or user guide for your email gateway.
Incoming and Outgoing Summary and Graph
The Incoming and Outgoing summary sections provide access to real-time activity of all mail activity on your
system and is comprised of the Incoming and Outgoing Mail Graphs and Mail Summaries. You can select
the time frame on which to report via the Time Range menu. The time range you select is used throughout all
of the Email Security Monitor pages. The explanations of each type or category of message are below (see
Categorizing Email, on page 840).
While the mail trend graph displays a visual representation of the mail flow, the summary table provides a
numeric breakdown of the same information. The summary table includes the percentage and actual number
of each type of message, including the total number of attempted, threat, and clean messages.
The outgoing graph and summary show similar information for outbound mail.
Related Topics
• Notes on Counting Messages in Email Security Monitor, on page 840
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
875
Using Email Security Monitor
Notes on Counting Messages in Email Security Monitor
Notes on Counting Messages in Email Security Monitor
The method Email Security Monitor uses to count incoming mail depends on the number of recipients per
message. For example, an incoming message from example.com sent to three recipients would count as three
messages coming from that sender.
Because messages blocked by sender reputation filtering do not actually enter the work queue, the email
gateway does not have access to the list of recipients for an incoming message. In this case, a multiplier is
used to estimate the number of recipients. This multiplier was determined by Cisco and based upon research
of a large sampling of existing customer data.
Categorizing Email Messages on the Mail Flow Summary Page
Incoming messages that are considered as threat, and outgoing messages that are delivered in the Mail Flow
Summary report page are categorized as follows:
Table 88: Email Categories on Mail Flow Summary Page
Category Description
Mail Flow Summary: Incoming
IP Reputation Filtering All connections blocked by HAT policies, multiplied by a fixed multiplier,
and added with all recipients blocked by recipient throttling.
The value for Stopped by IP Reputation Filtering is calculated based on the
following factors:
• Number of “throttled” messages from this sender.
• Number of rejected or TCP refused connections (may be a partial count).
• A conservative multiplier for the number of messages per connection.
When the email gateway is under heavy load, an exact count of rejected
connections is not maintained on a per-sender basis. Instead, rejected
connections counts are maintained only for the most significant senders in
each time interval. In this situation, the value shown can be interpreted as
an indicative value of the least number of messages are stopped.
The IP Reputation Filtering total count and percentage on the Mail Flow
Summary report page is always based on a complete count of all rejected
connections. Only the per-sender connection counts are limited due to load.
Sender Domain Reputation The total count of messages blocked based on the reputation verdict of the
Filtering sender domain.
Invalid Recipients The total count and percentage of all mail recipients rejected by
conversational LDAP rejection in addition to all RAT rejections.
Anti-Spam The total count and percentage of incoming messages detected by the
anti-spam scanning engine as positive or suspect. Additionally, messages
that are both spam and virus positive.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
876
Using Email Security Monitor
Categorizing Email Messages on the Mail Flow Summary Page
Category Description
Anti-Virus The total count and percentage of incoming messages detected as virus
positive and not also spam.
The following messages are counted in the “Virus Detected” category:
• Messages with a virus scan result of “Repaired” or “Infectious”
• Messages with a virus scan result of “Encrypted” when the option to
count encrypted messages as containing viruses is selected
• Messages with a virus scan result of “Unscannable” when the action
for unscannable messages is NOT “Deliver”
• Messages with a virus scan result of “Unscannable” or “Encrypted”
when the option to deliver to an alternate mail host or an alternate
recipient is selected
• Messages that are deleted from the Outbreak quarantine, either manually
or by timing out.
Advanced Malware Protection The total count and percentage of incoming messages blocked by the file
analysis service.
A message attachment was found to be malicious by file reputation filtering.
This value does not include verdict updates or files found to be malicious
by file analysis.
Content Filter The total count and percentage of incoming messages that are stopped by
message and content filters.
DMARC Policy The total count and percentage of incoming messages that failed DMARC
verification policy.
S/MIME The total count and percentage of incoming messages that failed S/MIME
Verification/Decryption Failed verification, decryption, or both.
Mail Flow Summary: Outgoing
Hard Bounces The total count and percentage of outgoing messages that are permanently
undeliverable.
Delivered The total count and percentage of outgoing messages that are delivered.
Note If you have configured your anti-virus settings to deliver unscannable or encrypted messages, these messages
will be counted as clean messages and not virus positive. Otherwise, the messages are counted as virus positive.
Additionally, if messages match a message filter and are not dropped or bounced by the filter, they are treated
as clean. Messages dropped or bounced by a message filter are not counted in the totals.
Related Topics
Mail Flow Details Page, on page 890
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
877
Using Email Security Monitor
Using Counters to Filter Data on the Trend Graphs
Using Counters to Filter Data on the Trend Graphs
You can filter data based on the required time range and available counters on a trend graph.
The time range that you select in the Time Range drop-down, is used for a trend graph until you select a
different value.
A counters on a trend graph of the Mail Flow Summary report page is used to view data specific to different
filters. Click on an available counter to filter the data.
System Capacity Page
The System Capacity page provides a detailed representation of the system load, including messages in the
work queue, average time spent in the work queue, incoming and outgoing messages (volume, size, and
number), overall CPU usage, CPU usage by function, and memory page swapping information.
The system capacity page can be used to determine the following information:
• Identify when an email gateway is exceeding recommended capacity and configuration optimization or
additional email gateways are needed.
• Identify historical trends in system behavior which point to upcoming capacity issues.
• Identify which part of the system is using the most resources to assist with troubleshooting.
It is important to monitor your email gateway to ensure that your capacity is appropriate to your message
volumes. Over time, volume will inevitably rise and appropriate monitoring will ensure that additional capacity
or configuration changes can be applied proactively. The most effective way to monitor system capacity is to
track overall volume, messages in the work queue and incidents of Resource Conservation Mode.
• Volume: It is important to have an understanding of the “normal” message volume and the “usual” spikes
in your environment. Track this data over time to measure volume growth. You can use the Incoming
Mail and Outgoing Mail pages to track volume over time. For more information, see System Capacity-
Incoming Mail, on page 861 and System Capacity-Outgoing Mail, on page 861.
• Work Queue: The work queue is designed to work as a “shock absorber”-- absorbing and filtering spam
attacks and processing unusual increases in ham messages. However, the work queue is also the best
indicator of a system under stress, prolonged and frequent work queue backups may indicate a capacity
problem. You can use the WorkQueue page to track the average time messages spend in the work queue
and the activity in your work queue. For more information, see System Capacity- Workqueue, on page
860.
• Resource Conservation Mode: When an email gateway becomes overloaded, it will enter “Resource
Conservation Mode” (RCM) and send a CRITICAL system alert. This is designed to protect the device
and allow it to process any backlog of messages. Your email gateway should enter RCM infrequently
and only during a very large or unusual increase in mail volume. Frequent RCM alerts may be an indication
that the system is becoming overloaded. See System Capacity-System Load, on page 861.
Related Topics
• System Capacity- Workqueue, on page 860
• System Capacity- Incoming Mail, on page 861
• System Capacity-Outgoing Mail, on page 861
• System Capacity-System Load, on page 861
• Note about Memory Page Swapping, on page 862
• System Capacity- All, on page 862
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
878
Using Email Security Monitor
System Capacity- Workqueue
System Capacity- Workqueue
The Workqueue page shows the average time a message spends in the work queue, excluding any time spent
in the Spam quarantine or in a policy, virus, or outbreak quarantine. You can view time periods from an hour
up to one month. This average can help in identifying both short term events delaying mail delivery and
identify long term trends in the workload on the system.
Note If a message is released from the quarantine into the work queue, the “average time in work queue” metric
ignores this time. This prevents double-counting and distorted statistics due to extended time spent in a
quarantine.
The report also shows the volume of messages in the work queue over a specified time period, and it shows
the maximum messages in the work queue over the same time period. The graphical representation of the
maximum messages in the work queue also shows the work queue threshold level.
Occasional spikes in the Workqueue graphs are normal and expected. If the messages in the work queue
remain higher than the configured threshold for a long duration, this may indicate a capacity issue. In this
scenario, consider tuning the threshold level or review the system configuration.
For instructions to change the work queue threshold level, see Setting Thresholds for System Health Parameters,
on page 1041.
Tip When reviewing the work queue page, you may want to measure the frequency of work queue backups, and
take note of work queue backups that exceed 10,000 messages.
System Capacity- Incoming Mail
The incoming mail page shows incoming connections, the total number of incoming messages, the average
message size, and the total incoming message size. You can limit the results to the time range that you specify.
It is important to have an understanding of the trends of normal message volume and spikes in your environment.
You can use the incoming mail page to help track volume growth over time and plan for system capacity.
You might also want to compare the Incoming Mail data with the Sender Profile data to view the trends in
volumes of emails that are being sent from specific domains to your network.
Note An increased number of incoming connections may not necessarily affect system load.
System Capacity-Outgoing Mail
The outgoing mail page shows outgoing connections, the total number of outgoing messages, the average
message size, and the total outgoing message size. You can limit the results to the time range that you specify.
It is important to have an understanding of the trends of normal message volume and spikes in your environment.
You can use the outgoing mail page to help track volume growth over time and plan for system capacity. You
might also want to compare the Outgoing Mail data with the Outgoing Destinations data to view the trends
in volumes of emails that are being sent from specific domains or IP addresses.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
879
Using Email Security Monitor
System Capacity-System Load
System Capacity-System Load
The system load report shows the following:
• Overall CPU Usage
• Memory Page Swapping
• Resource Conservation Activity
Overall CPU Usage
The email gateway is optimized to use idle CPU resources to improve message throughput. High CPU usage
may not indicate a system capacity problem. If the high CPU usage is coupled with consistent, high-volume
memory page swapping, you may have a capacity problem.
Note This graph also shows the threshold level for CPU usage. If you want to change the threshold level, use the
System Administration > System Health page in web interface or healthconfig command in CLI. See
Setting Thresholds for System Health Parameters, on page 1041.
This page also shows a graph that displays the amount of CPU used by different functions, including mail
processing, spam and virus engines, reporting, and quarantines. The CPU-by-function graph is a good indicator
of which areas of the product use the most resources on your system. If you need to optimize your email
gateway, this graph can help you determine which functions may need to be tuned or disabled.
Memory Page Swapping
The memory page swapping graph shows how frequently the system must page to disk. This graph also shows
the threshold level for memory page swapping. If you want to change the threshold level, use the System
Administration > System Health page in web interface or healthconfig command in CLI. See Setting
Thresholds for System Health Parameters, on page 1041.
Resource Conservation Activity
The resource conservation activity graph shows the number of times the email gateway entered Resource
Conservation Mode (RCM). For example, if the graph shows n times, it means that the email gateway has
entered RCM n times and exited at least n-1 times.
Your email gateway should enter RCM infrequently and only during a very large or unusual increase in mail
volume. If the Resource Conservation Activity graph shows that your email gateway is entering RCS frequently,
it may be an indication that the system is becoming overloaded.
Note about Memory Page Swapping
The system is designed to swap memory regularly, so some memory swapping is expected and is not an
indication of problems with your email gateway. Unless the system consistently swaps memory in high
volumes, memory swapping is normal and expected behavior, especially on C170 and C190 appliances. To
improve performance, you may need to add email gateways to your network or tune your configuration to
ensure maximum throughput.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
880
Using Email Security Monitor
System Capacity- All
System Capacity- All
The All page consolidates all the previous system capacity reports onto a single page so you can view the
relationship between the different reports. For example, you might view the message queue is high at the same
time that excessive memory swapping takes place. This might be an indication that you have a capacity
problem. You may want to save this page as PDF to preserve a snapshot of system performance for later
reference (or to share with support staff). For information about generating PDFs in languages other than
English, see the Notes on Reports, on page 909.
Reporting Data Availability
The Reporting Data Availability page allows you to view data to provide real-time visibility into resource
utilization and email traffic trouble spots.
All data resource utilization and email traffic trouble spots are shown from this page, including the data
availability for the overall email gateways that are managed by the Cisco Secure Email and Web Manager.
From this report page you can also view the data availability for a specific email gateway and time range.
Advanced Malware Protection Page
Advanced Malware Protection protects against zero-day and targeted file-based threats in email attachments
by:
• Obtaining the reputation of known files.
• Analyzing behavior of certain files that are not yet known to the reputation service.
• Evaluating emerging threats as new information becomes available, and notifying you about files that
are determined to be threats after they have entered your network.
This feature is available for incoming and outgoing messages.
For more information on the file reputation filtering and file analysis, see the User Guide or Online Help for
AsyncOS for Cisco Secure Email Gateway.
To view the report page, select Advanced Malware Protection from the File and Malware Reports section
of the Reports drop-down.
The Advanced Malware Protection report page shows the following reporting views:
• Advanced Malware Protection – Summary, on page 882
• Advanced Malware Protection – AMP Reputation, on page 882
• Advanced Malware Protection – File Analysis, on page 883
• Advanced Malware Protection – File Retrospection, on page 884
• Advanced Malware Protection – Mailbox Auto Remediation, on page 884
The Advanced Malware Protection report page displays a metrics bar that provides real time data of the email
gateway connected to the Cisco Threat Grid appliance.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
881
Using Email Security Monitor
Advanced Malware Protection – Summary
Note • You must use the trailblazerconfig > enable command on the CLI to populate data on the metrics
bar. For more information, see the Cisco Email Security Command Reference Guide.
• You can only view the data from the Cisco Threat Grid appliance for the day, week and month.
Related Topics
• Identifying Files by SHA-256 Hash , on page 885
• Viewing File Reputation Filtering Data in Other Reports , on page 885
Advanced Malware Protection – Summary
The Advanced Malware Protection - Summary page shows the complete summary of the incoming and
outgoing file-based threats that are identified by the file reputation and file analysis service.
For more information, see Advanced Malware Protection – AMP Reputation, on page 882 and Advanced
Malware Protection – File Analysis, on page 883.
Advanced Malware Protection – AMP Reputation
The Advanced Malware Protection - AMP Reputation page shows incoming and outgoing file-based threats
that were identified by the file reputation service.
For files with changed verdicts, see the AMP Verdict updates report. Those verdicts are not reflected in the
Advanced Malware Protection report.
If a file extracted from a compressed or archived file is malicious, only the SHA value of the compressed or
archived file is included in the Advanced Malware Protection report.
The Incoming files handled by AMPsection shows the incoming malware files by different categories such
as malicious, clean, unknown, unscanable, and low risk.
Incoming malicious files are categorized as the following:
• The percentage of block listed file SHAs received from the AMP reputation server that are categorized
as Malware.
• The percentage of block listed file SHAs received from the AMP for Endpoints console that are categorised
as Custom Detection. The threat name of a block listed file SHA obtained from AMP for Endpoints
console is displayed as Simple Custom Detection in the Incoming Malware Threat Files section of the
report.
• The percentage of block listed file SHAs based on the threshold settings that are categorised as Custom
Threshold.
You can click on the link in the More Details section of the report to view the file trajectory details of a block
listed file SHA in the AMP for Endpoints console.
You can view the Low Risk verdict details in the Incoming Files Handed by AMP section of the report.
You can use the AMP Reputation view of the Advanced Malware Protection: Incoming report page to view:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
882
Using Email Security Monitor
Advanced Malware Protection – File Analysis
• The summary of incoming files that are identified by file reputation service of the Advanced Malware
Protection engine, in a graphical format.
• A trend graph for all the incoming malware threat files based on the selected time range.
• The top incoming malware threat files.
• The top incoming threat files based on the file types.
• The Incoming Malware Threat Files interactive table that lists the top incoming malware threat files.
Drill down to view detailed analysis results, including the threat characteristics for each file.
If your access privileges allow you to view Message Tracking data for the messages that populate this
report, click a blue number link in the table.
You can use the AMP Reputation view of the Advanced Malware Protection: Outgoing report page to view:
• The summary of outgoing files that are identified by file reputation service of the Advanced Malware
Protection engine, in a graphical format.
• A trend graph for all the outgoing malware threat files based on the selected time range.
• The top outgoing malware threat files.
• The top outgoing threat files based on the file types.
• The Outgoing Malware Threat Files interactive table that lists the top outgoing malware threat files that
are identified by the file reputation service.
Drill down to view detailed analysis results, including the threat characteristics for each file.
If your access privileges allow you to view Message Tracking data for the messages that populate this
report, click a blue number link in the table.
Advanced Malware Protection – File Analysis
The Advanced Malware Protection - File Analysis page shows the time and verdict (or interim verdict) for
each file sent for analysis. The email gateway checks for analysis results every 30 minutes.
To view more than 1000 File Analysis results, export the data as a .csv file.
For deployments with an on-premises Cisco AMP Threat Grid Appliance: Files that are allow listed on the
AMP Threat Grid appliance show as "clean". For information about allow listing, see the AMP Threat Grid
documentation or online help.
Drill down to view detailed analysis results, including the threat characteristics for each file.
You can also search for additional information about an SHA, or click the link at the bottom of the file analysis
details page to view additional details on the server that analyzed the file. For more information, see Identifying
Files by SHA-256 Hash , on page 885.
If your access privileges allow you to view Message Tracking data for the messages that populate this report,
click the Details link in the table.
If a file extracted from a compressed or archived file is sent for analysis, only the SHA value of the extracted
file is included in the File Analysis report.
You can use the File Analysis view of the Advanced Malware Protection report page to view:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
883
Using Email Security Monitor
Advanced Malware Protection – File Retrospection
• The number of incoming and outgoing files that are uploaded for file analysis by file analysis service of
the Advanced Malware Protection engine.
• A list of incoming and outgoing files that have completed file analysis requests.
• A list of incoming and outgoing files that have pending file analysis requests.
Advanced Malware Protection – File Retrospection
The Advanced Malware Protection - File Retrospection page lists the files processed by this email gateway
for which the verdict has changed since the message was received. For more information about on this scenario,
see the documentation for your email gateway.
As Advanced Malware Protection is focused on targeted and zero-day threats, threat verdicts can change as
aggregated data might unviel more information.
To view more than 1000 verdict updates, export the data as a .csv file.
In the case of multiple verdict changes for a single SHA-256, this report shows only the latest verdict, not the
verdict history.
To view all affected messages for a particular SHA-256 within the maximum available time range (regardless
of the time range selected for the report) click a SHA-256 link.
You can use the File Retrospection view of the Advanced Malware Protection report page to view:
• A list of incoming and outgoing files with retrospective verdict changes.
Advanced Malware Protection – Mailbox Auto Remediation
The Advanced Malware Protection - Mailbox Auto Remediation report page shows the details of the mailbox
remediation results for the incoming files.
You can use the Advanced Malware Protection - Mailbox Auto Remediation page to view retrospective
security details such as:
• A list of recipients for whom the mailbox remediation was successful or unsuccessful
• Remedial actions taken on messages
• The filenames associated with a SHA-256 hash
• A list of profile names defined for the recipients for whom the mailbox remediation was successful or
unsuccessful
• Reason for the remediation failure
• No profile mapped to the domain
The Recipients for whom remediation was unsuccessful field is updated in the following scenario:
• Invalid Mailbox: The recipient is not a valid Microsoft Exchange online or Microsoft Exchange on-premise
user, or the recipient does not belong to the Microsoft Exchange online or an Microsoft Exchange
on-premise domain account configured on your email gateway.
• The message containing the attachment is no longer available in the mailbox, for example, the end user
deleted the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
884
Using Email Security Monitor
Identifying Files by SHA-256 Hash
• Authentication Error: The user account provided on your email gateway to connect to the Microsoft
Exchange on-premise mailbox is incorrect.
• Connection Error: There is a connectivity issue between your email gateway and Microsoft Exchange
online or Microsoft Exchange on-premise services when the email gateway attempts to perform the
remedial action.
• Permission Error:
• In case of a Microsoft Exchange on-premise account, the user account provided on your email
gateway to connect to the Microsoft Exchange on-premise mailbox is not assigned the impersonator
role.
• In case of a Microsoft Exchange online account, the Office 365 application does not have the required
permission to access the recipient mailbox.
• No Profile Mapped for domain: There is no profile mapped to the recipient domain.
• Mailbox is Inaccessible or Invalid:
• The profile type of the account profile that is used to access the mailbox is incorrect.
• The recipient is not a valid Microsoft Exchange online or Microsoft Exchange on-premise user.
• The recipient does not belong to the Microsoft Exchange online or an Microsoft Exchange on-premise
domain account configured on your email gateway.
Click on a SHA-256 hash to view the related messages in Message Tracking.
Identifying Files by SHA-256 Hash
Because filenames can easily be changed, the appliance generates an identifier for each file using a Secure
Hash Algorithm (SHA-256). If an appliance processes the same file with different names, all instances are
recognized as the same SHA-256. If multiple appliances process the same file, all instances of the file have
the same SHA-256 identifier.
In most reports, files are listed by their SHA-256 value (in an abbreviated format).
Viewing File Reputation Filtering Data in Other Reports
Data for file reputation and analysis is available in other reports where relevant. A Detected by Advanced
Malware Protection column may be hidden by default in applicable reports. To display additional columns,
click the Customize Columns icon at the top right side of the table.
Virus Filtering Page
The Virus Filtering page provides an overview of the viruses entering and being sent from your network. The
Virus Filtering page displays the viruses that have been detected by the virus scanning engines running on
your email gateway. You might want to use this report to take a specific action against a particular virus. For
example, if you see that you are receiving a high volume of a viruses known to be embedded in PDF files,
you might want to create a filter action to quarantine messages with PDF attachments.
If you run multiple virus scanning engines, the Virus Filtering page includes results from all enabled virus
scanning engines. The name of the virus displayed on the page is a name determined by the virus scanning
engines. If more than one scanning engine detects a virus, it is possible to have more than one entry for the
same virus.
The Virus Filtering page gives you an overview of the viruses entering or being sent from or to your network.
The Top Incoming Virus Detected section shows a chart view of the viruses that have been sent to your
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
885
Using Email Security Monitor
Macro Detection Page
network in descending order. The Top Outgoing Virus Detected section shows a chart view of the viruses
that have been sent from your network in descending order.
Note To see which hosts sent virus-infected messages to your network, you can go to the Incoming Mail page,
specify the same reporting period and sort by virus-positive. Similarly, to see which IP addresses have sent
virus-positive email within your network, you can view the Outgoing Senders page and sort by virus-positive
messages.
The VirusTypes Details listing displays information about specific viruses, including the infected incoming
and outgoing messages, and the total infected messages. The details listing for infected incoming messages
displays the name of the virus and the number of incoming messages infected with this virus. Similarly, the
outgoing messages displays the name of the virus and the number of outgoing messages infected with the
virus. You can sort the Virus Type details by Incoming Messages, Outgoing Messages, or Total Infected
Messages.
Macro Detection Page
You can use the Macro Detection report page to view:
• Top and summary of Incoming Macro-Enabled Attachments by File Type in graphical and tabular format.
• Top and summary Outgoing Macro-Enabled Attachments by File Type in graphical and tabular format.
You can click on the number of macro-enabled attachments to view the related messages in Message Tracking.
To view the Macro Detection report page on the email gateway, select Macro Detection from the Reports
drop-down.
Note During report generation:
• If one or more macros are detected within an archive file, the Archive Files file type is incremented by
one. The number of macro-enabled attachments within an archive file are not counted.
• If one or more macros are detected within an embedded file, the parent file type is incremented by one.
The number of macro-enabled attachments within an embedded file are not counted.
DMARC Verification Page
The DMARC Verification page shows the top domains that failed DMARC verification and the details of
actions AsyncOS performed on the messages that failed DMARC verification. You can use this report to
fine-tune your DMARC settings and answer these kinds of questions:
• Which are the domains that sent maximum number of messages that are not DMARC compliant?
• For each domain, what are the actions AsyncOS performed on the messages that failed DMARC
verification?
The DMARC Verification page contains:
• A graphical representation showing top domains by DMARC verification failures.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
886
Using Email Security Monitor
URL Filtering Page
• Tabular representation of the following, for each domain:
• Number of messages that were rejected, quarantined, or accepted without taking any action. Click
the number to view a list of messages under the selected category.
• Number messages that passed DMARC verification.
• Total number of DMARC verification attempts.
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link.
URL Filtering Page
• URL Filtering report modules are populated only if URL filtering is enabled.
• URL Filtering reports are available for incoming and outgoing messages.
• Only messages that are scanned by the URL filtering engine (either as part of anti-spam/outbreak filter
scanning or through message/content filters) are included in these modules. However, not all of the results
are necessarily specifically attributable to the URL Filtering feature.
• The Top URL Categories module includes all categories found in messages that have been scanned,
whether or not they match a content or message filter.
• Each message can be associated with only one URL reputation level. For messages with multiple URLs,
the statistics reflect the lowest reputation of any URL in the message.
• URLs in the global allowed list configured at Security Services > URL Filtering are not included in
reports.
URLs in allowed lists used in individual filters are included in reports.
• Malicious URLs are URLs that Outbreak Filters have determined to have poor reputation. Neutral URLs
are those that Outbreak Filters have determined to require click-time protection. Neutral URLs have
therefore been rewritten to redirect them to the Cisco Web Security proxy.
• Results of URL category-based filters are reflected in content and message filter reports.
• Results of click-time URL evaluations by the Cisco Web Security proxy are not reflected in reports.
Outbreak Filtering Page
The Outbreak Filtering report page shows information about recent outbreaks and messages quarantined due
to Outbreak Filters. You can use this page to monitor your defense against targeted virus, scam, and phishing
attacks.
Use the Outbreak Filtering report page to answer the following types of questions:
• How many messages are quarantined and by which Outbreak Filters rule?
• How long do messages stay in the Outbreak Quarantine?
• Which potentially malicious URLs are most frequently seen?
To view the Outbreak Filtering report page , select Outbreak Filtering from the Reports drop-down.
The following table explains the various sections on the Outbreak Filtering report page:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
887
Using Email Security Monitor
Outbreak Filtering Page
Table 89: Details on the Outbreak Filtering Page
Section Description
Time Range (drop-down list) A drop-down list with options for choosing a time range to view.
Threats By Type The Threats by Type section shows the different types of threat
messages received by the email gateway.
Threat Summary The Threat Summary section shows a breakdown of the messages by
Malware, Phish, Scam and Virus.
To view Message Tracking details for the messages that populate this
report, click a blue number link in the table.
Threat Details The Threat Details interactive table shows details about specific
outbreaks, including the threat category (virus, scam, or phishing),
threat name, a description of the threat, and the number of messages
identified.
To view Message Tracking details for the messages that populate this
report, click a blue number link in the table.
Hit Messages from Incoming The Hit Messages from Incoming Messages section shows the chart
Messages and summary of the number of incoming messages processed by
Outbreak Filters in the selected time period.
Non-viral threats include phishing emails, scams, and malware
distribution using links to an external website.
Hit Messages by Threat Level The Hit Messages by Threat Level section shows the chart and
summary of the severity of threats caught by Outbreak Filters.
Level 5 threats are severe in scope or impact, while Level 1 represents
low threat risk. For descriptions of threat levels, see the online help
or user guide for your email gateway.
Messages resided in Outbreak The Messages resided in Outbreak Quarantine shows the length of
Quarantine time messages spent in the Outbreak Quarantine.
This duration is determined by the time it takes the system to compile
enough data about the potential threat to make a verdict on its safety.
Messages with viral threats typically spend more time in the quarantine
than those with non-viral threats, because they must wait for anti-virus
program updates. The maximum retention time that you specify for
each mail policy is also reflected.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
888
Using Email Security Monitor
Forged Email Detection Page
Section Description
Top URL’s Rewritten The Top URL’s Rewritten section shows the URLs that are most
frequently rewritten to redirect message recipients to the Cisco Web
Security Proxy for click-time evaluation of the site if and when the
recipient clicks a potentially malicious link in a message.
This list may include URLs that are not malicious, because if any
URL in a message is deemed malicious, then all URLs in the message
are rewritten.
To view Message Tracking details for the messages that populate this
report, click a blue number link in the table.
Note In order to correctly populate the tables on the Outbreak Filtering report page, the email gateway must be able
to communicate with the Cisco update servers.
Forged Email Detection Page
The Forged Email Detection page includes the following reports:
• Top Forged Email Detection. Displays the top ten users in the content dictionary that matched the
forged From: header in the incoming messages.
• Forged Email Detection: Details. Displays a list of all the users in the content dictionary that matched
the forged From: header in the incoming messages and for a given user, the number of messages matched.
To view the Forged Email Detection report page on the Security Management appliance, select Forged Email
Detection from the Reports drop-down.
The Forged Email Detection reports are populated only if you are using the Forged Email Detection content
filter or the forged-email-detection message filter.
From the Forged Email Detection report page you can export raw data to a CSV file. Click Export link on
the top of a report page. Select the required report module that you want to export and click Download.
Sender Domain Reputation Page
You can use the Sender Domain Reputation report page to view:
• Incoming messages based on the verdict received from the SDR service in graphical format.
• Incoming messages based on the threat category received from the SDR service in graphical format.
Note Only the messages whose SDR verdict is 'awful' or 'poor' are classified under the
SDR threat category, such as, 'spam,' 'malicious,' etc.
• Summary of incoming messages based on the threat category received from the SDR service in tabular
format.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
889
Using Email Security Monitor
External Threat Feeds Page
To view the Sender Domain Reputation report page on the Security Management appliance, select Sender
Domain Reputation from the Reports drop-down.
External Threat Feeds Page
You can use the External Threat Feeds report page to view:
• Top ETF sources used to detect threats in messages in graphical format
• Summary of ETF sources used to detect threats in messages in tabular format.
• Top IOCs that matched threats detected in messages in graphical format.
• Top ETF sources used to filter malicious incoming mail connections in graphical format.
• Summary of ETF sources used to filter malicious incoming mail connections in tabular format.
In the ‘Summary of External Threat Feed Sources’ section:
• You can click on the number of messages for a particular ETF source to view the related messages in
Message Tracking.
• You can click on a particular threat feed source to view the distribution of the ETF source based on the
IOCs.
In the ‘Summary of Indicator of Compromise (IOC) Matches’ section:
• You can click on the number of IOCs for a particular ETF source to view the related messages in Message
Tracking.
• You can click on a particular IOC to view the distribution of the IOC based on the ETF sources.
To view the External Threat Feeds report page, select External Threat Feeds from the Reports drop-down.
Mail Flow Details Page
The Mail Flow Details report page provides interactive reporting on the real-time information for all remote
hosts connecting to your managed Cisco Secure Email and Web Manager. You can gather information about
the IP addresses, domains, and network owners (organizations) sending mail to your system. You can also
gather information about the IP addresses and domains of the outgoing senders.
To view the Mail Flow Details report page, select Mail Flow Details from the Reports drop-down.
The Mail Flow Details report page has the following tabs:
• Incoming Mails
• Outgoing Senders
To search for specific information within your data, see Searching and the Interactive Email Report Pages ,
on page 869.
From the Incoming Mails tab, you can:
• View the top senders by total threat messages in graphical format.
• View the top senders by clean messages in graphical format.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
890
Using Email Security Monitor
Views Within the Mail Flow Details Page
• View the top senders by graymail messages in graphical format.
• See the IP addresses, domains, or network owners (organizations) that have sent mail to your Cisco
Secure Email and Web Manager.
• See detailed statistics on senders that have sent mail to your email gateways. The statistics include the
number of connections (accepted or rejected), attempted messages broken down by security service
(sender reputation filtering, anti-spam, anti-virus, and so forth), total threat messages, total graymails
and clean messages.
• See the Incoming Mails interactive table for the detailed information about the particular IP address,
domain, or network owner (organization). For more information, see Incoming Mails Table, on page 893.
If your access privileges allow you to view Message Tracking data for the messages that populate this
report, click a number hyperlink in the table.
From the Outgoing Senders tab, you can:
• View the top senders by total threat messages in graphical format.
• View the top senders by clean messages in graphical format.
• View the top senders (by IP address or domain) of outgoing threat messages (spam, antivirus, etc.) in
your organization.
• See detailed statistics on senders that have sent mail from your email gateways. The statistics include
the total threat messages broken down by security service (sender reputation filtering, anti-spam, anti-virus,
and so forth) and clean messages.
• See the Sender Details interactive table for detailed information about the particular IP address or domain.
For more information, see Sender Details Table, on page 897.
If your access privileges allow you to view Message Tracking data for the messages that populate this
report, click a number hyperlink in the table.
Related Topics
• Incoming Mails Table, on page 893
• “No Domain Information”, on page 892
• Time Range for Reports, on page 870
• Views Within the Mail Flow Details Page, on page 891
Views Within the Mail Flow Details Page
The Mail Flow Details: Incoming report page has three different views:
• IP Addresses
• Domains
• Network Owners
These views provide a snapshot of the remote hosts connecting to the system in the context of the selected
view.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
891
Using Email Security Monitor
“No Domain Information”
Additionally, in the Incoming Mail table of the Mail Flow Details page, you can click on a Sender’s IP Address,
Domain name, or Network Owner Information to retrieve specific Sender Profile Information. For more
information on Sender Profile information, see the Sender Profile Pages, on page 896.
Note Network owners are entities that contain domains. Domains are entities that contain IP addresses.
Depending on the view you select, the Incoming Mail Details interactive table displays the top IP addresses,
domains, or network owners that have sent mail to all public listeners configured on the email gateways. You
can monitor the flow of all mail into your email gateways.
Click an IP address, domain, or network owner to access details about the sender on the Sender Profile page.
The Sender Profile page is an Mail Flow Details page that is specific to a particular IP address, domain, or
network owner.
See the Incoming Mails Table, on page 893 for an explanation of the data included in the Incoming Mails
interactive table.
From the Mail Flow Details page you can export raw data to a CSV file.
Note You can generate a scheduled report for the Mail Flow Details report page. See the Scheduled Reports, on
page 910.
The Mail Flow Details: Outgoing report page has two different views:
• IP Addresses
• Domains
These views provide a snapshot of the remote hosts connecting to the system in the context of the selected
view.
Depending on the view you select, the Sender Details interactive table displays the top IP addresses or domains
of the senders that have sent mail from the public listeners configured from the Email Security appliances.
You can monitor the flow of all mail from your email gateways.
See the Sender Details Table, on page 897 for an explanation of the data included in the Sender Details
interactive table.
“No Domain Information”
Domains which have connected to the email gateway and could not be verified with a double-DNS lookup
are automatically grouped into the special domain “No Domain Information.” You can control how these
types of unverified hosts are managed via Sender Verification. See Configuring the Gateway to Receive Email,
on page 77.
You can select the number of senders to show in the listing via the Items Displayed menu.
Time Range for Reports
The Email Security Monitor feature constantly records data about the mail flowing into your gateway. The
data are updated every 60 seconds, but the display shown is delayed by 120 seconds behind the current system
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
892
Using Email Security Monitor
Incoming Mails Table
time. You can specify the time range to include in the results shown. Because the data is monitored in real
time, information is periodically updated and summarized in the database.
Choose from the time range options in the following table.
Table 90: Time Ranges Available in the Email Security Monitor Feature
This time range selected in the GUI ...is defined as:
Hour the last 60 minutes + up to 5 minutes
Day the last 24 hours + the last 60 minutes
Week the last 7 days + the elapsed hours of the current day
30 days the last 30 days + the elapsed hours of the current day
90 days the last 90 days + the elapsed hours of the current day
Yesterday 00:00 to 23:59 (midnight to 11:59 PM)
Previous Calendar Month 00:00 of the first day of the month to 23:59 of the last day of the
month
Custom Range the range enclosed by the start date and hour and the end date and
hour that you specify
Incoming Mails Table
The interactive Incoming Mails table at the bottom of the Mail Flow Details: Incoming Mails page lists the
top senders that have connected to public listeners on the email gateways. The table shows domains, IP
addresses, or network owners, based on the view selected.
The system acquires and verifies the validity of the remote host’s IP address by performing a double DNS
lookup. For more information about double DNS lookups and sender verification, see the user guide or online
help for the email gateway
For senders, that is Network Owner, IP Address or Domain, listed in the first column of the Incoming Mails
table, or on the Top Senders by Total Threat Messages, click the Sender or No Domain Information link to
view more information about the sender. The results appear on a Sender Profile page, which includes real-time
information from the IP Reputation Service. From the Sender Profile page, you can view for more information
about specific IP addresses or network owners. For more information, see the Sender Profile Pages, on page
896.
You can also view the Sender Groups report, by clicking Sender Groups report at the bottom of the Mail Flow
Details page. For more information about the Sender Groups report page, see the Sender Groups Report, on
page 898.
To view Message Tracking details for the messages that populate this report, click a number hyperlink in the
table.
The following table shows the table column descriptions for the Incoming Mails table:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
893
Using Email Security Monitor
Incoming Mails Table
Table 91: Table Column Descriptions for Incoming Mail Table
Column Name Description
Sender Domain (Domains) The domain name of the sender.
Sender IP Address (IP The IP address of the sender.
Addresses)
Hostname (IP Addresses) The hostname of the sender.
DNS Verified (IP Addresses) The IP addresses that are verified by the DNS.
IP Reputation Score (IP The IP Reputation Score of the sender.
Addresses)
Last Sender Group (IP The details of the last sender group.
Addresses)
Last Sender Group (IP The details of the last sender group.
Addresses)
Network Owner (Network The network owner of the sender.
Owners)
Connections Rejected All connections blocked by HAT policies. When the email gateway is under
(Domains and Network heavy load, an exact count of rejected connections is not maintained on a
Owners) per-sender basis. Instead, rejected connections counts are maintained only
for the most significant senders in each time interval.
Connections Accepted All connections accepted,
(Domains and Network
Owners)
Total Attempted All accepted and blocked connections attempted.
Stopped by Recipient This is a component of Stopped by Reputation Filtering. It represents the
Throttling (Domains and number of recipient messages stopped because any of the following HAT
Network Owners) limits have been exceeded: maximum recipients per hour, maximum recipients
per message, or maximum messages per connection. This is summed with
an estimate of the recipient messages associated with rejected or TCP refused
connections to yield Stopped by Reputation Filtering.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
894
Using Email Security Monitor
Incoming Mails Table
Column Name Description
Stopped by IP Reputation The value for Stopped by IPReputation Filtering is calculated based on several
Filtering factors:
• Number of “throttled” messages from this sender
• Number of rejected or TCP refused connections (may be a partial count)
• A conservative multiplier for the number of messages per connection.
When the email gateway is under heavy load, an exact count of rejected
connections is not maintained on a per-sender basis. Instead, rejected
connections counts are maintained only for the most significant senders in
each time interval. In this situation, the value shown can be interpreted as a
“floor”; that is, at least this many messages are stopped.
Note The IP Reputation Filtering total on the Mail Flow Summary page
is always based on a complete count of all rejected connections.
Only the per-sender connection counts are limited due to load.
Stopped by Domain The total count of messages blocked based on the reputation verdict of the
Reputation Filtering sender domain.
Stopped as Invalid Recipients All mail recipients rejected by conversational LDAP rejection plus all RAT
rejections.
Spam Detected Any spam that has been detected.
Virus Detected Any viruses that have been detected
Detected by Advanced The total count of messages detected by Advanced Malware Protection
Malware Protection engines.
Stopped by Content Filter The total count of messages that are stopped by a content filter.
Stopped by DMARC The total count of messages that failed Domain-based Message Authentication,
Reporting and Conformance (DMARC) verification.
Total Threat Total number of threat messages (stopped by reputation, stopped as invalid
recipient, spam, plus virus)
Marketing Number of messages detected as unwanted marketing messages.
Social Number of messages detected as social messages.
Bulk Number of messages detected as bulk.
Total Graymails Number of messages detected as graymails.
Clean All clean messages.
Messages processed on email gateways on which the graymail feature is not
enabled are counted as clean.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
895
Using Email Security Monitor
Sender Profile Pages
Sender Profile Pages
When you click a sender in the Incoming Mail Details interactive table, on the Mail Flow Details [New Web
Interface] or Incoming Mail page, the Sender Profile page appears. It shows detailed information about the
particular IP address, domain, or network owner (organization). You can access a Sender Profile page for any
IP address, domain, or network owner by clicking the corresponding link on the Incoming Mail page or on
other Sender Profile pages.
Network owners are entities that contain domains. Domains are entities that contain IP addresses.
The Sender Profile pages displayed for IP addresses, domains, and network owners vary slightly. For each,
the page contains a graph and summary table for incoming mail from the particular sender. Below the graph,
a table lists the domains or IP addresses associated with the sender. (The Sender Profile page for an individual
IP address does not contain a more granular listing.) The Sender Profile page also includes an information
section with the current SenderBase, sender group, and network information for the sender.
• Network Owner profile pages contain information for the network owner, as well as the domains and IP
addresses associated with that network owner.
• Domain profile pages contain information for the domains and IP addresses associated with that domain.
• IP address profile pages contain information about the IP address only.
Each Sender Profile page contains the following data in the Current Information table at the bottom of the
page:
• The global information from the IP Reputation Service, including:
• IP address, domain name, and/or network owner
• Network owner category (network owner only)
• CIDR range (IP addresses only)
• Daily magnitude and monthly magnitude for the IP address, domain, and/or network owner
• Days since the first message was received from this sender
• Last sender group and whether DNS verified (IP address sender profile page only)
Daily magnitude is a measure of how many messages a domain has sent over the last 24 hours. Similar
to the Richter scale used to measure earthquakes, SenderBase magnitude is a measure of message volume
calculated using a log scale with a base of 10. The maximum theoretical value of the scale is set to 10,
which equates to 100% of the world's email message volume. Using the log scale, a one-point increase
in magnitude equates to a 10x increase in actual volume.
Monthly magnitude is calculated using the same approach as daily magnitude, except the percentages
are calculated based on the volume of email sent over the last 30 days.
• Average magnitude (IP addresses only)
• Lifetime volume / 30 day volume (IP address profile pages only)
• Bonded sender status (IP address profile pages only)
• IP Reputation Score (IP address profile pages only)
• Days since first message (network owner and domain profile pages only)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
896
Using Email Security Monitor
Sender Details Table
• Number of domains associated with this network owner (network owner and domain profile pages
only)
• Number of IP addresses in this network owner (network owner and domain profile pages only)
• Number of IP addresses used to send email (network owner pages only)
Click More from SenderBase to see a page with all information supplied by the IP Reputation Service.
• Details about the domains and IP addresses controlled by this network owner appear on network owner
profile pages. Details about the IP addresses in the domain appear on domain pages.
From a domain profile page, you can click on a specific IP address to view specific information, or view an
organization profile page.
Sender Details Table
The interactive Sender Details table at the bottom of the Mail Flow Details: Outgoing page lists the top senders
that have connected to public listeners on the email gateways. The table shows domains or IP addresses, based
on the view selected.
To view Message Tracking details for the messages that populate this report, click a number hyperlink in the
table.
The following table shows the table column descriptions for the Sender Details table:
Table 92: Table Column Descriptions for Sender Details Table
Column Name Description
Sender Domain (Domains) The domain name of the sender.
Sender IP Address (IP Addresses) The IP address of the sender.
Hostname (IP Addresses) The hostname of the sender.
Spam Detected Any spam that has been detected.
Virus Detected Any viruses that have been detected.
Detected by Advanced Malware The total count of messages detected by Advanced Malware Protection
Protection engines.
Stopped by Content Filter The total count of messages that are stopped by a content filter.
Stopped by DLP The total count of messages that are stopped by DLP engine.
Total Threat Total number of threat messages (spam, virus)
Clean All clean messages.
Messages processed on email gateways on which the graymail feature
is not enabled are counted as clean.
Total Messages The total count of all the messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
897
Using Email Security Monitor
Sender Groups Report
Sender Groups Report
The Sender Groups report provides a summary of connections by sender group and mail flow policy action,
allowing you to review SMTP connection and mail flow policy trends. The Mail Flow by Sender Group listing
shows the percentage and number of connections for each sender group. The Connections by Mail Flow Policy
Action chart shows the percentage of connections for each mail flow policy action. This page provides an
overview of the effectiveness of your Host Access Table (HAT) policies. For more information about the
HAT, see Configuring the Gateway to Receive Email, on page 77.
Outgoing Destinations
The Outgoing Destinations page provides information about the domains your company sends mail to. The
page consists of two sections. The top half of the page consists of graphs depicting the top destinations by
outgoing threat messages and top destinations by outgoing clean messages on the top half of the page. The
bottom half of the page displays a chart showing all the columns sorted by total recipients (default setting).
You can select a time range on which to report, such as a day, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link.
The Outgoing Destinations page can be used to answer the following types of questions:
• What domains is the email gateway sending mail to?
• How much mail is sent to each domain?
• How much of that mail is clean, spam-positive, virus-positive, malware or stopped by a content filter?
• How many messages are delivered and how many messages are hard-bounced by the destination server?
TLS Encryption Page
The TLS Encryption pages shows the overall usage of TLS Encryption for sent and received mail. The report
also shows details for each domain sending mail using TLS connections.
The TLS Encryption page can be used to determine the following information:
• Overall, what portion of incoming and outgoing connections use TLS?
• What partners do I have successful TLS connections with?
• What partners do I have unsuccessful TLS connections with?
• What partners do I have successful TLS connections with DANE support?
• What partners do I have unsuccessful TLS connections with DANE support?
• What partners have issue with their TLS certificates?
• What percent of overall mail with a partner uses TLS?
• What percent of outgoing TLS connections with DANE support are successful?
• What percent of outgoing connections with DANE support are unsuccessful?
The TLS Encryption page is divided into a section for incoming connections and a section for outgoing
connections. Each section includes a graph, summaries, and a table with details.
The graph displays a view of incoming or outgoing TLS-encrypted and non-encrypted connections over the
time range you specify. The graph displays the total volume of messages, the volume of encrypted and
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
898
Using Email Security Monitor
Inbound SMTP Authentication Page
unencrypted messages, the volume of successful and failed TLS encrypted messages and the volume of
successful and failed DANE connections. The graphs distinguish between connections in which TLS was
required and connections in which TLS was merely preferred.
The table displays details for domains sending or receiving encrypted messages. For each domain, you can
view the number of required and preferred TLS connections that were successful and that failed, the total
number of TLS connections attempted (whether successful or failed), the total number of unencrypted
connections, and the total number of unencrypted connections, and the total number of DANE connections
(depending on whether successful or failed). You can also view the percentage of all connections in which
TLS was attempted, and the total number of encrypted messages sent successfully, regardless of whether TLS
was preferred or required. You can show or hide columns by Customize Columns icon at the top right side
of the table.
Inbound SMTP Authentication Page
The Inbound SMTP Authentication page shows the use of client certificates and the SMTP AUTH command
to authenticate SMTP sessions between the email gateway and users’ mail clients. If the email gateway accepts
the certificate or SMTP AUTH command, it will establish a TLS connection to the mail client, which the
client will use to send a message. Since it is not possible for the email gateway to track these attempts on a
per-user basis, the report shows details on SMTP authentication based on the domain name and domain IP
address.
Use this report to determine the following information:
• Overall, how many incoming connection use SMTP authentication?
• How many connections use a client certificated?
• How many connections use SMTP AUTH?
• What domains are failing to connect when attempting to use SMTP authentication?
• How many connections are successfully using the fall-back when SMTP authentication fails?
The Inbound SMTP Authentication page includes a graph for received connections, a graph for mail recipients
who attempted an SMTP authentication connection, and a table with details on the attempts to authenticate
connections.
The Received Connections graph shows the incoming connections from mail clients that attempt to
authentication their connections using SMTP authentication over the time range you specify. The graph
displays the total number of connections the email gateway received, the number that did not attempt to
authenticate using SMTP authentication, the number that failed and succeeded to authenticate the connection
using a client certificate, and the number that failed and succeeded to authenticate using the SMTP AUTH
command.
The Received Recipients graph displays the number of recipients whose mail clients attempted to authenticate
their connections to the email gateways to send messages using SMTP authentication. The graph also show
the number of recipients whose connections were authenticated and the number of recipients whose connections
were not authenticated.
The SMTP Authentication details table displays details for the domains whose users attempt to authenticate
their connections to the email gateway to send messages. For each domain, you can view the number of
connection attempts using a client certificate that were successful or failed, the number of connection attempts
using the SMTP AUTH command that were successful or failed, and the number that fell back to the SMTP
AUTH after their client certificate connection attempt failed. You can use the tabs at the top of the page to
display this information by domain name or domain IP address.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
899
Using Email Security Monitor
Rate Limits Page
Rate Limits Page
Rate Limiting by envelope sender allows you to limit the number of email message recipients per time interval
from an individual sender, based on the mail-from address. The Rate Limits report shows you the senders
who most egregiously exceed this limit.
Use this report to help you identify the following:
• Compromised user accounts that might be used to send spam in bulk.
• Out-of-control applications in your organization that use email for notifications, alerts, automated
statements, etc.
• Sources of heavy email activity in your organization, for internal billing or resource-management purposes.
• Sources of large-volume inbound email traffic that might not otherwise be considered spam.
Note that other reports that include statistics for internal senders (such as Internal Users or Outgoing Senders)
measure only the number of messages sent; they do not identify senders of a few messages to a large number
of recipients.
The Top Offenders by Incident chart shows the envelope senders who most frequently attempted to send
messages to more recipients than the configured limit. Each attempt is one incident. This chart aggregates
incident counts from all listeners.
The Top Offenders by Rejected Recipients chart shows the envelope senders who sent messages to the largest
number of recipients above the configured limit. This chart aggregates recipient counts from all listeners.
To configure rate limiting by envelope sender or modify the existing rate limit, see Defining Rules for Incoming
Messages Using a Mail Flow Policy, on page 115.
Connections by Country Page
You can use the Connections by Country report page to view:
• Top incoming mail connections based on country of origin in graphical format.
• Total incoming mail connections based on country of origin in tabular format.
You can click on the number of incoming mail connections of a specific geolocation to view the related
messages in Message Tracking.
The "Total Messages" column only displays those messages that are accepted at the SMTP connection level.
Note During report generation:
• If one or more incoming mail connections are detected as private IP address, the incoming mail connections
are categorized as “Private IP Addresses” in the report.
• If one or more incoming mail connections are detected as not a valid IP Reputation score, the incoming
mail connections are categorized as ‘No Country Info’ in the report.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
900
Using Email Security Monitor
User Mail Summary Page
User Mail Summary Page
The User Mail Sumamry page provides information about the mail sent and received by your internal users,
per email address (a single user may have multiple email addresses listed — the email addresses are not
combined in the report).
The page consists of two sections:
• Graphs depicting the top users by clean incoming and outgoing messages and top users receiving graymail.
• User mail flow details
You can select a time range on which to report (hour, day, week, or month). As with all reports, you can export
the data for the graphs or the details listing to CSV format via the Export link. You can also display hidden
table columns or hide default columns by clicking the Customize Column icon on the top right side of the
table.
The User Mail Flow Details listing breaks down the mail received and sent by each email address into clean,
spam (incoming only), virus, malware, content filter matches, and graymail (incoming only). You can sort
the listing by clicking on the column headers.
Using the Internal Users report, you can answer these kinds of questions:
• Who is sending the most external email?
• Who receives the most clean email?
• Who receives the most number of graymail messages?
• Who receives the most spam?
• Who is triggering which content filters?
• Whose email is getting caught by content filters?
Inbound Internal Users are the users for which you received email, based on the Rcpt To: address. Outbound
Internal Users are based on the Mail From: address and are useful when tracking the types of email that senders
on your internal network are sending.
Note that some outbound mail (like bounces) have a null sender. They are counted under outbound and
“unknown.”
Click on an internal user to view the Internal User detail page for that user.
Click the Customize Columns icon on the top right side of the table to show columns that are hidden by default,
such as the Incoming Spam Detected by Intelligent Multi-Scan column or Outgoing Spam Detected by
Intelligent Multi-Scan column.
Related Topics
• User Mail Flow Details, on page 901
• Searching for a Specific Internal User, on page 850
User Mail Flow Details
The User Mail Flow details section shows detailed information about the specified user, including a breakdown
of incoming and outgoing messages showing the number of messages in each category (spam detected, virus
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
901
Using Email Security Monitor
Searching for a Specific Internal User
detected, detected by Advanced Malware Protection, stopped by content filter, graymail detected, and clean).
Optionally, for incoming messages, you can click the Customize Columns icon on the top right side of the
table to show the Incoming Spam Detected by Intelligent Multi-Scan column. This value reflects the number
messages that contained attachments that were determined by file reputation filtering to be malicious. It does
not include verdict updates or files found to be malicious by file analysis. Incoming and outgoing content
filter and DLP policy matches are also shown.
Click a content filter name to view detailed information for that filter in the corresponding content filter
information page (see Content Filters Page, on page 851). You can use this method to get a list of users who
also sent or received mail that matched that particular content filter.
Searching for a Specific Internal User
You can search for a specific internal user (email address) via the search form at the bottom User Mail Summary
page. Choose whether to exactly match the search text or look for items starting with the entered text (for
instance, starts with “ex” will match “example.com”).
DLP Incident Summary Page
The DLP Incident Summary page shows information on the incidents of data loss prevention (DLP) policy
violations occurring in outgoing mail. The email gateway uses the DLP email policies enabled in the Outgoing
Mail Policies table to detect sensitive data sent by your users. Every occurrence of an outgoing message
violating a DLP policy is reported as an incident.
Using the DLP Incidents report, you can answer these kinds of questions:
• What type of sensitive data is being sent by your users?
• How severe are these DLP incidents?
• How many of these messages are being delivered?
• How many of these messages are being dropped?
• Who is sending these messages?
The DLP Incident Summary page is comprised of two main sections:
• the DLP incident trend graphs summarizing the top DLP incidents by severity (Low, Medium, High,
Critical) and policy matches, and
• the DLP Incidents Details listing.
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link. For information
about generating PDFs in languages other than English, see the Notes on Reports, on page 909.
Click the name of a DLP policy to view detailed information on the DLP incidents detected by the policy.
You can use this method to get a list of users who sent mail that contained sensitive data detected by the
policy.
Related Topics
• DLP Incident Details, on page 903
• DLP Policy Detail Page, on page 903
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
902
Using Email Security Monitor
DLP Incident Details
DLP Incident Details
The DLP policies currently enabled in the email gateway's outgoing mail policies are listed in the DLP Incident
Details table. Click the name of a DLP policy to view more detailed information.
The DLP Incident Details table shows the total number of DLP incidents per policy, with a breakdown by
severity level. The severity level also includes the number of bounced messages and the number of messages
delivered in the clear, delivered encrypted, or dropped. Click the column headings to sort the data.
DLP Policy Detail Page
If you clicked the name of a DLP policy in the DLP Incident Details table, the resulting DLP Policy Detail
page displays the DLP incidents data for the policy. The page displays graphs on the DLP incidents based on
severity.
The page also includes an Incidents by Sender listing at the bottom of the page that lists each internal user
who has sent a message that violated the DLP policy. The listing also shows the total number of DLP incidents
for this policy per user, with a breakdown by severity level, and whether any of the messages were delivered
in the clear, delivered encrypted, or dropped. You can use the Incidents by Sender listing to find out which
users may be sending your organization’s sensitive data to people outside your network.
Clicking on the sender name opens up the Internal Users page. See #unique_1507 for more information.
Web Interaction Page
• Web Interaction Tracking report modules are populated only if the web interaction tracking feature is
enabled.
• Web Interaction Tracking report modules are not updated in real-time and are refreshed every 30 minutes.
Also, after clicking a rewritten URL, it may take up to two hours for the Web Interaction Tracking report
to report this event.
• Web Interaction Tracking report is not updated in real-time. After clicking a cloud re-directed rewritten
URL, it may take up to two hours for the Web Interaction Tracking report to report this event.
• Web Interaction Tracking reports are available for incoming and outgoing messages.
• Only cloud re-directed rewritten URLs (either by policy or Outbreak Filter) clicked by the end users are
included in these modules.
• Web Interaction Tracking page includes the following reports:
Top Malicious URLs clicked by End Users. Click on a URL to view a detailed report that contains the
following information:
• A list of end users who clicked on the rewritten malicious URL.
• Date and time at which the URL was clicked.
• Whether the URL was rewritten by a policy or an outbreak filter.
• Action taken (allow, block, or unknown) when the rewritten URL was clicked. Note that, if a URL was
rewritten by outbreak filter and the final verdict is unavailable, the status is shown as unknown.
Top End Users who clicked on Malicious URLs
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
903
Using Email Security Monitor
Remediation Report Page
This section displays the summary of the top end users who clicked on the Rewritten Malicious URLs, for
incoming and outgoing messages.
Web Interaction Tracking Details. Includes the following information:
• A list of all the cloud re-directed rewritten URLs (malicious and unmalicious). Click on a URL to view
a detailed report.
• Action taken (allow, block, or unknown) when a cloud re-directed rewritten URL was clicked.
For the data to show up, perform the following:
• Choose Incoming Mail Policies > Outbreak Filters to configure an outbreak filter and enable message
modification and URL rewriting.
• Configure a content filter with the "Redirect to Cisco Security Proxy" action.
Note that, if the verdict of a URL (clean or malicious) was unknown at the time when the end user clicked it,
the status is shown as unknown. This could be because the URL was under further scrutiny or the web server
was down or not reachable at the time of the user click.
• The number of times end users clicked on a rewritten URL. Click on a number to view a list of all the
messages that contain the clicked URL.
• While using Web Interaction Tracking reports, keep in mind the following limitations:
• If you have configured a content or message filter to deliver messages after rewriting malicious
URLs and notify another user (for example, an administrator), the web interaction tracking data of
the original recipient is incremented even if the notified user clicks on the rewritten URLs.
• If you are sending a copy of quarantined messages containing rewritten URLs to a user (for example,
an administrator) using web interface, the web interaction tracking data of the original recipient is
incremented even if the user (to whom the copy of the messages were sent) clicks on the rewritten
URLs.
• At any point, if you plan to modify the time of your email gateway, make sure that the system time
is synchronized with Coordinated Universal Time (UTC).
Remediation Report Page
You can use the Remediation report to monitor the remediation results for Mailbox Auto Remediation and
Mailbox Search and Remediate.
Use this report:
• To view the list of messages that are attempted for Mailbox Auto Remediation and Mailbox Search and
Remediate.
• To know the reason for remediation failure. For example, connections errors, authentication errors, and
so on.
The following list explains the various sections on the Rate Limit report:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
904
Using Email Security Monitor
Message Filters Page
Section Description
Summary The Summary section displays the following:
• Total number of messages attempted for remediation using Mailbox Auto
Remediation and Mailbox Search and Remediate.
• Number of messages successfully remediated for a configured remedial
action.
• Number of messages for which the remediation failed.
Mailbox Auto Remediation The Mailbox Auto Remediation report section displays the following:
• A list of recipients for whom the mailbox auto remediation was successful
or unsuccessful.
• Auto Remedial actions taken on messages.
• The filenames associated with a SHA-256 hash. Click the SHA-256 hash
to view the related messages in the Message Tracking page.
• A list of profile names defined for the recipients for whom the mailbox
auto remediation was successful or unsuccessful.
• Reason for the auto remediation failure.
Mailbox Search and The Mailbox Search and Remediate section displays the following details:
Remediate
• The list of remediation batches that are in progress or completed.
• The remediation status of the messages in the batches.
• The batch name and the batch ID. Click the batch name to view the batch
details:
• The date and time when the Mailbox Search and Remediate was
initiated.
• The source from which the Mailbox Search and Remediate was
initiated.
• The host who initiated the Mailbox Search and Remediate.
• The remedial action taken on the messages.
• The Cisco Ironport Message ID of the message.
• A read receipt icon to show if the message was read by the recipient
before the message was remediated successfully.
• The remediation status of the message in the particular batch as
Success, Failed, or In Progress.
• The email address of the sender who sent the message.
• The email addresses of the recipients for whom the message was
delivered and later attempted for remediation.
• The date and time when the message was sent to the recipient.
Message Filters Page
The Message Filters page shows information about the top message filter matches (which message filter had
the most matching messages) in two forms: a bar chart and a tabular representation.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
905
Using Email Security Monitor
High Volume Mail Page
Using the bar chart, you can find the message filters that are being triggered the most by incoming and outgoing
messages. The tabular representation shows the top message filters and the number of matches for the respective
message filters. Click on the number to view a list of all the messages that are included in that number using
Message Tracking.
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link.
High Volume Mail Page
Note The High Volume Mail page shows data only from message filters that use Header Repeats rule.
The High Volume Mail page contains the following reports in the form of bar charts:
• Top Subjects. You can use this chart to understand the top subjects of messages that AsyncOS received.
• Top Envelope Senders. You can use this chart to understand the top envelope senders of messages that
AsyncOS received.
• Top Message Filters by Number of Matches. You can use this chart to understand the top message
filter (that uses Header Repeats rule) matches.
The High Volume Mail page also provides a tabular representation of the top message filters and the number
of matches for the respective message filters. Click the number to view a list of all the messages that are
included in that number using Message Tracking.
You can select a time range on which to report, such as an hour, a week, or a custom range. As with all reports,
you can export the data for the graphs or the details listing to CSV format via the Export link.
Content Filters Page
The Content Filters page shows information about the top incoming and outgoing content filter matches (which
content filter had the most matching messages) in two forms: a bar chart and a listing. Using the Content
Filters page, you can review your corporate policies on a per-content filter or per-user basis and answer
questions like:
• Which content filter is being triggered the most by incoming or outgoing mail?
• Who are the top users sending or receiving mail that is triggering a particular content filter?
You can click the name of the content filter in the listing to view more information about that filter on the
Content Filter detail page.
Related Topics
• Content Filter Details, on page 906
Content Filter Details
Click the content filter name link to view the content filter details. The Content Filter detail page displays
matches for that filter over time, as well as matches by internal user.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
906
Using Email Security Monitor
Safe Print Page
In the Matches by Internal Users section, you can click the name of a user to view that internal user’s (email
address) Internal User details page (see #unique_1507).
Safe Print Page
You can use the Safe Print report page to view:
• Number of safe-printed attachments based on the file type in graphical format.
• Summary of safe-printed attachments based on the file type in tabular format.
In the ‘Summary of Safe Print File Types’ section, click the total number of safe-printed attachments to view
the message details in Message Tracking.
Advanced Phishing Protection Report Page
The Reports > Mail Flow Summary > Advanced Phishing Protection report page displays the following:
• Total number of messages successfully forwarded to the Cisco Advanced Phishing Protection cloud
service.
• Total number of messages that are not forwarded to the Cisco Advanced Phishing Protection cloud
service.
Note If the forwarding of message metadata has failed, you must validate the
configurations of the Advanced Phishing Protection feature. For more information,
see How to Integrate Email Gateway with the Cisco Advanced Phishing Protection
Cloud Service, on page 766
You can use the Advanced Phishing Protection report page to view:
• Total number of messages that are sent from all email gateways at the organizational level to the Cisco
Advanced Phishing Protection cloud service in a dashboard.
• Total number of messages attempted to be forwarded to the Cisco Advanced Phishing Protection cloud
service, in a graphical format.
To view the detailed information on the metadata of the message that is forwarded to the Cisco Advanced
Phishing Protection cloud service, click on the link and login to the Cisco Advanced Phishing Protection cloud
service. For more information, see Monitoring Message Metadata on the Cisco Advanced Phishing Protection
Cloud Service, on page 772.
Mail Policy Details Report Page
You can use the Mail Policy Details report page to view:
• Top incoming messages that matched a configured mail policy in graphical and tabular format.
• Top outgoing messages that matched a configured mail policy in graphical and tabular format.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
907
Using Email Security Monitor
Reporting Overview
In the ‘Incoming Policies’ section, click the total number of incoming messages that matched a specific mail
policy to view the message details in Message Tracking.
In the ‘Outgoing Policies’ section, click the total number of incoming messages that matched a specific mail
policy to view the message details in Message Tracking.
Reporting Overview
Reporting in AsyncOS involves three basic actions:
• You can create Scheduled Reports to be run on a daily, weekly, or monthly basis.
• You can generate a report immediately (“on-demand” report).
• You can view archived versions of previously run reports (both scheduled and on-demand).
Configure scheduled and on-demand reports via the Monitor > Scheduled Reports page. View archived reports
via the Monitor > Archived Reports page.
Your email gateway will retain the most recent reports it generates, up to 1000 total versions for all reports.
You can define as many recipients for reports as you want, including zero recipients. If you do not specify an
email recipient, the system will still archive the reports. If you need to send the reports to a large number of
addresses, however, it may be easier to create a mailing list rather than listing the recipients individually.
By default, the email gateway archives the twelve most recent reports of each scheduled report. Reports are
stored in the /saved_reports directory of the email gateway. (See FTP, SSH, and SCP Access, on page 1297 for
more information.)
Related Topics
• Scheduled or Archived Report Types, on page 908
• Setting the Return Address for Reports, on page 909
Scheduled or Archived Report Types
You can choose from the following report types:
• AMP Reputation
• Advanced Malware Protection File Analysis
• Advanced Malware Protection File Retrospection
• Connections by Country
• Content Filters
• DLP Incident Summary
• DMARC Verification Report
• Delivery Status
• Executive Summary
• External Threat Feeds
• Forged Email Detection
• High Volume Mail
• Inbound SMTP Authentication
• Marco Detection
• Mail Flow Summary:Incoming
• Mailbox Auto Remediation
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
908
Using Email Security Monitor
Notes on Reports
• Mail Flow Details (Outgoing senders: domain)
• Mail Flow Summary: Outgoing
• Message Filters
• My Email Reports
• Outgoing Destinations
• Rate Limits
• Sender Domain Reputation
• Sender Groups
• System Capacity
• TLS Encryption
• User Mail Summary
• URL Filtering
• Outbreak Filters
• Virus Filtering
• Web Interaction
Each of the reports consists of a summary of the corresponding Email Security Monitor page.
Related Topics
• Notes on Reports, on page 909
Notes on Reports
Content Filter reports in a PDF format are limited to a maximum of 40 content filters. You can obtain the full
listing via reports in a CSV format.
Note To generate PDFs in Chinese, Japanese, or Korean on Windows computers, you must also download the
applicable Font Pack from Adobe.com and install it on your local computer.
Setting the Return Address for Reports
To set the return address for reports, see Configuring the Return Address for Email Gateway Generated
Messages, on page 1041. From the CLI, use the addressconfig command.
Managing Reports
You can create, edit, delete, and view archived scheduled reports. You can also run a report immediately
(on-demand report). Managing and viewing these reports is discussed below.
Note When in Cluster Mode, you are unable to view reports. You may view reports when in machine mode.
The Monitor > Scheduled Reports page shows a listing of the scheduled reports already created on the email
gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
909
Using Email Security Monitor
Scheduled Reports
Related Topics
• Scheduled Reports, on page 910
• Archived Reports, on page 911
Scheduled Reports
Scheduled reports can be scheduled to run on a daily, weekly, or monthly basis. You can select a time at which
to run the report. Regardless of when you run a report, it will only include data for the time period that you
specify, for example the past 3 days or the previous calendar month. Note that a daily report scheduled to run
at 1AM will contain data for the previous day, midnight to midnight.
Your email gateway ships with a default set of scheduled reports —you can use, modify, or delete any of
them.
Related Topics
• Scheduling a Report to be Generated Automatically , on page 910
• Editing Scheduled Reports , on page 911
• Deleting Scheduled Reports, on page 911
Scheduling a Report to be Generated Automatically
Procedure
Step 1 On the Monitor > Scheduled Reports page, click Add Scheduled Report.
Step 2 Select a report type. Depending on the report type you select, different options may be available.
For more information about the available types of scheduled reports, see Scheduled or Archived Report Types,
on page 908.
Step 3 Enter a descriptive title for the report. AsyncOS does not verify the uniqueness of report names. To avoid
confusion, do not create multiple reports with the same name.
Step 4 Select a time range for the report data. (This option is not available for Outbreak Filters reports.)
Step 5 Select a format for the report:
• PDF. Create a formatted PDF document for delivery, archival, or both. You can view the report as a PDF
file immediately by clicking Preview PDF Report.
For information about generating PDFs in languages other than English, see the Notes on Reports, on
page 909.
• CSV. Create an ASCII text file that contains the tabular data as comma-separated values. Each CSV file
may contain up to 100 rows. If a report contains more than one type of table, a separate CSV file is
created for each table.
Step 6 Specify the report options, if available. Some reports do not have report options.
Step 7 Specify scheduling and delivery options. If you do not specify an email address, the report is archived but is
not sent to any recipients.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
910
Using Email Security Monitor
Editing Scheduled Reports
Note If you are sending reports to an external account (such as Yahoo or Gmail, etc.), you may need to
add the reporting return address to the external account’s allowed list to prevent report emails from
being incorrectly classified as spam.
Step 8 Click Submit. Commit your changes.
Editing Scheduled Reports
Procedure
Step 1 Click the report title in the listing on the Services > Centralized Reporting page.
Step 2 Make your changes.
Step 3 Submit and commit your changes.
Deleting Scheduled Reports
Procedure
Step 1 On the Services > Centralized Reporting page, select the check boxes corresponding to the reports that you
want to delete.
Note Select the All check box to remove all scheduled reports.
Step 2 Click Delete.
Step 3 Confirm the deletion and then commit your changes.
Any archived versions of deleted reports are not automatically deleted.
Archived Reports
The Monitor > Archived Reports page lists the available archived reports. You can view a report by clicking
its name in the Report Title column. You can generate a report immediately by clicking Generate Report
Now
Use the Show menu to filter which type of reports is listed. Click the column headings to sort the listing.
Archived reports are deleted automatically — up to 30 instances of each scheduled report (up to 1000 reports)
are kept and as new reports are added, older ones are deleted to keep the number at 1000. The 30 instances
limit is applied to each individual scheduled report, not report type.
Related Topics
• Generating On-Demand Reports, on page 912
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
911
Using Email Security Monitor
Generating On-Demand Reports
Generating On-Demand Reports
You can generate a report without scheduling it. These on-demand reports are still based on a specified time
frame, but they are generated immediately.
Procedure
Step 1 Click Generate Report Now on the Archived Reports page.
Step 2 Select a report type and edit the title if desired. AsyncOS does not verify the uniqueness of report names. To
avoid confusion, do not create multiple reports with the same name.
For more information about the available types of scheduled reports, see Scheduled or Archived Report Types,
on page 908.
Step 3 Select a time range for the report data. (This option is not available for Virus Outbreak reports.)
If you create a custom range, the range will appear as a link. To modify the range, click the link.
Step 4 Select a format for the report.
• PDF. Create a formatted PDF document for delivery, archival, or both. You can view the report as a PDF
file immediately by clicking Preview PDF Report.
For information about generating PDFs in languages other than English, see the Notes on Reports, on
page 909.
• CSV. Create an ASCII text file that contains the tabular data as comma-separated values. Each CSV file
may contain up to 100 rows. If a report contains more than one type of table, a separate CSV file is
created for each table.Specify any report options.
Step 5 Select whether to archive the report (if so, the report will shown on the Archived Reports page).
Step 6 Specify whether to email the report and to which email addresses to send the report.
Step 7 Click Deliver this Report to generate the report and deliver it to recipients or archive it.
Step 8 Commit your changes.
Troubleshooting Email Reports
• Link to Message Tracking Gives Unexpected Results , on page 912
• File Analysis Details in the Cloud Are Incomplete, on page 913
Link to Message Tracking Gives Unexpected Results
Problem
Drilling down from a report to view details in message tracking yields unexpected results.
Solution
This can occur if reporting and message tracking were not simultaneously enabled, functioning properly, and
storing data locally (as opposed to being stored centrally on a Cisco Secure Email and Web Manager). Data
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
912
Using Email Security Monitor
File Analysis Details in the Cloud Are Incomplete
for each feature (reporting and message tracking) is stored only while that feature is enabled and functioning
on that email gateway, independently of whether the other feature (reporting or message tracking) is enabled
and functioning. Therefore, reports may include data that is not available in Message Tracking and vice-versa.
File Analysis Details in the Cloud Are Incomplete
Problem
Complete file analysis results in the public cloud are not available for files uploaded from other email gateways
in my organization.
Solution
Be sure to group all email gateways that will share file analysis result data. See (Public Cloud File Analysis
Services Only) Configuring Appliance Groups , on page 494. This configuration must be done on each appliance
in the group.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
913
Using Email Security Monitor
File Analysis Details in the Cloud Are Incomplete
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
914
CHAPTER 35
Tracking Messages
This chapter contains the following sections:
• Message Tracking Overview , on page 915
• Enabling Message Tracking, on page 915
• Searching for Messages on the Legacy Interface , on page 916
• Searching for Email Messages on the New Web Interface, on page 919
• Working with Message Tracking Search Results , on page 921
• Checking Message Tracking Data Availability , on page 924
• Troubleshooting Message Tracking, on page 925
Message Tracking Overview
Message tracking helps resolve help desk calls by giving a detailed view of message flow. For example, if a
message was not delivered as expected, you can determine if it was found to contain a virus or placed in a
spam quarantine — or if it is located somewhere else in the mail stream.
You can search for a particular email message or a group of messages that match criteria that you specify.
Note You cannot use message tracking to read the content of messages.
Enabling Message Tracking
Note Message tracking data is preserved only for messages that are processed after you enable this feature.
Before you Begin
• In order to search for and display attachment names in Message Tracking and view attachment names
in log files, you must configure and enable at least one body scanning process, such as a message filter
or content filter.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
915
Tracking Messages
Searching for Messages on the Legacy Interface
• To support searching by subject, log files must be configured to record subject headers. For more
information, see Logging, on page 1141.
• If you are setting up Centralized Tracking: Set up your Cisco Secure Manager Email and Web Gatewayto
support centralized message tracking for this email gateway. See the Cisco Secure Manager Email and
Web Gateway User Guide.
Procedure
Step 1 Click Security Services > Message Tracking.
Use this path even if you do not plan to centralize this service.
Step 2 Select Enable Message Tracking Service.
Step 3 If you are enabling message tracking for the first time after running the System Setup Wizard, review the
end-user license agreement, and click Accept.
Step 4 Choose a Message Tracking Service:
Option Description
Local Tracking Use message tracking on this email gateway.
Centralized Tracking Use Cisco Secure Manager Email and Web Gateway to track messages for multiple
email gateways including this one.
Step 5 (Optional) Select the check box to save information for rejected connections.
For best performance, leave this setting disabled.
Step 6 Submit and commit your changes.
What to do next
If you selected Local Tracking:
• Choose who can access content related to DLP violations. See Controlling Access to Sensitive Information
in Message Tracking, on page 981.
• (Optional) Adjust the disk space allocation for storing messages. See Managing Disk Space , on page
1023.
Searching for Messages on the Legacy Interface
Procedure
Step 1 Choose Monitor > Message Tracking
Step 2 Enter search criteria.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
916
Tracking Messages
Searching for Messages on the Legacy Interface
• To view all options, click the Advanced link.
• Tracking does not support wildcard characters or regular expressions.
• Tracking searches are not case sensitive.
• Unless otherwise specified, the query is an “AND” search: The query returns messages that match all
conditions specified in the search fields. For example, if you specify text strings for the envelope recipient
and the subject line parameters, the query returns only messages that match both the specified envelope
recipient and the subject line.
• Search criteria include:
Option Description
Envelope Sender Select Begins With, Is, or Contains, then enter an email address,
username, or domain of a message sender to find.
You can enter any character(s). No validation of your entry is
performed.
Envelope Recipient Select Begins With, Is, or Contains, and enter an email address,
username, or domain of a message recipient to find.
You can enter any character(s). No validation of your entry is
performed.
Subject Select Begins With, Is, or Contains, and enter a text string to search
for in the message subject line.
Warning: Do not use this type of search in environments where
regulations prohibit such tracking.
Message Received Specify a date and time range.
If you do not specify a date, the query returns data for all dates. If you
specify a time range only, the query returns data for that time range
across all available dates.
Use the local date and time that the message was received by the email
gateway.
Advanced options:
Sender IP Address/ Domain / Specify the IP address, domain, or network owner of a remote host.
Network Owner
You can search within rejected connections only or search all messages.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
917
Tracking Messages
Searching for Messages on the Legacy Interface
Option Description
Attachment Select Begins With, Is, or Contains, and enter an ASCII or Unicode
text string for one attachment to find. Leading and trailing spaces are
not stripped from the text you enter.
You can search for messages by attachment filenames only if you have
performed:
• Body scan using a message filter
• Body scan using a content filter
• Advanced Malware Protection (AMP) scan.
For more information about identifying files based on SHA-256 hash,
see Identifying Files by SHA-256 Hash , on page 502.
You can search for messages that are detected as malicious by the
Advanced Malware Protection engine based on the threat name. In the
Threat Name field, enter Simple_Custom_ Detection or
Custom_Threshold to search for messages that are detected as malicious
based on the Custom Detection and Custom Threshold categories. You
can also search for messages by the virus name if a particular file is
detected as virus positive by the Advanced Malware Protection engine.
Message Event Select one or more message processing events. For example, you can
search for messages that have been delivered, quarantined, or hard
bounced.
Message events are added with an “OR” operator: Selecting multiple
events finds messages that match any of the conditions you specify.
Message ID Header Enter a text string for the SMTP Message-ID header.
This RFC 822 message header uniquely identifies each email message.
It is inserted in the message when the message is first created.
Cisco IronPort MID Enter a message number to search for. An IronPort MID uniquely
identifies each email message on the email gateway.
Cisco IronPort Host Select an Email Security appliance to restrict the search to messages
processed by that email gateway, or select all email gateways.
Step 3 Click Search to submit the query.
The query results are displayed at the bottom of the page.
What to do next
Related Topics
• Working with Message Tracking Search Results , on page 921
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
918
Tracking Messages
Searching for Email Messages on the New Web Interface
Searching for Email Messages on the New Web Interface
The tracking service of the email gateway lets you search for a particular email message or group of messages
that match specified criteria, such as the message subject line, date and time range, envelope sender or recipient,
or processing event (for example, whether the message was virus positive, spam positive, hard bounced,
delivered, and so forth). Message tracking gives you a detailed view of message flow. You can also drill down
on particular email messages to see message details, such as the processing events, attachment names, or the
envelope and header information.
Note Although the tracking component provides detailed information about individual email messages, you cannot
use it to read the content of messages.
Procedure
Step 1 Click Tracking tab.
Step 2 Select Messages tab or Rejected Connections tab to narrow your search results.
Note You can search for rejected connections based on the sender IP address, domain or network owner.
Step 3 (Optional) Click the Advanced Search to display additional search options.
Step 4 Enter the following search criteria:
Note Tracking searches do not support wildcard characters or regular expressions. Tracking searches are
not case sensitive.
• [For Messages and Rejected Connections] Message Received: Specify a date and time range for the
query using “Last Day,” “Last 7 Days,” or “Custom Range.” Use the “Last Day” option to search for
messages within the past 24 hours, and use the “Last 7 Days” option to search for messages within the
past full seven days, plus the time that has passed on the current day.
If you do not specify a date, the query returns data for all dates. If you specify a time range only, the
query returns data for that time range across all available dates. If you specify the current date and 23:59
as the end date and time, the query returns all data for the current date.
Dates and times are converted to GMT format when they are stored in the database. When you view
dates and times on an email gateway, they are displayed in the local time of the email gateway.
Messages appear in the results only after they have been logged on the email gateway and retrieved by
the Cisco Secure Email and Web Gateway. Depending on the size of logs and the frequency of polling,
there could be a small gap between the time when an email message was sent and when it actually appears
in tracking and reporting results.
• Envelope Sender: Select Begins With, Is, or Contains, and enter a text string to search for in the envelope
sender. You can enter email addresses, user names, or domains. Use the following formats:
• For email domains: example.com, [203.0.113.15], [ipv6:2001:db8:80:1::5]
• For full email addresses: [email protected], user@[203.0.113.15] or
user@[ipv6:2001:db8:80:1::5].
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
919
Tracking Messages
Searching for Email Messages on the New Web Interface
• You can enter any character(s). No validation of your entry is performed.
• Subject: Select Begins With, Is, Contains, or Is Empty, and enter a text string to search for in the message
subject line.
• Envelope Recipient: Select Begins With, Is, or Contains, and enter text to search for in the envelope
recipient. You can enter email addresses, user names, or domains.
If you use the alias table for alias expansion on your email gateways, the search finds the expanded
recipient addresses rather than the original envelope addresses. In all other cases, message tracking
queries find the original envelope recipient addresses.
Otherwise, valid search criteria for Envelope Recipient are the same as those for Envelope Sender.
You can enter any character(s). No validation of your entry is performed.
• Attachment Name: Select Begins With, Is, or Contains, and enter an ASCII or Unicode text string for
one Attachment Name to find. Leading and trailing spaces are not stripped from the text you enter.
• Reply-To: Select Begins With, Is, or Contains, and enter a text string to search for messages based on
the Reply-To header of the message.
• File SHA256: Enter a File SHA-256 value of the message.
For more information about identifying files based on SHA-256 hash, see Identifying Files by SHA-256
Hash , on page 885.
• Cisco Host: Select All Host to search across all email gateways or select the required email gateway
from the drop-down menu.
• Message ID Header and Cisco MID: Enter a text string for the message ID header, the Cisco IronPort
message ID (MID), or both.
• [For Messages and Rejected Connections] Sender IP Address/ Domain/ Network Owner: Enter a
sender IP address, domain or nework owner details.
• An IPv4 address must be 4 numbers separated by a period. Each number must be a value from 0 to
255. (Example: 203.0.113.15).
• An IPv6 address consists of 8 sets of 16-bit hexadecimal values separated by colons.
You can use zero compression in one location, such as 2001:db8:80:1::5.
• Message Event: Select the events to track. For example, you can search for messages that have
been delivered, quarantined, or hard bounced. Message events are added with an “OR” operator:
Selecting multiple events finds messages that match any of the conditions you specify.
You do not need to complete every field. Except for the Message Event options, the query is an “AND” search.
The query returns messages that match the “AND” conditions specified in the search fields. For example, if
you specify text strings for the envelope recipient and the subject line parameters, the query returns only
messages that match both the specified envelope recipient and the subject line.
Step 5 Click Search.
Each row corresponds to an email message. Scroll down to load more messages in the view.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
920
Tracking Messages
Working with Message Tracking Search Results
If necessary, you can refine your search by entering new search criteria, and run the query again. Alternatively,
you can refine the search by narrowing the result set, as described in the following section.
What to do next
• Working with Message Tracking Search Results , on page 921
Working with Message Tracking Search Results
Keep the following points in mind:
• Messages appear in the results only after they have been logged on the email gateway and retrieved by
the Cisco Secure Manager Email and Web Gateway. Depending on the size of logs and the frequency
of polling, there could be a small gap between the time when an email message was sent and when it
actually appears in tracking and reporting results.
• For information about searches involving Advanced Malware Protection (file reputation scanning and
file analysis), see About Message Tracking and Advanced Malware Protection Features , on page 504.
Actions you can take when working with search results:
• Show more than 250 search results by returning to the search criteria, clicking Advanced, scrolling to
the Query Settings, and setting the maximum number of results to 1000.
• Show more results per page by choosing an option from the top right side of the search results section.
• Navigate through multiple pages of search results from the top right side of the search results section.
• Narrow your search results by floating the cursor over a value in the search results that you want to add
as a condition. If an orange highlight appears, you can click that value to narrow the search by that
criterion. This adds the additional criterion to the search criteria. For example, if you search for messages
sent to a particular recipient, you can then click on a sender name in the search results to find all messages
to that recipient from that sender within the time range (and meeting any other criteria) that you originally
specified.
• If more than 1000 messages match your search criteria, you can click Export All (a link at the top right
of the search results section) and export up to 50,000 search results as a comma-separated values file
and work with the data in another application.
• View more details for a message by clicking Show Details in the row for that message. A new browser
window opens with the message details.
• For quarantined messages, you can click a link in the message tracking search results to view details
such as the reason the message was quarantined.
• Remediate the malicious messages from the user mailbox using the Mailbox Search and Remediate
action. For more information, see Search and Remediate Messages in the Mailboxes, on page 594
Note If you clicked a link in a report page to view message details in Message Tracking, and the set of results is
not what you expected, this can occur if reporting and tracking were not both simultaneously and continuously
enabled during the time period you are reviewing.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
921
Tracking Messages
Message Tracking Details
Related Topics
• Message Tracking Details , on page 922
Message Tracking Details
Item Description
Envelope and Header Summary
section:
Received Time Time that the email gateway received the message.
Dates and times are displayed using the local time configured on the
email gateway.
MID Unique IronPort message ID.
Message Size Message size.
Subject Subject line of the message.
The subject line in the tracking results may have the value “(No
Subject)” if the message does not have a subject, or if log files are not
configured to record subject headers. For more information, see
Logging, on page 1141
Envelope Sender Address of the sender in the SMTP envelope.
Envelope Recipients If your deployment uses the alias table for alias expansion, the search
finds the expanded recipient addresses rather than the original envelope
addresses. For more information about Alias Tables, see “Creating
Alias Tables” in the “Configuring Routing and Delivery Features”
chapter .
In all other cases, message tracking queries find the original envelope
recipient addresses.
Message ID Header The RFC 822 message header.
SMTP Auth User ID SMTP authenticated username of the sender, if the sender used SMTP
authentication to send the message. Otherwise, the value is “N/A.”
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
922
Tracking Messages
Message Tracking Details
Item Description
Attachments The names of files attached to the message.
Messages that contain at least one attachment with the queried name
will appear in the search results.
Some attachments may not be tracked. For performance reasons,
scanning of attachment names occurs only as part of other scanning
operations, for example message or content filtering, DLP, or
disclaimer stamping. Attachment names are available only for messages
that pass through body scanning while the attachment is still attached.
Situations in which an attachment name will not appear in search
results include (but are not limited to):
• If the system only uses content filters, and a message is dropped
or its attachment is stripped by anti-spam or anti-virus filters
• If message splintering policies strip the attachment from some
messages before body scanning occurs.
For performance reasons, the names of files within attachments, such
as OLE objects or archives such as .ZIP files, are not searched.
[New Web Interface Only] Message Select multiple events to include messages that match each event type.
Event
Sending Host Summary section
Reverse DNS Hostname Name of the sending host, as verified by reverse DNS (PTR) lookup.
IP Address IP address of the sending host.
IP Reputation Score IP reputation score. The range is from 10 (likely a trustworthy sender)
to -10 (apparent spammer). A score of “None” indicates that there was
no information about this host at the time the message was processed.
For more information about IP Reputation Service, see IP Reputation
Filtering , on page 93
Processing Details section
Summary information The Summary tab displays status events logged during the processing
of the message.
(If one of the tabs below is displayed,
this information is displayed in a tab. Entries include information about Mail Policy processing, such as
Summary information always Anti-Spam and Anti-Virus scanning, and other events such as message
displays.) splitting and custom log entries added by a content or message filter.
If the message was delivered, the details of the delivery are displayed
here.
The last recorded event is highlighted in the processing details.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
923
Tracking Messages
Checking Message Tracking Data Availability
Item Description
DLP Matched Content tab This tab displays only for messages that were caught by DLP policies.
This tab includes information about the match, as well as the sensitive
content that triggered the DLP policy match.
You must configure the email gateway to display this information.
See Displaying Sensitive DLP Data in Message Tracking , on page
535.
To control access to this tab, see Controlling Access to Sensitive
Information in Message Tracking, on page 981.
URL Details tab This tab displays only for messages caught by URL Reputation and
URL Category content filters and by outbreak filters.
This tab displays the following information:
• The reputation score or category associated with the URL
• The action performed on the URL (rewrite, defang, or redirect)
• If a message contains multiple URLs, which URL has triggered
the filter action.
You must configure the email gateway to display this information.
See Displaying URL Details in Message Tracking , on page 463.
To control access to this tab, see Controlling Access to Sensitive
Information in Message Tracking, on page 981.
Related Topics
• Searching for Messages on the Legacy Interface , on page 916
Checking Message Tracking Data Availability
You can determine the date range that your message tracking data includes, as well as identify any missing
intervals in that data.
Procedure
Step 1 [New Web Interface Only] Click the gear icon on the upper right corner of the page to load the legacy web
interface.
Step 2 Select Monitor > Message Tracking.
Step 3 Look for Data in time range: in the upper right corner of the Search box.
Step 4 Click the value shown for Data in time range:.
What to do next
Related Topics
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
924
Tracking Messages
About Message Tracking and Upgrades
• About Message Tracking and Upgrades , on page 925
About Message Tracking and Upgrades
New message tracking features may not apply to messages that were processed before upgrade, because the
required data may not have been retained for those messages. For possible limitations related to message
tracking data and upgrades, see the Release Notes for your release.
Troubleshooting Message Tracking
Related Topics
• Attachments Do Not Appear in Search Results , on page 925
• Expected Messages Are Missing from Search Results , on page 925
Attachments Do Not Appear in Search Results
Problem
Attachment names are not found and displayed in search results.
Solution
See configuration requirements at Enabling Message Tracking, on page 915 . Also see limitations for attachment
name searches in Message Tracking Details , on page 922.
Expected Messages Are Missing from Search Results
Problem
Search results did not include messages that should have met the criteria.
Solution
• Results for many searches, and especially searches that involve Message Events, depend on your email
gateway configuration. For example, if you search for a URL Category for which you have not filtered,
no results will be found, even if a message contains a URL in that category. Verify that you have
configured the email gateway properly to achieve the behavior that you expected. For example, check
your mail policies, content and message filters, and quarantine settings.
• If expected information is missing after you clicked a link in a report, see Troubleshooting Email Reports,
on page 912.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
925
Tracking Messages
Expected Messages Are Missing from Search Results
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
926
CHAPTER 36
Policy, Virus, and Outbreak Quarantines
This chapter contains the following sections:
• Overview of Policy, Virus, and Outbreak Quarantines, on page 927
• Managing Policy, Virus, and Outbreak Quarantines, on page 929
• Working with Messages in Policy, Virus, or Outbreak Quarantines, on page 937
Overview of Policy, Virus, and Outbreak Quarantines
“Policy, virus and outbreak quarantines” includes all non-spam quarantines, including the File Analysis
quarantine.
When an email gateway detects possible malware or content that is not allowed by your organization in
incoming or outgoing messages, it can send those messages to a quarantine instead of deleting them
immediately. A quarantine holds these messages safely on the email gateway or on a Cisco Secure Email and
Web Manager for a period of time, to allow a human being to review them, or to await an update that will
better evaluate the safety of the message.
Examples of how non-spam quarantines can be used in your organization:
• Policy enforcement. Let Human Resources personnel or the Legal department review messages that
may contain offensive, confidential, or otherwise disallowed information.
• Virus quarantine. Store messages that are marked as infected, encrypted, or not scannable by the
anti-virus scanning engine to prevent the spread of viruses to your users.
• Outbreak prevention. Hold messages that are flagged by the Outbreak Filters as possibly being part of
a viral outbreak or small-scale malware attack until an anti-virus or anti-spam update is released.
• File Analysis quarantine. Store messages that have attachments that may contain malware, and that
have been sent for analysis, until a verdict is reached.
Related Topic
• Spam Quarantine, on page 947
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
927
Policy, Virus, and Outbreak Quarantines
Quarantine Types
Quarantine Types
Quarantine Type Quarantine Name Created by the Description More Information
System by Default?
Advanced Malware File Analysis Yes Holds messages that • Managing
Protection are sent for file Policy, Virus,
analysis, until a and Outbreak
verdict is returned. Quarantines
Virus Virus Yes Holds messages that • Working with
may be transmitting Messages in
malware, as Policy, Virus,
determined by the or Outbreak
anti-virus engine. Quarantines
Outbreak Outbreak Yes Holds messages
caught by Outbreak
Filters as potentially
being spam or
malware.
Policy Policy Yes Holds messages
caught by message
filters, content
filters, and DLP
message actions.
A default Policy
quarantine has been
created for you.
Unclassified Yes Holds messages
only if a quarantine
that is specified in a
message filter,
content filter, or
DLP message action
has been deleted.
You cannot assign
this quarantine to
any filter or message
action.
(Policy quarantines No Policy quarantines
that you create) that you create for
use in message
filters, content
filters, and DLP
message actions.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
928
Policy, Virus, and Outbreak Quarantines
Managing Policy, Virus, and Outbreak Quarantines
Quarantine Type Quarantine Name Created by the Description More Information
System by Default?
Spam Spam Yes Holds spam or Spam Quarantine,
suspected spam on page 947
messages for the
message’s recipient
or an administrator
to review.
The spam quarantine
is not included in the
group of policy,
virus, and outbreak
quarantines and is
managed separately
from all other
quarantines.
Managing Policy, Virus, and Outbreak Quarantines
• Disk Space Allocation for Policy, Virus, and Outbreak Quarantines , on page 929
• Retention Time for Messages in Quarantines , on page 930
• Default Actions for Automatically Processed Quarantined Messages , on page 931
• Checking the Settings of System-Created Quarantines , on page 931
• Configuring Policy, Virus, and Outbreak Quarantines , on page 931
• About Editing Policy, Virus, and Outbreak Quarantine Settings , on page 933
• Determining the Filters and Message Actions to Which a Policy Quarantine Is Assigned , on page 933
• About Deleting Policy Quarantines , on page 934
• Monitoring Quarantine Status, Capacity, and Activity , on page 934
• Policy Quarantine Performance , on page 935
• Alerts About Quarantine Disk-Space Usage , on page 936
• Policy Quarantines and Logging, on page 936
• About Distributing Message Processing Tasks to Other Users , on page 936
• About Policy, Virus, and Outbreak Quarantines in Cluster Configurations , on page 937
• About Centralized Policy, Virus, and Outbreak Quarantines , on page 937
Disk Space Allocation for Policy, Virus, and Outbreak Quarantines
For disk space information for policy, virus, and outbreak quarantines, see Managing Disk Space , on page
1023.
Policy, virus, and outbreak quarantines consume some disk space on the email gateway even if the quarantines
are centralized.
Messages in multiple quarantines consume the same amount of disk space as a message in a single quarantine.
If Outbreak Filters and Centralized Quarantines are both enabled:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
929
Policy, Virus, and Outbreak Quarantines
Retention Time for Messages in Quarantines
• All disk space on the email gateway that would have been allocated to local policy, virus, and outbreak
quarantines is used instead to hold copies of messages in the Outbreak quarantine, in order to scan those
messages each time outbreak rules are updated.
• The disk space on the Cisco Secure Email and Web Manager for messages in the Outbreak quarantine
from a particular managed
Related Topics
• Monitoring Quarantine Status, Capacity, and Activity , on page 934
• Alerts About Quarantine Disk-Space Usage , on page 936
• Retention Time for Messages in Quarantines , on page 930
Retention Time for Messages in Quarantines
Messages are automatically removed from the quarantine under the following circumstances:
• Normal Expiration—the configured retention time is met for a message in the quarantine. You specify
a retention time for messages in each quarantine. Each message has its own specific expiration time,
displayed in the quarantine listing. Messages are stored for the amount of time specified unless another
circumstance described in this topic occurs.
Note The normal retention time for messages in the Outbreak Filters quarantine is
configured in the Outbreak Filters section of each mail policy, not in the outbreak
quarantine.
• Early Expiration—messages are forced from quarantines before the configured retention time is reached.
This can happen when:
• The size limit for all quarantines, as defined in Disk Space Allocation for Policy, Virus, and Outbreak
Quarantines , on page 929, is reached.
If the size limit is reached, the oldest messages, regardless of quarantine, are processed and the
default action is performed for each message, until the size of all quarantines is again less than the
size limit. The policy is First In First Out (FIFO). Messages in multiple quarantines will be expired
based on their latest expiration time.
(Optional) You can configure individual quarantines to be exempt from release or deletion because
of insufficient disk space. If you configure all quarantines to be exempt and the disk space reaches
capacity, messages in the quarantine will be delivered to make room for new messages.
You will receive alerts at disk-space milestones. See Alerts About Quarantine Disk-Space Usage ,
on page 936.
• You delete a quarantine that still holds messages.
When a message is automatically removed from a quarantine, the default action is performed on that message.
See Default Actions for Automatically Processed Quarantined Messages , on page 931.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
930
Policy, Virus, and Outbreak Quarantines
Default Actions for Automatically Processed Quarantined Messages
Note In addition to the above scenarios, messages can be automatically removed from quarantine based on the
result of scanning operations (outbreak filters or file analysis.)
Effects of Time Adjustments on Retention Time
• Daylight savings time and email gateway time zone changes do not affect the retention period.
• If you change the retention time of a quarantine, only new messages will have the new expiration time.
• If the system clock is changed, messages that should have expired in the past will expire at the next most
appropriate time.
• System clock changes do not apply to messages that are in the process of being expired.
Default Actions for Automatically Processed Quarantined Messages
The default action is performed on messages in a policy, virus, or outbreak quarantine when any situation
described in Retention Time for Messages in Quarantines , on page 930, occurs.
There are two primary default actions:
• Delete—The message is deleted.
• Release—The message is released for delivery.
Upon release, messages may be rescanned for threats. For more information, see About Rescanning of
Quarantined Messages , on page 943.
In addition, messages released before their expected retention time has passed can have additional operations
performed on them, such as adding an X-Header. For more information, see Configuring Policy, Virus, and
Outbreak Quarantines , on page 931.
Checking the Settings of System-Created Quarantines
Before you use quarantines, customize the settings of the default quarantines, including the Unclassified
quarantine.
Related Topics
• Configuring Policy, Virus, and Outbreak Quarantines , on page 931
Configuring Policy, Virus, and Outbreak Quarantines
Before you begin
• If you are editing an existing quarantine, see About Editing Policy, Virus, and Outbreak Quarantine
Settings , on page 933.
• Understand how messages in quarantines are automatically managed, including retention times and
default actions. See Retention Time for Messages in Quarantines , on page 930, and Default Actions for
Automatically Processed Quarantined Messages , on page 931.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
931
Policy, Virus, and Outbreak Quarantines
Configuring Policy, Virus, and Outbreak Quarantines
• Determine which users you want to have access to each quarantine, and create users and custom user
roles accordingly. For details, see Which User Groups Can Access Policy, Virus, and Outbreak Quarantines
, on page 936.
Procedure
Step 1 You can configure Policy, Virus, and Outbreak Quarantines in any one of the following ways:
• [ New Web Interface Only] Choose Quarantine > Other Quarantine > View > +.
• Choose Monitor > Policy, Virus, and Outbreak Quarantines and do one of the following.
• Click Add Policy Quarantine.
• Click a quarantine to edit.
Step 2 Enter the following information:
Keep the following in mind:
• Changing the retention time of the File Analysis quarantine from the default of one hour is not
recommended.
• If you do not want messages in this quarantine to be processed before the end of the Retention Period
you specify, even when quarantine disk space is full, deselect Free up space by applying default action
on messages upon space overflow.
Do not select this option for all quarantines. The system must be able to make space by deleting messages
from at least one quarantine.
• If you select Release as the default action, you can specify additional actions to apply to messages that
are released before their retention period has passed:
Option Information
Modify Subject Type the text to add and specify whether to add it to the beginning or the end
of the original message subject.
For example, you might want to warn the recipient that the message may
contain inappropriate content.
Note In order for a subject with non-ASCII characters to display correctly
it must be represented according to RFC 2047.
Add X-Header An X-Header can provide a record of actions taken on a message. This can be
helpful for example when handling inquiries about why a particular message
was delivered.
Enter a name and value.
Example:
Name = Inappropriate-release-early
Value = True
Strip Attachments Stripping attachments protects against viruses that may be in such files.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
932
Policy, Virus, and Outbreak Quarantines
About Editing Policy, Virus, and Outbreak Quarantine Settings
Step 3 Specify the users who can access this quarantine:
User Information
Local Users The list of local users includes only users with roles that can access quarantines.
The list excludes users with Administrator privileges, because all Administrators
have full access to quarantines.
Externally Authenticated You must have configured external authentication.
Users
Custom User Roles You see this option only if you have created at least one custom user role with
quarantine access.
Step 4 Submit and commit your changes.
What to do next
Create message and content filters and DLP message actions that will move messages to the quarantine.
About Editing Policy, Virus, and Outbreak Quarantine Settings
Note • You cannot rename a quarantine.
• See also Retention Time for Messages in Quarantines , on page 930.
To change quarantine settings, choose Monitor > Policy, Virus, and Outbreak Quarantines , and then click
the name of a quarantine.
To change quarantine settings on the new web interface, navigate to Quarantine > Other Quarantine >
View and click on the required quarantine or
Determining the Filters and Message Actions to Which a Policy Quarantine
Is Assigned
You can view the message filters, content filters, Data Loss Prevention (DLP) message actions, and DMARC
verification profiles that are associated with a policy quarantine.
Procedure
Step 1 [New Web Interface Only] On the email gateway, click Quarantine > Other Quarantine > View.
Step 2 [New Web Interface Only] Select the required quarantine and click on the button.
Step 3 Choose Monitor > Policy, Virus, and Outbreak Quarantines.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
933
Policy, Virus, and Outbreak Quarantines
About Deleting Policy Quarantines
Step 4 Click the name of the policy quarantine to check.
Step 5 Scroll to the bottom of the page and view the Associated Message Filters/Content Filters/DLP Message
Actions.
About Deleting Policy Quarantines
• Before you delete a policy quarantine, see if it is associated with any active filters or message actions.
See Determining the Filters and Message Actions to Which a Policy Quarantine Is Assigned , on page
933.
• You can delete a policy quarantine even if it is assigned to a filter or message action.
• If you delete a quarantine that is not empty, the default action defined in the quarantine will be applied
to all messages, even if you have selected the option not to delete messages if the disk is full. See Default
Actions for Automatically Processed Quarantined Messages , on page 931.
• After you delete the quarantine associated with a filter or message action, any messages subsequently
quarantined by that filter or message action will be sent to the Unclassified quarantine. You should
customize the default settings of the Unclassified quarantine before you delete quarantines.
• You cannot delete the Unclassified quarantine.
Monitoring Quarantine Status, Capacity, and Activity
To View Do This
Total space allocated for all non-spam
[New Web Interface Only] On the email gateway, click to
quarantines
load the legacy web interface.
Choose Monitor > Policy, Virus, and Outbreak
Quarantinesand look in the first section on the page.
To change allocations, see Managing Disk Space , on page 1023.
Currently available space for all non-spam [New Web Interface Only] Choose Quarnatine > Other
quarantines Quarantine.
Choose Monitor > Policy, Virus, and Outbreak Quarantines
and look just below the table.
Total amount of space currently used by all
[New Web Interface Only] On the email gateway, click to
quarantines
load the legacy web interface.
Choose Monitor > System Status and look for Queue Space
Used by Quarantine.
Amount of space currently used by each [New Web Interface Only] Choose Quarantines Quarantine
quarantine > Other Quarantine > View.
Choose Monitor > Policy, Virus, and Outbreak Quarantines
, click the quarantine name, and look for this information in the
table row directly below the quarantine name.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
934
Policy, Virus, and Outbreak Quarantines
Policy Quarantine Performance
To View Do This
Total number of messages currently in all
[New Web Interface Only] On the email gateway, click to
quarantines
load the legacy web interface.
Choose Monitor > System Status and look for Active Messages
in Quarantine.
Number of messages currently in each [New Web Interface Only] Choose Quarantines Quarantine
quarantine > Other Quarantine > View.
Choose Monitor > Policy, Virus, and Outbreak Quarantines
and look at the table row for the quarantine.
Total CPU usage by all quarantines
[New Web Interface Only] On the email gateway, click to
load the legacy web interface.
Choose Monitor > System Status and look in the CPU
Utilization section.
Date and time when the last message [New Web Interface Only] Choose Quarantines > Other
entered each quarantine (excluding moves Quarantine > View.
between policy quarantines)
Choose Monitor > Policy, Virus, and Outbreak Quarantines
and look at the table row for the quarantine.
Date a policy quarantine was created
[New Web Interface Only] On the email gateway, click to
Name of policy quarantine creator load the legacy web interface.
Choose Monitor > Policy, Virus, and Outbreak Quarantines,
click the quarantine name, and look for this information in the
table row directly below the quarantine name.
Creation date and creator name are not available for
system-created quarantines.
Filters and message actions associated with See Determining the Filters and Message Actions to Which a
a policy quarantine Policy Quarantine Is Assigned , on page 933.
Policy Quarantine Performance
Messages stored in policy quarantines use system memory in addition to hard-drive space. Storing hundreds
of thousands of messages in policy quarantines on a single email gateway may cause a decrease in the email
gateway's performance due to excessive memory usage. The email gateway takes more time to quarantine,
delete, and release messages, which causes message processing to slow down and the email pipeline to back
up.
Cisco recommends storing an average of less than 20,000 messages in your policy quarantines to ensure that
the email gateway processes email at a normal rate.
To check the number of messages in quarantines, see Monitoring Quarantine Status, Capacity, and Activity
, on page 934.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
935
Policy, Virus, and Outbreak Quarantines
Alerts About Quarantine Disk-Space Usage
Alerts About Quarantine Disk-Space Usage
An alert is sent whenever the total size of the policy, virus, and outbreak quarantine reaches or passes 75
percent, 85 percent, and 95 percent of its capacity. The check is performed when a message is placed in the
quarantine. For example, if adding a message to a quarantine increases the size to or past 75 percent of the
total capacity, an alert is sent.
Policy Quarantines and Logging
AsyncOS individually logs all messages that are quarantined:
Info: MID 482 quarantined to "Policy" (message filter:policy_violation)
The message filter or Outbreak Filters feature rule that caused the message to be quarantined is placed in
parentheses. A separate log entry is generated for each quarantine in which the message is placed.
AsyncOS also individually logs messages that are removed from quarantine:
Info: MID 483 released from quarantine "Policy" (queue full)
Info: MID 484 deleted from quarantine "Anti-Virus" (expired)
The system individually logs messages after they are removed from all quarantines and either permanently
deleted or scheduled for delivery, for example
Info: MID 483 released from all quarantines
Info: MID 484 deleted from all quarantines
When a message is re-injected, the system creates a new Message object with a new Message ID (MID). This
is logged using an existing log message with a new MID “byline”, for example:
Info: MID 483 rewritten to 513 by Policy Quarantine
About Distributing Message Processing Tasks to Other Users
You can distribute message review and processing tasks to other administrative users. For example:
• The Human Resources team can review and manage the Policy Quarantine.
• The Legal team can manage the Confidential Material Quarantine.
You assign access privileges to these users when you specify settings for a quarantine. In order to add users
to quarantines, the users must already exist.
Each user may have access to all, some, or none of the quarantines. A user who is not authorized to view a
quarantine will not see any indication of its existence anywhere in the GUI or CLI listings of quarantines.
Related Topics
• Which User Groups Can Access Policy, Virus, and Outbreak Quarantines , on page 936
• Distributing Administrative Tasks, on page 977
Which User Groups Can Access Policy, Virus, and Outbreak Quarantines
When you allow administrative users to access a quarantine, the actions that they can perform depend on their
user group:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
936
Policy, Virus, and Outbreak Quarantines
About Policy, Virus, and Outbreak Quarantines in Cluster Configurations
• Users in the Administrators groups can create, configure, delete, and centralize quarantines and can
manage quarantined messages.
• Users in the Operators, Guests, Read-Only Operators, and Help Desk Users groups, as well as custom
user roles with quarantine management privileges, can search for, view, and process messages in a
quarantine, but cannot change the quarantine’s settings, create, delete, or centralize quarantines. You
specify in each quarantine which of these users have access to that quarantine.
• Users in the Technicians group cannot access quarantines.
Access privileges for related features, such as Message Tracking and Data Loss Prevention, also affect the
options and information that an administrative user sees on Quarantine pages. For example, if a user does not
have access to Message Tracking, that user will not see message tracking links and information for quarantined
messages.
End users do not have see or have access to policy, virus, and outbreak quarantines.
About Policy, Virus, and Outbreak Quarantines in Cluster Configurations
Policy, virus, and outbreak quarantines are configurable only at machine level in deployments with centralized
management.
About Centralized Policy, Virus, and Outbreak Quarantines
You can centralize policy, virus, and outbreak quarantines on a Cisco Secure Email and Web Manager. For
more information, see Centralized Policy, Virus, and Outbreak Quarantines , on page 1289.
Working with Messages in Policy, Virus, or Outbreak
Quarantines
Related Topics
• Viewing Messages in Quarantines , on page 938
• Finding Messages in Policy, Virus, and Outbreak Quarantines , on page 938
• Manually Processing Messages in a Quarantine, on page 939
• Messages in Multiple Quarantines , on page 941
• Message Details and Viewing Message Content, on page 941
• About Rescanning of Quarantined Messages , on page 943
• The Outbreak Quarantine, on page 944
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
937
Policy, Virus, and Outbreak Quarantines
Viewing Messages in Quarantines
Viewing Messages in Quarantines
To Do This
View all messages in a quarantine [New Web Interface Only] Choose Quarantine > Other Quarantine
> View.
Choose Monitor > Policy, Virus, and Outbreak Quarantines.
In the row for the relevant quarantine, click the blue number in the
Messages column of the table.
View messages in the Outbreak [New Web Interface] Choose Quarantine > Other Quarantine >
quarantine View.
Choose Monitor > Policy, Virus, and Outbreak Quarantines.
In the row for the relevant quarantine, click the blue number in the
Messages column of the table.
See Manage by Rule Summary Link, on page 945.
Navigate through the list of messages Click Previous, Next, a page number, or double-arrow link. The double
in a quarantine arrows take you to the first (<<) or last (>>) page in the listing.
Sort the list of messages in a Click a column heading (except columns that could include multiple
quarantine items or the “In other quarantines” column).
Resize table columns Drag the divider between column headings.
View the content that caused the See Viewing Matched Content , on page 942.
message to be quarantined
Related Topics
• Quarantined Messages and International Character Sets, on page 938
Quarantined Messages and International Character Sets
For messages with subjects that contain characters from international character sets (double-byte, variable
length, and non-ASCII encoded), the Policy Quarantine pages display subject lines in non-ASCII characters
in their decoded form.
Finding Messages in Policy, Virus, and Outbreak Quarantines
Note • Users can find and see only the messages in quarantines to which they have access.
• Searches in Policy, Virus, and Outbreak quarantines do not find messages in the spam quarantine.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
938
Policy, Virus, and Outbreak Quarantines
Manually Processing Messages in a Quarantine
Procedure
Step 1 [New Web Interface Only] Click the blue number link of the corresponding quarantine.
Tip [New Web Interface Only] For the Outbreak Quarantine, you can also find all messages quarantined
by each outbreak rule: Click the Rule Summary tab in the Outbreak quarantine, and then click the
relevant rule.
Step 2 [New Web Interface Only] Choose Quarantine > Other Quarantine > Search.
Step 3 [New Web Interface Only] Click the blue number link of the corresponding quarantine.
Tip [New Web Interface Only] For the Outbreak Quarantine, you can also find all messages quarantined
by each outbreak rule: Click the Rule Summary tab in the Outbreak quarantine, and then click the
relevant rule.
Step 4 Choose Monitor > Policy, Virus, and Outbreak Quarantines .
Step 5 Click the Search Across Quarantines button.
Tip For the Outbreak Quarantine, you can also find all messages quarantined by each outbreak rule:
Click the Manage by Rule Summary link in the Outbreak table row, and then click the relevant
rule.
Step 6 (Optional) Enter other search criteria.
• For Envelope Sender and Envelope Recipient: You can enter any character(s). No validation of your
entry is performed.
• Search results include only messages that match all of the criteria you specify. For example, if you specify
an Envelope Recipient and a Subject, only messages that match the terms specified in both the Envelope
Recipient and the Subject are returned.
What to do next
You can use the search results in the same way that you use the quarantine listings. For more information,
see Manually Processing Messages in a Quarantine, on page 939.
Manually Processing Messages in a Quarantine
Manually processing messages means to manually select a Message Action for the message from the Message
Actions page.
You can perform the following actions on messages:
• Delete
• Release
• Delay Scheduled Exit from quarantine
• Send a Copy of messages to email addresses that you specify
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
939
Policy, Virus, and Outbreak Quarantines
Sending a Copy of the Message
• Move a message from one quarantine to another
Generally, you can perform actions on messages in the lists that are displayed when you do the following.
However, not all actions are available in all situations.
• From the list of quarantines on the Monitor > Policy, Virus, and Outbreak Quarantines or [New Web
Interface Only] Quarantine > Other Quarantine > View page, click the number of messages in a
quarantine.
• Click Search Across Quarantines.
• Click a quarantine name and search within a quarantine.
You can perform these actions on multiple messages at one time by:
• Choosing an option from the pick list at the top of the list of messages.
• Selecting the check box beside each message listed on a page.
• Selecting the check box in the table heading at the top of a list of messages. This applies the action to
all messages visible on the screen. Messages on other pages are not affected.
Additional options are available for messages in the outbreak quarantine. See
Related Topics
• Sending a Copy of the Message, on page 940
• About Moving Messages Between Policy Quarantines , on page 940
• Messages in Multiple Quarantines , on page 941
• Default Actions for Automatically Processed Quarantined Messages , on page 931
Sending a Copy of the Message
Only users who belong to the Administrators group may send copies of a message.
To send a copy of the message, enter an email address in the Send Copy To: field and click Submit. Sending
a copy of a message does not cause any other action to be performed on the message.
About Moving Messages Between Policy Quarantines
You can manually move messages from one policy quarantine to another on a single email gateway.
When you move a message to a different quarantine:
• The expiration time is unchanged. The message keeps the retention time of the original quarantine.
• The reason the message was quarantined, including the matched content and other relevant details, does
not change.
• If a message is in multiple quarantines and you move the message to a destination that already holds a
copy of that message, the expiration time and reason for quarantine of the moved copy of the message
overwrite those of the copy of the message that was originally in the destination quarantine.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
940
Policy, Virus, and Outbreak Quarantines
Messages in Multiple Quarantines
Messages in Multiple Quarantines
If a message is present in one or more other quarantines, the “In other quarantines” column in the quarantine
message list will show “Yes,” regardless of whether you have permissions to access those other quarantines.
A message in multiple quarantines:
• Is not delivered unless it has been released from all of the quarantines in which it resides. If it is deleted
from any quarantine, it will never be delivered.
• Is not deleted from any quarantine until it has been deleted or released from all quarantines in which it
resides.
Because a user wanting to release a message may not have access to all of the quarantines in which it resides,
the following rules apply:
• A message is not released from any quarantine until it has been released from all of the quarantines in
which it resides.
• If a message is marked as Deleted in any quarantine, it cannot be delivered from any other quarantine in
which it resides. (It can still be released.)
If a message is queued in multiple quarantines and a user does not have access to one or more of the other
quarantines:
• The user will be informed whether the message is present in each of the quarantines to which the user
has access.
• The GUI shows only the scheduled exit time from the quarantines to which the user has access. (For a
given message, there is a separate exit time for each quarantine.)
• The user will not be told the names of the other quarantine(s) holding the message.
• The user will not see matched content that caused the message to be placed into quarantines that the user
does not have access to.
• Releasing a message affects only the queues to which the user has access.
• If the message is also queued in other quarantines not accessible to the user, the message will remain in
quarantine, unchanged, until acted upon by users who have the required access to the remaining quarantines
(or until the message is released “normally” via early or normal expiration).
Message Details and Viewing Message Content
Click on the subject line of a message to view that message’s content and to access the Quarantined Message
page.
The Quarantined Message page has two sections: Quarantine Details and Message Details.
From the Quarantined Message page, you can read the message, select a Message Actionsend a copy of the
message, or test for viruses. You can also see if a message will be encrypted upon release from the quarantine
due to the Encrypt on Delivery filter action.
The Message Details section displays the message body, message headers, and attachments. Only the first
100 K of the message body is displayed. If the message is longer, the first 100 K is shown, followed by an
ellipsis (...). The actual message is not truncated. This is for display purposes only. You can download the
message body by clicking [message body] in the Message Parts section at the bottom of Message Details.
You can also download any of the message’s attachments by clicking the attachment’s filename.
If you view a message that contains a virus and you have desktop anti-virus software installed on your computer,
your anti-virus software may complain that it has found a virus. This is not a threat to your computer and can
be safely ignored.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
941
Policy, Virus, and Outbreak Quarantines
Viewing Matched Content
To view additional details about the message, click the Message Tracking link.
Note For the special Outbreak quarantine, additional functionality is available. See The Outbreak Quarantine, on
page 944.
Related Topics
• Viewing Matched Content , on page 942
• Downloading Attachments , on page 943
• Testing for Viruses, on page 943
Viewing Matched Content
When you configure a quarantine action for messages that match Attachment Content conditions, Message
Body or Attachment conditions, Message body conditions, or the Attachment content conditions, you can
view the matched content in the quarantined message. When you display the message body, the matched
content is highlighted in yellow, except for DLP policy violation matches. You can also use the
$MatchedContent action variable to include the matched content from message or content filter matches in
the message subject.
If the attachment contains the matched content, the attachment’s contents are displayed, as well as the reason
it was quarantined, whether it was due to a DLP policy violation, content filter condition, message filter
condition, or Image Analysis verdict.
When you view messages in the local quarantine that have triggered message or content filter rules, the GUI
may display content that did not actually trigger the filter action (along with content that triggered the filter
action). The GUI display should be used as a guideline for locating content matches, but does not necessarily
reflect an exact list of content matches. This occurs because the GUI uses less strict content matching logic
than is used in the filters. This issue applies only to the highlighting in the message body. The table that lists
the matched strings in each part of the message, along with the associated filter rule, is correct.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
942
Policy, Virus, and Outbreak Quarantines
Downloading Attachments
Figure 71: Matched Content Viewed in the Policy Quarantine
Downloading Attachments
You can download a message attachment by clicking the attachment’s file name in the Message Parts or
Matched Content section. AsyncOS displays a warning that attachments from unknown sources may contain
viruses and asks you if you want to continue. Download attachments that may contain viruses at your own
risk. You can also download the message body by clicking [message body] in the Message Parts section.
Testing for Viruses
To test the message for viruses, click Start Test. Use a quarantine to hold messages until you are sure that
your anti-virus signatures have been updated.
Testing for viruses sends a copy of the message to the anti-virus engine, not the message itself. The verdict
from the anti-virus engine is returned and displayed above the Quarantines area.
About Rescanning of Quarantined Messages
When a message is released from all queues in which is has been quarantined, the following rescanning occurs,
depending on the features enabled for the email gateway and for the mail policy that originally quarantined
the message:
• Messages released from Policy and Virus quarantines are rescanned by the anti-virus, advanced malware
protection, and graymail engines.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
943
Policy, Virus, and Outbreak Quarantines
The Outbreak Quarantine
• Messages released from the Outbreak quarantine are rescanned by the anti-spam, AMP, and anti-virus
engines. (For information about rescanning of messages while in the Outbreak quarantine, see )
• Messages released from the File Analysis quarantine are rescanned for threats.
• Messages with attachments are rescanned by the file reputation service upon release from Policy, Virus,
and Outbreak quarantines.
Upon rescanning, if the verdict produced matches the verdict produced the previous time the message was
processed, the message is not re-quarantined. Conversely, if the verdict is different, the message could be sent
to another quarantine.
The rationale is to prevent messages from looping back to the quarantine indefinitely. For example, suppose
a message is encrypted and therefore sent to the Virus quarantine. If an administrator releases the message,
the anti-virus engine will still not be able to decrypt it; however, the message should not be re-quarantined or
a loop will be created and the message will never be released from the quarantine. Since the two verdicts are
the same, the system bypasses the Virus quarantine the second time.
The Outbreak Quarantine
The Outbreak quarantine is present when a valid Outbreak Filters feature license key has been entered. The
Outbreak Filters feature sends messages to the Outbreak quarantine, depending on the threshold set. For more
information, see
The Outbreak quarantine functions just like other quarantines—you can search for messages, release or delete
messages, and so on.
• Standard
• Rule Summary
The Outbreak quarantine has some additional features not available in other quarantines: the Manage by Rule
Summary link, the Send to Cisco feature when viewing message details, and the option to sort messages in
search results by the Scheduled Exit time.
If the license for the Outbreak Filters feature expires, you will be unable to add more messages to the Outbreak
quarantine. Once the messages currently in the quarantine have expired and the Outbreak quarantine becomes
empty, it is no longer shown in the Quarantines listing in the GUI.
Related Topics
• Rescanning Messages in an Outbreak Quarantine , on page 944
• Manage by Rule Summary Link, on page 945
• Reporting False Positives or Suspicious Messages to Cisco Systems, on page 945
Rescanning Messages in an Outbreak Quarantine
Messages placed in the Outbreak quarantine are automatically released if newly published rules deem the
quarantined message no longer a threat.
If anti-spam and anti-virus are enabled on the email gateway, the scanning engines scan every message released
from the Outbreak quarantine based on the mail flow policy that applies to the message.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
944
Policy, Virus, and Outbreak Quarantines
Manage by Rule Summary Link
Manage by Rule Summary Link
Click the Manage by Rule Summary link next to the Outbreak quarantine in the quarantine listing to view the
Manage by Rule Summary page. You can perform message actions (Release, Delete, Delay Exit) on all of
the messages in the quarantine based on which outbreak rule caused the message to be quarantined. This is
ideal for clearing out large numbers of messages from the Outbreak quarantine. For more information, see
the topics under Outbreak Quarantine and the Manage by Rule Summary View
Reporting False Positives or Suspicious Messages to Cisco Systems
When viewing message details for a message in the Outbreak quarantine, you can send the message to Cisco
to report false positives or suspicious messages.
Procedure
Step 1 Navigate to a message in the Outbreak quarantine.
Step 2 In the Message Details section, select the Send a Copy to Cisco Systems check box.
Step 3 In the new web interface, click the blue number in the Message column of the outbreak filters entry in the
table and select the check box of the message(s) and select Send a Copy .
Step 4 Enter the recipient address and click Send.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
945
Policy, Virus, and Outbreak Quarantines
Reporting False Positives or Suspicious Messages to Cisco Systems
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
946
CHAPTER 37
Spam Quarantine
This chapter contains the following sections:
• Overview of the Spam Quarantine , on page 947
• Local Versus External Spam Quarantine , on page 947
• Setting Up the Local Spam Quarantine, on page 948
• Using Safelists and Blocklists to Control Email Delivery Based on Sender , on page 953
• Configuring Spam Management Features for End Users , on page 964
• Managing Messages in the Spam Quarantine , on page 972
• Disk Space for the Spam Quarantine , on page 974
• About Disabling the External Spam Quarantine , on page 975
• Troubleshooting Spam Quarantine Features , on page 975
Overview of the Spam Quarantine
The Spam Quarantine (also known as ISQ) and End-User Quarantine (also known as EUQ) provides a safeguard
mechanism for organizations that are concerned about “false positives” — that is, legitimate email messages
that the email gateway has deemed to be spam. When the email gateway determines that a message is spam
or suspected spam, you may want to let the recipient or an administrator review the message before delivering
or deleting it. The spam quarantine stores messages for this purpose.
Administrative users of the email gateway can view all messages in a spam quarantine. End users, usually the
message recipients, can view their own quarantined messages in a slightly different web interface.
The spam quarantine is separate from policy, virus, and outbreak quarantines.
Related Topics
• Managing Spam and Graymail, on page 383
• Policy, Virus, and Outbreak Quarantines, on page 927
Local Versus External Spam Quarantine
A local spam quarantine stores spam and suspect spam on the email gateway. An external spam quarantine
can store these messages on a separate Cisco Secure Email and Web Manager.
Consider using an external spam quarantine if:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
947
Spam Quarantine
Setting Up the Local Spam Quarantine
• You want a centralized location to store and manage spam from multiple email gateways.
• You want to store more spam than the email gateway can hold.
• You want to regularly back up the spam quarantine and its messages.
Related Topics
• Disk Space for the Spam Quarantine , on page 974
• Working with an External Spam Quarantine , on page 1286
Setting Up the Local Spam Quarantine
The following table shows how to send messages to a Spam Quarantine
Procedure
Command or Action Purpose
Step 1 Enable the Anti-Spam feature if you have not For more information, see Managing Spam and
yet done so. Graymail, on page 383.
Step 2 Enable and configure quarantine settings. For more information, see Enabling and
Configuring the Spam Quarantine on the Legacy
Web Interface , on page 949.
Step 3 Adjust the disk space allocated to the spam For more information, see Managing Disk
quarantine Space , on page 1023
Step 4 Enable browser access to the quarantine. For more information, see Configuring the IP
Interface for Browser Access to the Spam
Quarantine , on page 950
Step 5 Configure the email gateway to send spam to For more information, see
the quarantine.
• Configuring a Mail Policy to Quarantine
Spam , on page 952
• Limiting Which Recipients Have Mail
Quarantined , on page 952
Step 6 Specify a default character encoding for For more information, see Ensuring That
messages that do not have this information in Message Text Displays Correctly , on page 952
the heading.
What to do next
Related Topics
• Configuring the IP Interface for Browser Access to the Spam Quarantine , on page 950
• Configuring Administrative User Access to the Spam Quarantine , on page 951
• Configuring a Mail Policy to Quarantine Spam , on page 952
• Limiting Which Recipients Have Mail Quarantined , on page 952
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
948
Spam Quarantine
Enabling and Configuring the Spam Quarantine on the Legacy Web Interface
• Ensuring That Message Text Displays Correctly , on page 952
• Spam Quarantine Language, on page 953
Enabling and Configuring the Spam Quarantine on the Legacy Web Interface
Procedure
Step 1 [New Web Interface Only] On the email gateway, click to load the legacy web interface.
Step 2 Select Spam Quarantine.
Step 3 If you have not previously enabled the spam quarantine, select Enable Spam Quarantine.
If you are editing spam quarantine settings, click the Spam Quarantine link in the Quarantine Name column
of the Spam Quarantine section.
Step 4 Specify options:
Option Description
Deliver Messages Via All outgoing quarantine-related email (such as spam notifications
and messages released from the spam quarantine) must be delivered
via another email gateway or server that is configured to send
messages.
You can route these messages through an SMTP or groupware
server, or you can specify the outbound listener interface of an
email gateway (typically the Data 2 interface).
The alternate address is used for load balancing and failover.
If you have multiple email gateways, you can use the outbound
listener interface of any managed email gateways for the primary
and alternate addresses. Both must use the same interface (either
Data 1 or Data 2) as the outbound listener.
Read instructions on the screen for additional caveats about these
addresses.
Schedule Delete After Specify the number of days to hold messages before deleting them.
Cisco recommends that you configure the quarantine to delete older
messages to prevent the quarantine from filling to capacity, but you
can elect not to schedule automatic deletion.
Notify Cisco Upon Message Release Check the Send a copy of released messages to Cisco for
analysis(recommended) checkbox if you wish to notify Cisco
upon message release.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
949
Spam Quarantine
Configuring the IP Interface for Browser Access to the Spam Quarantine
Option Description
Spam Quarantine Appearance Logo
By default, the Cisco logo is displayed at the top of the spam
quarantine page when the user logs in to view quarantined messages.
To use a custom logo instead, upload the logo. The logo should be
a .jpg, .gif, or .png file that is at most 50 pixels high by 500 pixels
wide.
Login page message
(Optional) Specify a login page message. This message is shown
to end users and administrators when they log in to view the
quarantine.
If you do not specify a message, the following message appears:
Enter your login information below. If you are unsure what to enter,
please contact your administrator.
Administrative Users See Configuring Administrative User Access to the Spam
Quarantine , on page 951.
Step 5 Submit and commit your changes.
What to do next
• Return to Setting Up the Local Spam Quarantine, on page 948
Configuring the IP Interface for Browser Access to the Spam Quarantine
When administrators and end users access the spam quarantine, a separate browser window opens.
Procedure
Step 1 [New Web Interface Only] On the email gateway, click to load the legacy web interface.
Step 2 Choose Network > IP Interfaces.
Step 3 Click the interface name (for this example, we will use the Management interface).
Step 4 In the Spam Quarantine section, configure settings for access to the spam quarantine:
• By default, HTTP uses port 82 and HTTPS uses port 83.
• Specify the URL that appears in notifications and in the spam quarantine browser window.
If you do not want to expose the hostname of your Cisco Secure Email and Web Manager to end users,
you can specify an alternate hostname.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
950
Spam Quarantine
Configuring Administrative User Access to the Spam Quarantine
Step 5 Submit and commit your changes.
What to do next
Ensure that your DNS server can resolve the hostname that you specified for spam quarantine access.
Configuring Administrative User Access to the Spam Quarantine
All users with administrator privileges can change spam quarantine settings and view and manage messages
in the spam quarantine. You do not need to configure spam quarantine access for administrator users.
If you configure access to the spam quarantine for users with the following roles, they can view, release, and
delete messages in the spam quarantine:
• Operator
• Read-only operator
• Help desk user
• Guest
• Custom user roles that have spam quarantine privileges
These users cannot access spam quarantine settings.
Before you begin
Create users or custom user roles that have access to the spam quarantine. For more information, see Distributing
Administrative Tasks, on page 977
Procedure
Step 1 On the Cisco Secue Email and Web Manager, click Service Status and hover over the corresponding to
Spam Quarantine and click Edit Spam Quarantine Settings.
Step 2 Click the toggle switch to enable Spam Quarantine.
Step 3 Click the link for the type of user to add: local, externally authenticated, or custom role.
If you have already added users or roles, click a username or role to view all eligible users or roles.
Step 4 Select the users or roles that you want to add.
Users with Administrator privileges are not listed because they automatically have full access to the spam
quarantine.
Step 5 Click OK.
Step 6 Click Submit.
What to do next
Related Topics
Configuring End-User Access to the Spam Quarantine , on page 966
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
951
Spam Quarantine
Configuring a Mail Policy to Quarantine Spam
Configuring a Mail Policy to Quarantine Spam
Once you have enabled the spam quarantine, you can configure a mail policy to send spam or suspected spam
to that quarantine. Anti-spam scanning must be enabled on the mail policy in order to send mail to the spam
quarantine.
Procedure
Step 1 On the Mail Policies > Incoming Mail Policies page, click the link in the Anti-Spam column for the
corresponding mail policy.
Step 2 In the Anti-Spam Settings section, select Use IronPort Anti-Spam service.
Step 3 In the Positively-Identified Spam Settings section, select Spam Quarantine for the Apply This Action to
Message option.
Step 4 Configure settings for suspected spam and marketing email.
Step 5 Submit and commit your changes.
Limiting Which Recipients Have Mail Quarantined
You can use multiple mail policies on the email gateway (Mail Policies > Incoming Mail Policy) to specify
a list of recipient addresses for which mail will not be quarantined. Select ‘Deliver’ or ‘Drop’ instead of
quarantine when configuring the anti-spam settings for the mail policy.
Ensuring That Message Text Displays Correctly
AsyncOS attempts to determine the character set of a message based on the encoding that is specified in the
message headers. However, if the encoding specified in the headers does not match that of the actual text, the
message will not be displayed properly when viewed in the spam quarantine. This situation is more likely to
occur with spam messages.
To ensure that message text displays correctly for these messages, see .
Related Topic
• Specifying a Default Encoding , on page 952
Specifying a Default Encoding
If an incoming message does not have a character set encoding specified in the headers, you can configure
your email gateway to specify a default encoding.
Doing so will help ensure that these types of messages display properly in the spam quarantine. However,
specifying a default encoding can cause messages in other character sets to display incorrectly. This setting
applies only to messages that do not specify the encoding in the message headers. Generally, you would only
set a default encoding if you expect the majority of your mail that falls into this category to be of one specific
encoding.
For example, if most quarantined messages that do not specify the character set encoding in the message
headers are in Japanese (ISO-2022-JP), you can set the encoding on the Scan Behavior page as Japanese
(ISO-2022-JP).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
952
Spam Quarantine
Spam Quarantine Language
Procedure
Step 1 Click Security Services > Scan Behavior.
Step 2 Under Global Settings, click Edit Global Settings.
Step 3 From the Encoding to use when none is specified drop-down list, select the desired encoding type.
Step 4 Click Submit.
Step 5 Click Commit Changes.
Spam Quarantine Language
Each user selects a language in the spam quarantine from the Options menu at the top right of the window.
Using Safelists and Blocklists to Control Email Delivery Based
on Sender
Administrators and end users can use safelists and blocklists to help determine which messages are spam.
Safelists specify senders and domains that are never treated as spam. Blocklists specify senders and domains
that are always treated as spam.
You can allow end users (email users) to manage the safelist and blocklist for their own email accounts. For
example, an end user may receive email from a mailing list that no longer interests him. He may decide to
add this sender to his blocklist to prevent emails from the mailing list from being sent to his inbox. On the
other hand, end users may find that emails from specific senders are sent to their spam quarantine when they
do not want them to be treated as spam. To ensure that messages from these senders are not quarantined, they
may want to add the senders to their safelists.
Changes that end users and administrators make are visible to and can be changed by either.
Related Topics
• Message Processing of Safelists and Blocklists , on page 953
• Enabling Safelists and Blocklists on the Legacy Web Interface, on page 954
• External Spam Quarantine and Safelist/Blocklists , on page 955
• Adding Senders and Domains to Safelists and Blocklists (Administrators) , on page 955
• About End-User Access to Safelists and Blocklists , on page 960
• Synchronizing Safelists or Blocklists on Multiple Email Gateways (Deployments Without a Cisco Secure
Email and Web Manager) , on page 962
• Backing Up and Restoring the Safelist/Blocklist , on page 962
• Troubleshooting Safelists and Blocklists, on page 963
Message Processing of Safelists and Blocklists
A sender’s being on a safelist or blocklist does not prevent the email gateway from scanning a message for
viruses or determining if the message meets the criteria for a content-related mail policy. Even if the sender
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
953
Spam Quarantine
Enabling Safelists and Blocklists on the Legacy Web Interface
of a message is on the recipient’s safelist, the message may not be delivered to the end user depending on
other scanning settings and results.
When you enable safelists and blocklists, the email gateway scans the messages against the safelist/blocklist
database immediately before anti-spam scanning. If the email gateway detects a sender or domain that matches
a safelist or blocklist entry, 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 the safelist
or the 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 by the anti-spam scanning engine. Both messages then
continue along the pipeline (through anti-virus scanning, content policies, and so on) and are subject to any
configured settings.
If a message sender or domain is blocklisted, the delivery behavior depends on the blocklist action that you
specify when you enable the safelist/blocklist feature. 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
to quarantine, the message is scanned and eventually quarantined. If the blocklist action is configured to delete,
the message is dropped immediately after safelist/blocklist scanning.
Because safelists and blocklists are maintained in the spam quarantine, delivery behavior is also contingent
on other anti-spam settings. For example, if you configure the “Accept” mail flow policy in the Host Access
Table (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 mail flow
policy that skips anti-spam scanning for certain message recipients, these recipients will not have their safelist
and blocklist settings applied.
Related Topics
• Enabling Safelists and Blocklists on the Legacy Web Interface, on page 954
• External Spam Quarantine and Safelist/Blocklists , on page 955
Enabling Safelists and Blocklists on the Legacy Web Interface
Before you begin
• The spam quarantine must be enabled. See Setting Up the Local Spam Quarantine, on page 948.
• Configure the email gateway to use an external safelist/blocklist. See instructions for setting up an external
spam quarantine in the documentation for your email gateway.
Procedure
Step 1 [New Web Interface Only] On the email gateway, click to load the legacy web interface.
Step 2 Navigate to Spam Quarantine.
Step 3 Under End-User Safelist/Blocklist, click Edit Settings.
Step 4 Select Enable End User Safelist/Blocklist Feature.
Step 5 Select Quarantine or Delete for the Blocklist Action.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
954
Spam Quarantine
External Spam Quarantine and Safelist/Blocklists
Step 6 Specify Maximum List Items Per User.
This is the maximum number of addresses or domains for each list, for each recipient. If you allow a large
number of list entries per user, system performance might be adversely affected.
Step 7 Select Update Frequency.
This value determines how often AsyncOS updates the safelists/blocklists on the email gateways that use the
external spam quarantine. The significance of this setting is described in External Spam Quarantine and
Safelist/Blocklists , on page 955.
Step 8 Select the update frequency. This value determines how often AsyncOS updates the safelists/blocklists on
the email gateways that use the external spam quarantine. The significance of this setting is described in
External Spam Quarantine and Safelist/Blocklists , on page 955.
Step 9 Submit and commit your changes.
External Spam Quarantine and Safelist/Blocklists
If you use an external spam quarantine on a Cisco Secure Email and Web Manager, the safelist/blocklist is
saved on the management appliance. This gives you a single location to manage safe and blocked senders for
all appliances.
Because the email gateway evaluates senders in safelists and blocklists when processing incoming mail,
safelists and blocklists that are stored on a Cisco Secure Email and Web Manager must be sent to the email
gateway in order to be applied to incoming mail. When you configure the safelist/blocklist feature on a Cisco
Secure Email and Web Manager, you configure the frequency of these updates.
For more information about working with external safelists and blocklists on a Cisco Secure Email and Web
Manager, see the topics under the Cisco Secure Email and Web Manager User Guide
Adding Senders and Domains to Safelists and Blocklists (Administrators)
Manage safelists and blocklists via the spam quarantine interface.
You can also see whether many recipients (end users in your organization) have included a particular sender
or domain in allowed list or blocked list.
Administrators see and work with the superset of the same entries that each end user sees and works with.
Before you begin
• Ensure that you can access the spam quarantine. See Accessing the Spam Quarantine (Administrative
Users), on page 972.
• Enable access to the safelist/blocklist. See Enabling Safelists and Blocklists on the Legacy Web Interface,
on page 954.
• (Optional) To import safelist/blocklists instead of building these lists using the procedure in this section,
use the process described in Backing Up and Restoring the Safelist/Blocklist , on page 962.
• Understand the required format of safelist and blocklist entries. See Syntax for Safelists and Blocklist
Entries , on page 959.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
955
Spam Quarantine
Adding Senders and Domains to Safelists and Blocklists (Administrators)
Procedure
Step 1 [New Web Interface Only] On the email gateway, click Quarantine > Spam Quarantine > Search.
Or
Choose Monitor > Spam Quarantine and select the Options drop-down menu in the upper right corner of
the page.
Step 2 Choose Safelist or Blocklist.
Step 3 (Optional) Search for a sender or recipient.
Step 4 Do one or more of the following:
To Do This
Add multiple senders for a recipient To add multiple senders for a recipient on the new web interface:
a. Select Recipient tab.
b. Click on the + icon to add a recipient address and sender list.
c. Enter the recipient email address.
d. Enter the sender email addresses and domains.
Put each entry on a separate line, or separate each entry with a
comma.
e. Click to save the entry.
To modify an existing sender address, select the checkbox next to
the required recipient address, click the edit icon, modify the sender
address and click to save the entry.
To add multiple senders for a recipient on the legacy web interface:
a. Select View by: Recipient
b. Click Add, or click Edit for a recipient.
c. Enter or edit the recipient email address.
d. Enter sender email addresses and domains.
Put each entry on a separate line, or separate each entry with a
comma.
e. Click Submit.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
956
Spam Quarantine
Adding Senders and Domains to Safelists and Blocklists (Administrators)
To Do This
Add multiple recipients for a sender To add multiple recipient for a sender on the new web interface:
a. Select Sender tab.
b. Click + to add a sender address and recipient list.
c. Enter the sender address or domain.
d. Enter the recipient email addresses.
Put each entry on a separate line, or separate each entry with a
comma.
e. Click to save the entry.
To modify an existing recipient address, select the checkbox next
to the required sender address, click the edit icon, modify the sender
address and click to save the entry.
To add multiple recipient for a sender on the legacy web interface:
a. Select View by: Sender
b. Click Add, or click Edit for a sender.
c. Enter or edit the sender address or domain.
d. Enter recipient email addresses.
Put each entry on a separate line, or separate each entry with a
comma.
e. Click Submit.
Delete all senders associated with a To delete all senders associated with a recipient on the new web
recipient interface:
a. Select the checkbox next to the recipient or sender address to
select the entry.
You can select and delete all entries.
b. Click on the trash can icon to delete an entire table row.
To delete all senders associated with a recipient on the legacy web
interface:
a. Select a View by option.
b. Click a trash can icon to delete an entire table row.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
957
Spam Quarantine
Adding Senders and Domains to Safelists and Blocklists (Administrators)
To Do This
Delete all recipients associated with a To delete all recipients associated with a sender on the new web
sender interface:
a. Select the checkbox next to the recepient or sender address to
select the entry.
You can select and delete all entries.
b. Click on the trash can icon to delete an entire table row.
To delete all recipients associated with a sender on the legacy web
interface:
a. Select a View by option.
b. Click a trash can icon to delete an entire table row.
Delete individual senders for a recipient To delete individual senders for a recipient on the new web
interface:
a. Select the checkbox next to the recepient or sender address to
select the entry.
You can select and delete multiple entries.
b. Click on the edit icon to modify an individual recipient or
sender.
c. Add or remove entries from the text box. You must leave at
least one entry.
d. Click to save the entry.
To delete individual senders for a recipient on the legacy web
interface:
a. Select a View by option.
b. Click Edit for an individual recipient or sender.
c. Add or remove entries from the text box. You must leave at
least one entry.
d. Click Submit.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
958
Spam Quarantine
Syntax for Safelists and Blocklist Entries
To Do This
Delete individual recipients for a sender To delete individual recipient for a sender on the new web interface:
a. Select the checkbox next to the recepient or sender address to
select the entry.
You can select and delete multiple entries.
b. Click on the edit icon to modify an individual recipient or
sender.
c. Add or remove entries from the text box. You must leave at
least one entry.
d. Click to save the entry.
To delete individual senders for a recipient on the legacy web
interface:
a. Select a View by option.
b. Click Edit for an individual recipient or sender.
c. Add or remove entries from the text box. You must leave at
least one entry.
d. Click Submit.
What to do next
Related Topics
• Syntax for Safelists and Blocklist Entries , on page 959
• Clearing All Safelists and Blocklists , on page 960
Syntax for Safelists and Blocklist Entries
Senders can be added to safelists and blocklists using the following formats:
• [email protected]
• server.domain.com
• domain.com
• [10.1.1.0]
• [ipv6:2001:DB8:1::1]
• user@[1.2.3.4]
• user@[ipv6:2001:db8::1]
An identical entry, such as a sender address or a domain, cannot be included on both the safelist and the
blocklist at the same time. However, a domain can be on a safelist while an email address for a sender belonging
to that domain is on the blocklist (or vice versa), and both rules apply. For example, if example.com is on the
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
959
Spam Quarantine
Clearing All Safelists and Blocklists
safelist, [email protected] can be on the blocklist. In this case, the email gateway delivers all mail from
example.com without scanning for spam, except mail from [email protected], which is treated as spam.
It is not possible allow or block a range of subdomains using the following syntax: .domain.com . However,
it is possible to block a specific domain using the following syntax: server.domain.com .
Clearing All Safelists and Blocklists
If you need to delete all safelist and blocklist entries, including all senders and all recipients, import a file
with no entries using the procedure in Backing Up and Restoring the Safelist/Blocklist , on page 962.
About End-User Access to Safelists and Blocklists
End users access their safelist and blocklist via the spam quarantine. To configure end-user access to the spam
quarantine, see Setting Up End-User Access to the Spam Quarantine via Web Browser .
You may want to give your end users the URL of the spam quarantine and the instructions below, as applicable.
Related Topics
• Adding Entries to Safelists (End Users)
• Adding Senders to Blocklists (End Users)
Adding Entries to Safelists (End Users)
Note Delivery of messages from safelisted senders depends on other settings that are configured in the system. See
Message Processing of Safelists and Blocklists , on page 953.
End users can add senders to safelists in two ways:
• Adding the Sender of a Quarantined Message to the Safelist , on page 960
• Adding Senders to the Safelist Without a Quarantined Message , on page 961
Adding the Sender of a Quarantined Message to the Safelist
End users can add senders to the safelist if the message has been sent to the spam quarantine.
Procedure
Step 1 [New Web Interface Only] Choose Quarantine > Spam Quarantine > Safelist.
Or
Choose Monitor > Spam Quarantine > Safelist.
Step 2 [New Web Interface Only] Click Release and Add to Safelist icon to release the message and add it to the
safelist.
Or
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
960
Spam Quarantine
Adding Senders to the Safelist Without a Quarantined Message
Select Release and Add to Safelist from the drop-down menu.
The envelope sender and the from header for the specified mail are both added to the safelist, and the released
messages proceed directly to the destination queue, skipping any further work queue processing in the email
pipeline.
Adding Senders to the Safelist Without a Quarantined Message
Procedure
Step 1 [New Web Interface Only] Choose Quarantine > Spam Quarantine > Safelist and click the plus icon on
the top right side page.
Step 2 [New Web Interface Only] Enter the email address or domain. You can enter multiple domains and email
addresses, separated by commas.
Step 3 [New Web Interface Only] Click to save the entry.
Step 4 Optionally you can perform this task from the legacy interface:
a) Choose Monitor > Spam Quarantine.
b) Select the Options drop-down menu in the upper right corner of the page
c) Choose Safelist.
d) From the Safelist dialog box, enter the email address or domain. You can enter multiple domains and
email addresses, separated by commas.
e) Click Add to List.
Adding Senders to Blocklists (End Users)
Messages from blocklisted senders may be rejected or quarantined, depending on the safelist/blockist action
settings defined by your administrator.
Note You can add blocklist entries only using this procedure.
Procedure
Step 1 [New Web Interface Only] Choose Quarantine > Spam Quarantine .
Step 2 [New Web Interface Only] Choose Blocklist, click the + icon and enter the domain or email address that you
want to blocklist. You can enter multiple domains and email addresses, separated by commas.
Step 3 [New Web Interface Only] Click to save the entry.
Step 4 Optionally you can perform this task from the legacy interface:
a) Choose Monitor > Spam Quarantine.
b) Choose Blocklist from the Options drop-down menu in the upper right corner of the page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
961
Spam Quarantine
Synchronizing Safelists or Blocklists on Multiple Email Gateways (Deployments Without a Cisco Secure Email and Web Manager)
c) Enter the domain or email address that you want to blocklist. You can enter multiple domains and email
addresses, separated by commas.
d) Click Add to List.
SynchronizingSafelistsorBlocklistsonMultipleEmailGateways(Deployments
Without a Cisco Secure Email and Web Manager)
If you use multiple email gateways without a Cisco Secure Email and Web Manager, you may need to manually
synchronize the safelist/blocklist and its configuration settings across the different email gateways.
You can export and import a .csv file using the procedure described in Backing Up and Restoring the
Safelist/Blocklist , on page 962, then use FTP to upload and download the file.
Backing Up and Restoring the Safelist/Blocklist
Before you upgrade your email gateway or run the installation wizard, you should back up the safelist/blocklist
database. Safelist/blocklist information is not included in the main XML configuration file that contains your
appliance configuration settings.
You can also use this procedure to save a copy of the safelist/blocklist to synchronize multiple email gateways.
Procedure
Step 1 [New Web Interface Only] On the email gateway, clcik to load the legacy web interface.
Step 2 Select System Administration > Configuration File.
Step 3 Scroll to the End-User Safelist/Blocklist Database (Spam Quarantine) section.
To Do This
Export the safelist/blocklist Note the path and filename of the .csv file, and modify as needed.
Click Backup Now.
The email gateway saves a .csv file to the /configuration directory of the email
gateway using the following naming convention:
slbl<serial number><timestamp>.csv
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
962
Spam Quarantine
Troubleshooting Safelists and Blocklists
To Do This
Import the safelist/blocklist Caution This process will overwrite all existing entries in safelists and
blocklists for all users.
Click Select File to Restore.
Select the desired file from the list of files in your configuration directory.
Select the safelist/blocklist backup file that you want to restore.
Click Restore.
Troubleshooting Safelists and Blocklists
To troubleshoot issues with safelists and blocklists, you can view the log files or system alerts.
When an email is blocked due to safelist/blocklist settings, the action is logged in the ISQ_log files or the
antispam log files. Emails that are safelisted are marked as safelisted with an X-SLBL-Result-Safelist header.
Emails that are blocklisted are marked as blocklisted with an X-SLBL-Result-Blocklist header.
Alerts are sent out when the database is created or updated, or if there are errors in modifying the database or
running the safelist/blocklist processes.
For more information about alerts, see Alerts, on page 1043.
For more information about log files, see Logging, on page 1141.
Related Topics
• Message from Safelisted Sender Was Not Delivered , on page 963
Message from Safelisted Sender Was Not Delivered
Problem
Message from a safelisted sender was not delivered.
Solution
Possible causes:
• The message was dropped for malware or content violations. See Message Processing of Safelists and
Blocklists , on page 953.
• If you have multiple email gateways and the sender was recently added to the safelist, then
safelist/blocklists might not have been synchronized at the time the message was processed. See External
Spam Quarantine and Safelist/Blocklists , on page 955 and Synchronizing Safelists or Blocklists on
Multiple Email Gateways (Deployments Without a Cisco Secure Email and Web Manager) , on page
962.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
963
Spam Quarantine
Configuring Spam Management Features for End Users
Configuring Spam Management Features for End Users
To See
Understand the benefits and limitations of the different Configuring End-User Access to the Spam
authentication methods for end-user access to spam Quarantine , on page 966 and subsections
management features.
Allow end users to access the spam quarantine directly via Authentication Options for End Users
browser. Accessing Spam Management Features , on
page 964
Send users a notification when messages addressed to them Notifying End Users About Quarantined
are routed to the spam quarantine. Messages , on page 968
Notifications can include links for access to the spam
quarantine.
Allow users to specify email addresses and domains of Using Safelists and Blocklists to Control Email
senders whom they know to be safe, and of senders whom Delivery Based on Sender , on page 953
they know to be sending spam or other unwanted mail.
Related Topics
• Authentication Options for End Users Accessing Spam Management Features , on page 964
• Setting Up End-User Access to the Spam Quarantine via Web Browser , on page 966
• Notifying End Users About Quarantined Messages , on page 968
Authentication Options for End Users Accessing Spam Management Features
Note Mailbox authentication does not allow users to view messages addressed to an email alias.
For End-User Spam Quarantine Access Do This
Directly via web browser, authentication 1. In the End User Quarantine Access settings, choose
required LDAP, or Mailbox (IMAP/POP).
and 2. In the Spam Notifications settings, deselect Enable login
without credentials for quarantine access.
Via a link in a notification, authentication
required
Directly via web browser, authentication 1. In the End User Quarantine Access settings, choose
required LDAP, or Mailbox (IMAP/POP).
and 2. In the Spam Notifications settings, select Enable login
without credentials for quarantine access.
Via a link in a notification, authentication not
required
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
964
Spam Quarantine
LDAP Authentication Process
For End-User Spam Quarantine Access Do This
Only via a link in a notification, authentication In the End User Quarantine Access settings, choose None as
not required the authentication method.
No access In the End User Quarantine Access settings, deselect Enable
End-User Quarantine Access.
Related Topics
• LDAP Authentication Process , on page 965
• Configuring End-User Access to the Spam Quarantine , on page 966
• Notifying End Users About Quarantined Messages , on page 968
• Authentication Options for End Users Accessing Spam Management Features , on page 964
• About End-User Access to Safelists and Blocklists , on page 960
LDAP Authentication Process
1. A user enters his or her username and passphrase into the web UI login page.
2. The spam quarantine connects to the specified LDAP server either to perform an anonymous search or
as an authenticated user with the specified “Server Login” DN and passphrase. For Active Directory, you
will usually need to have the server connect on the “Global Catalog port” (it is in the 6000s) and you need
to create a low privilege LDAP user that the spam quarantine can bind as in order to execute the search.
3. The spam quarantine then searches for the user using the specified BaseDN and Query String. When a
user’s LDAP record is found, the spam quarantine then extracts the DN for that record and attempts bind
to the directory using the user records’ DN and the passphrase they entered originally. If this passphrase
check succeeds then the user is properly authenticated, but the spam quarantine still needs to determine
which mailboxes’ contents to show for that user.
4. Messages are stored in the spam quarantine using the recipient's envelope address. After a user's passphrase
is validated against LDAP, the spam quarantine then retrieves the “Primary Email Attribute” from the
LDAP record to determine which envelope address they should show quarantined messages for. The
“Primary Email Attribute” can contain multiple email addresses which are then used to determine what
envelope addresses should be displayed from the quarantine for the authenticated user.
Related Topics
• Authentication Options for End Users Accessing Spam Management Features , on page 964
IMAP/POP Authentication Process
1. Depending on your mail server configuration, a user enters their username ( joe ) or email address (
[email protected] ) and passphrase into the web UI login page. You can modify the Login Page Message
to tell your users whether they should enter a full email address or just their username (see Configuring
End-User Access to the Spam Quarantine , on page 966).
2. The spam quarantine connects to the IMAP or POP server and uses the entered login (either username or
email address) and passphrase to try to log into the IMAP/POP server. If the passphrase is accepted then
the user is considered authenticated and the spam quarantine immediately logs out of the IMAP/POP
server.
3. Once the user is authenticated, the spam quarantine lists email for the user, based on the email address:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
965
Spam Quarantine
Setting Up End-User Access to the Spam Quarantine via Web Browser
• If you have configured the spam quarantine to specify a domain to append to bare usernames (like
joe ), then this domain is appended and that fully qualified email address is used to search for matching
envelopes in the quarantine.
• Otherwise, the spam quarantine uses the entered email address to search for matching envelopes.
For more information about IMAP, see the University of Washington web site:
http://www.washington.edu/imap/
Setting Up End-User Access to the Spam Quarantine via Web Browser
Procedure
Step 1 Understand the benefits and limitations of the different authentication methods for end-user access to spam
management features.
Step 2 If you will authenticate end users using LDAP, configure an LDAP server profile, including the Spam
Quarantine End-User Authentication Query settings on the System Administration > LDAP > LDAP
Server Profile page.
Example:
If you will authenticate end users using SAML 2.0 (SSO), configure the settings on the
System Administration > SAML page.
Step 3 Configure end-user access to the spam quarantine.
Configuring End-User Access to the Spam Quarantine , on page 966
Step 4 Determine the URL for end-user access to the spam quarantine.
Determining the URL for End-User Access to the Spam Quarantine, on page 967
What to do next
Related Topics
• Configuring End-User Access to the Spam Quarantine , on page 966
• Determining the URL for End-User Access to the Spam Quarantine, on page 967
• Which Messages an End User Sees , on page 968
Configuring End-User Access to the Spam Quarantine
Administrative users can access the spam quarantine whether or not end-user access is enabled.
Before you begin
See requirements in Authentication Options for End Users Accessing Spam Management Features , on page
964.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
966
Spam Quarantine
Determining the URL for End-User Access to the Spam Quarantine
Procedure
Step 1 If you are on the legacy interface, navigate to Management Appliance > Centralized Services > Monitor >
Spam Quarantine > Edit Settings, and then scroll down to End-User Quarantine Access.If you are on the
new web interface, then navigate to Cisco Secure Email and Web Manager, click Service Status and hover
on icon and click Edit End-User Quarantine Settings. You will be redirected to the legacy interface.
Step 2 Select Enable End-User Quarantine Access.
Step 3 Specify the method to use to authenticate end users when they attempt to view their quarantined messages.
Select This Option More Information
None Choose this option to make the quarantined messages accessible to the
end-users via links in the spam notification without additional
authentication.
Mailbox (IMAP/POP) For sites without an LDAP directory to use for authentication, the
quarantine can validate user email addresses and passphrases against a
standards-based IMAP or POP server that holds their mailbox.
When logging in to the spam quarantine, end users enter their full email
address and mailbox passphrase.
If the POP server advertises APOP support in the banner, then for security
reasons (i.e., to avoid sending the passphrase in the clear) the Cisco
appliance will only use APOP. If APOP is not supported for some or all
users then the POP server should be reconfigured to not advertise APOP.
Select SSL if you have configured your server to use it. If users enter
username only, you can specify a domain to add to automatically complete
the email address. Enter the domain of the envelope for users logging in
to “Append Domain to Unqualified Usernames.”
LDAP Configure LDAP settings as described in the sections referenced in the
Before You Begin section of this topic.
Step 4 Specify whether or not to display message bodies before messages are released.
If this box is selected, users may not view the message body via the spam quarantine page. Instead, to view
the body of a quarantined message, users must release the message and view it in their mail application (such
as Microsoft Outlook). You can use this feature for policy and regulation compliance — for example, if a
regulation requires that all viewed email be archived.
Step 5 Submit and commit your changes.
Determining the URL for End-User Access to the Spam Quarantine
The URL that end users can use to directly access the spam quarantine is formed from the hostname of the
machine and the settings (HTTP/S and port numbers) configured on the IP interface on which the quarantine
has been enabled. For example, HTTP://mail3.example.com:82.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
967
Spam Quarantine
Which Messages an End User Sees
The end-users can now access the Spam Quarantine on the new web interface in any one of the following
ways:
• When trailblazerconfig CLI command is enabled, use the following URL -
https://example.com:<trailblazer-https-port>/euq-login.
where example.com is the appliance host name and <trailblazer-https-port> is the trailblazer HTTPS
port configured on the appliance.
• When trailblazerconfig CLI command is disabled, use the following URL -
https://example.com:<https-port>/euq-login.
where example.com is the appliance host name and <https-port> is the HTTPS port configured on the
appliance.
Note Local and externally-authenticated users cannot log into the end-user Spam Qurantine portal.
Which Messages an End User Sees
Generally, end users see only their own messages in the spam quarantine.
Depending on the method of access (via notification or directly via web browser) and authentication method
(LDAP or IMAP/POP), users may see mail for multiple email addresses in the spam quarantine.
When LDAP authentication is used, if the Primary Email attribute has multiple values in the LDAP directory,
all of those values (addresses) will be associated with the user. Therefore, quarantined messages addressed
to all email addresses associated with the end user in the LDAP directory are present in the quarantine.
If the authentication method is IMAP/POP, or the user accesses the quarantine directly via a notification, then
the quarantine will display only messages for that user’s email address (or the address to which the notification
was sent).
For information about messages that are sent to aliases of which the user is a member, see Recipient Email
Mailing List Aliases and Spam Notifications , on page 971.
Related Topics
• Configuring End-User Access to the Spam Quarantine , on page 966
• Recipient Email Mailing List Aliases and Spam Notifications , on page 971
Notifying End Users About Quarantined Messages
You can configure the system to send a notification email to some or all users when they have spam and
suspected spam messages in the spam quarantine.
By default, spam notifications lists the end user’s quarantined messages. Notifications include a link that you
can use to view the quarantined messages in the spam quarantine. You can then decide whether to have the
quarantined messages delivered to the inbox or to delete them.
Note In cluster configurations, you can choose which users receive notifications only at the machine level.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
968
Spam Quarantine
Notifying End Users About Quarantined Messages
Before you begin
• For end users to manage messages listed in notifications, they must be able to access the spam quarantine.
See Configuring End-User Access to the Spam Quarantine , on page 966.
• Understand and implement the authentication options for managing spam using notifications. See
Authentication Options for End Users Accessing Spam Management Features , on page 964.
• If end users receive email at multiple aliases, see Recipient Email Mailing List Aliases and Spam
Notifications , on page 971.
Procedure
Step 1 [New Web Interface Only] On the email gateway, click to load the legacy web interface.
Step 2 If you are on the legacy interface, navigate to Management Appliance > Centralized Services > Spam
Quarantine > Edit Settings, and then scroll down to Spam Notifications. However if you are on the new
web interface, navigate to Cisco Secure Email and Web Manager, click Service Status, hover over the
icon, and click Edit Spam Notification Settings. You will be redirected to the legacy interface.
Step 3 Select Enable Spam Notification.
Step 4 Enter a From: address for the notifications.
Step 5 Specify the end-users whom you want to notify.
Step 6 (Optional) Customize the subject for the notification.
Step 7 (Optional) Customize the title for the notification.
Step 8 Select the default language for notifications.
Step 9 Configure the quarantine access for the end-users.
a) Check the Login without credentials check box to automatically log users into the spam quarantine when
they access it by clicking a link in a notification. The end-users can release messages by clicking the
Release links in the notification. If you uncheck this option, the end-users cannot release messages by
clicking the Release links in the notification.
This option is visible only if you choose one of the following end-user authentication methods: Mailbox
(IMAP/POP), LDAP, or SAML 2.0. If you have chosen None as the authentication method, when the
end-users click on the links in the spam notification, they are automatically logged into the spam quarantine.
b) Set an expiration period (in days) for the links in the notification. Enter a number between 0 and 365.
These links will expire automatically after the specified period. Enter 0 if you do not want the links to
expire.
(For Mailbox (IMAP/POP), LDAP, and SAML 2.0) This option is configurable only if you check the
Login without credentials check box.
You can also set the expiration period using the spamdigestconfig command in the CLI.
Step 10 Customize the message body:
a) (Optional) Customize the default text and variables.
To insert a variable, place the cursor where you would like the variable inserted and then click the name
of the variable in the Message Variables listing on the right. Or type in the variable.
The following message variables are expanded to the actual value for the specific end user:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
969
Spam Quarantine
Notifying End Users About Quarantined Messages
• New Message Count ( %new_message_count% )— The number of new messages since the user
last logged in.
• Total Message Count ( %total_message_count% )— The number of messages for the user in the
spam quarantine.
• Days Until Message Expires ( %days_until_expire% )
• Quarantine URL ( %quarantine_url% )— URL to log in to the quarantine and view messages.
• Username ( %username% )
• New Message Table ( %new_quarantine_messages% )— A list of the user’s new quarantined
messages, showing sender, message subject, date, and a link to release the message. The user clicks
a message subject to view the message in the spam quarantine.
• New Message Tablewithout Subject ( %new_quarantine_messages_no_subject% ) — Similar to
New Message Table, but only a “View Message” link is shown in place of the subject for each
message.
b) Choose whether to show or hide the links to view all the quarantined messages in a spam notification.
Under Show link to see all quarantined messages in Notification Mails, choose Yes or No depending
on your requirement.
(For Mailbox (IMAP/POP), LDAP, and SAML 2.0). This option is visible only if you check the Login
without credentials check box (under Quarantine Access).
If you choose Yes, you can force the end-user to authenticate before accessing the spam quarantine. Check
Challenge Access. This option is not available if you have chosen None as the end-user authentication
method.
You can also show or hide the links using the spamdigestconfig command in the CLI.
c) Click Preview Message to verify that the message is as you want it to be.
Step 11 Select a message format (HTML, Text, or HTML/Text).
Step 12 Specify the address to which bounced notifications will be sent.
Step 13 (Optional) Select Consolidate messages sent to the same LDAP user at different addresses.
Step 14 Set the notification schedule.
Step 15 Submit and commit your changes.
What to do next
To ensure that end users receive these notifications, consider recommending that they add the From: address
for the spam quarantine notification emails to the “allowed list” in the junk mail settings of their mail application
(such as Microsoft Outlook or Mozilla Thunderbird.)
Related Topics
• Recipient Email Mailing List Aliases and Spam Notifications , on page 971
• Testing Notifications, on page 971
• Troubleshooting Spam Notifications , on page 971
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
970
Spam Quarantine
Recipient Email Mailing List Aliases and Spam Notifications
Recipient Email Mailing List Aliases and Spam Notifications
Notifications can be sent to each Envelope Recipient that has quarantined email, including mailing lists and
other aliases. Each mailing list receives a single digest. If you send notifications to a mailing list, all subscribers
to the list will receive the notification. Users who belong to multiple email aliases, or who belong to LDAP
groups that receive notifications, or who use several email addresses, may receive multiple spam notifications.
The following table shows example situations in which users may receive multiple notifications.
Table 93: Notifications per Address/Alias
User Email Addresses Aliases Notifications
Sam [email protected] — 1
Mary [email protected] [email protected] 4
[email protected]
[email protected]
Joe [email protected], [email protected] [email protected] 3
If you use LDAP authentication, you can choose not to send notifications to mailing list aliases. Or, if you
choose to send spam notifications to mailing list aliases, you can prevent some occurrences of multiple
notifications. See Spam Quarantine Alias Consolidation Queries, on page 816.
Users who access the spam quarantine by clicking a link in a notification will not see quarantined messages
for any other aliases that the end-user may have, unless the appliance is using a spam quarantine alias
consolidation query for email notifications. If the notification was sent to a distribution list that is expanded
after processing by the appliance, then multiple recipients may have access to the same quarantine for that
list.
This means that all subscribers to a mailing list will receive the notification and can log in to the quarantine
to release or delete messages. In this case, end users visiting the quarantine to view messages mentioned in a
notification may find that those messages have already been deleted by other users.
Note If you do not use LDAP and you do not want your end users to receive multiple email notifications, consider
disabling notifications and instead allow end users to access the quarantine directly and authenticate via LDAP
or POP/IMAP.
Testing Notifications
You can test notifications by configuring a testing mail policy, and having spam quarantined for just a single
user. Then, configure the spam quarantine notification settings: Select the Enable Spam Notification checkbox
and do not select Enable End-User Quarantine Access. Then only the administrator configured in the Deliver
Bounced Messages To field is notified of new spam in the quarantine.
Troubleshooting Spam Notifications
Related Topics
• User Receives Multiple Notifications , on page 972
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
971
Spam Quarantine
User Receives Multiple Notifications
• Recipient Does Not Receive Notifications , on page 972
• User Receives Multiple Notifications , on page 972
• Recipient Does Not Receive Notifications , on page 972
User Receives Multiple Notifications
Problem
A user receives multiple spam notifications for a single message.
Solution
Possible causes:
• The user has multiple email addresses and the spam message was sent to more than one of those addresses.
• The user is a member of one or more email aliases that received the spam message. To minimize
duplications, and for more information, see Recipient Email Mailing List Aliases and Spam Notifications
, on page 971.
Recipient Does Not Receive Notifications
Problem
Recipient is not receiving spam notifications.
Solution
• If notifications are being sent to the “Deliver Bounce Messages To:” address instead of to spam recipients,
this means that spam notifications are enabled, but spam quarantine access is not enabled. See
Authentication Options for End Users Accessing Spam Management Features , on page 964.
• Have the user check the junk mail settings of their email client.
Managing Messages in the Spam Quarantine
This section explains how to work with messages in local or external spam quarantines.
Administrative users can see and manage all messages in the spam quarantine.
Related Topics
• Accessing the Spam Quarantine (Administrative Users), on page 972
• Searching for Messages in the Spam Quarantine, on page 973
• Viewing Messages in the Spam Quarantine, on page 973
• Delivering Messages in the Spam Quarantine, on page 974
• Deleting Messages from the Spam Quarantine, on page 974
Accessing the Spam Quarantine (Administrative Users)
Administrative users can see and manage all messages in the spam quarantine.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
972
Spam Quarantine
Searching for Messages in the Spam Quarantine
Procedure
Step 1 [New Web Interface Only] Choose Quarantine > Spam Quarantine > Search.
Step 2 Select Monitor > Spam Quarantine, then click the number in the Messages column.
Searching for Messages in the Spam Quarantine
Procedure
Step 1 Specify an envelope recipient.
Note You can enter a partial address.
Step 2 Select whether the search results should match the exact recipient you entered, or whether the results should
contain, start with, or end with your entry.
Step 3 Enter a date range to search through. Click the calendar icons to select a date.
Step 4 Specify a From: address, and select whether the search results should contain, match exactly, start with, or
end with the value you entered.
Step 5 Click Search. Messages matching your search criteria are displayed below the Search section of the page.
What to do next
Related Topics
Searching Very Large Message Collections, on page 973
Searching Very Large Message Collections
If you have a very large collection of messages in the spam quarantine, and if your search terms are not
narrowly defined, your query may take a very long time to return information, or it may time out.
You will be prompted to confirm whether you want to resubmit your search. Please note that having multiple
large searches running simultaneously can impact performance.
Viewing Messages in the Spam Quarantine
The message listing shows messages in the spam quarantine. You can select how many messages are shown
at one time. You can sort the display by clicking on the column headings. Click the same column again to
reverse the sorting.
Click the subject of a message to view the message, including the body and headers. The message is displayed
in the Message Details page. The first 20K of the message is displayed. If the message is longer, it is truncated
at 20K and you can download the message via the link at the bottom of the message.
From the Message Details page you can delete a message (select Delete) or select Release to release the
message. Releasing a message causes it to be delivered.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
973
Spam Quarantine
Delivering Messages in the Spam Quarantine
To view additional details about the message, click the Message Tracking link.
Note the following:
• Viewing Messages with Attachments
When viewing a message that includes an attachment, the body of the message is displayed, followed
by a list of attachments.
• Viewing HTML Messages
The spam quarantine attempts to render an approximation of HTML-based messages. Images are not
displayed.
• Viewing Encoded Messages
Base64-encoded messages are decoded and then displayed.
Delivering Messages in the Spam Quarantine
To release a message for delivery, click the checkbox next to the message or messages that you want to release
and select Release from the drop-down menu. Then click Submit.
Click the checkbox in the heading row to automatically select all messages currently displayed on the page.
Released messages proceed directly to the destination queue, skipping any further work queue processing in
the email pipeline.
Deleting Messages from the Spam Quarantine
The spam quarantine can be configured to automatically delete messages after a certain amount of time. Also,
the spam quarantine can be configured to automatically delete the oldest messages once the quarantine has
reached its maximum size. You may also delete messages from the spam quarantine manually.
To delete specific messages, click the checkbox next to the messages that you want to delete and then select
Delete from the drop-down menu. Then click Submit. Click the checkbox in the heading row to automatically
select all of the messages currently displayed on the page.
To delete all messages in the spam quarantine, disable the quarantine (see About Disabling the External Spam
Quarantine , on page 975) and then click the Delete All Messages link. The number in parenthesis at the end
of the link is the number of messages in the spam quarantine.
Disk Space for the Spam Quarantine
By default, messages in the spam quarantine are automatically deleted after a set amount of time. If the
quarantine gets full, older spam is deleted.
Related Topics
• Managing Disk Space , on page 1023
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
974
Spam Quarantine
About Disabling the External Spam Quarantine
About Disabling the External Spam Quarantine
If you disable the spam quarantine:
• If messages are present in the spam quarantine when it is disabled, you can opt to delete all of the messages.
• Any mail polices set to quarantine spam or suspected spam will instead be set to deliver the message.
You may need to adjust mail policies .
• To completely disable an external spam quarantine, disable it on both the email gateway and the Cisco
Secure Email and Web Manager.
Disabling an external spam quarantine on the email gateway only does not delete the external quarantine or
its messages and data.
Troubleshooting Spam Quarantine Features
• Troubleshooting Safelists and Blocklists, on page 963
• Troubleshooting Spam Notifications , on page 971
• Ensuring That Message Text Displays Correctly , on page 952
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
975
Spam Quarantine
Troubleshooting Spam Quarantine Features
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
976
CHAPTER 38
Distributing Administrative Tasks
This chapter contains the following sections:
• Working with User Accounts, on page 977
• Managing Custom User Roles for Delegated Administration, on page 982
• Passphrases, on page 990
• Configuring Access to the Email Gateway, on page 997
• Displaying Messages to Administrative Users , on page 1001
• Managing Secure Shell (SSH) Keys, on page 1001
• Monitoring Administrative User Access , on page 1004
Working with User Accounts
The email gateway provides two methods for adding user accounts: creating user accounts on the email
gateways itself, and enabling user authentication using your own centralized authentication system, which
can be either an LDAP or RADIUS directory. You can manage users and connections to external authentication
sources on the System Administration > Users page in the GUI (or by using the userconfig command
in the CLI). For information about using an external directory to authenticate users, see External Authentication,
on page 992.
Optionally, you can enable two-factor authentication for specific user roles through:
• The System Administration > Users page in the web interface. See Two-Factor Authentication, on page
995.
• The userconfig > twofactorauth command in the CLI. See the CLI Reference Guide for AsyncOS for
Cisco Secure Email Gateway.
The default user account for the system, admin, has all administrative privileges. The admin user account
cannot be deleted, but you can change the passphrase and lock the account.
When you create a new user account, you assign the user to a predefined or a custom user role. Each role
contains differing levels of permissions within the system.
Although there is no limit to the number of user accounts that you can create on the email gateway, you cannot
create user accounts with names that are reserved by the system. For example, you cannot create the user
accounts named “operator” or “root.”
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
977
Distributing Administrative Tasks
User Roles
User Roles
Table 94: User Roles Listing
User Role Description
admin The admin user is the default user account for the system and has all
administrative privileges. The admin user account is listed here for convenience,
but it cannot be assigned via a user role, and it cannot be edited or deleted, aside
from changing the passphrase.
Only the admin user can issue the resetconfig and revert commands.
Administrator User accounts with the Administrator role have full access to all configuration
settings of the system. However, only the admin user has access to the
resetconfig and revert commands.
Note AsyncOS does not support multiple administrators configuring the
email gateway from the GUI simultaneously.
Technician User accounts with the Technician role can perform system upgrades, reboot
the email gateway, and manage feature keys. Technicians can also perform the
following actions in order to upgrade the email gateway:
• Suspend email delivery and receiving.
• View status of workqueue and listeners.
• Save and email configuration files.
• Back up safelists and blocklists. Technicians cannot restore these lists.
• Disconnect the email gateway from a cluster.
• Enable or disable remote service access for Cisco technical support.
• Raise a support request.
Operator User accounts with the Operator role are restricted from:
• Creating or editing user accounts.
• Issuing the resetconfig command.
• Upgrading the email gateway.
• Issuing the systemsetup command or running the System Setup Wizard.
• Issuing the adminaccessconfig command.
• Performing some quarantine functions (including creating, editing, deleting,
and centralizing quarantines).
• Modifying LDAP server profile settings other than username and
passphrase, if LDAP is enabled for external authentication.
Otherwise, they have the same privileges as the Administrator role.
Guest Users accounts with the Guest role can only view status information and reports.
Users with the Guest role can also manage messages in quarantines, if access is
enabled in a quarantine. Users with the Guest role cannot access Message
Tracking.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
978
Distributing Administrative Tasks
Managing Users
User Role Description
Read-Only Operator User accounts with the Read-Only Operator role have access to view
configuration information. Users with the Read-Only Operator role can make
and submit changes to see how to configure a feature, but they cannot commit
them. Users with this role can manage messages in quarantines, if access is
enabled in a quarantine.
Users with this role cannot access the following:
• File system, FTP, or SCP.
• Settings for creating, editing, deleting, or centralizing quarantines.
Help Desk User User accounts with the Help Desk User role are restricted to:
• Message tracking.
• Managing messages in quarantines.
Users with this role cannot access to the rest of the system, including the CLI.
You need to enable access in each quarantine before a user with this role can
manage them.
Custom user role User accounts with a custom user role can only access email security features
assigned to the role. These features can be any combination of DLP policies,
email policies, reports, quarantines, local message tracking, encryption profiles,
Trace debugging tool, and access log subscriptions, Logging APIs, and log files.
The users cannot access system configuration features, including enabling
features globally. Only administrators can define custom user roles. See
Managing Custom User Roles for Delegated Administration, on page 982 for
more information.
Note Users assigned to custom roles cannot access the CLI.
All roles defined in the above table can access both the GUI and the CLI, except the Help Desk User role and
custom user roles, which can only access the GUI.
If you use an LDAP directory to authenticate users, you assign directory groups to user roles instead of
individual users. When you assign a directory group to a user role, each user in that group receives the
permissions defined for the user role. For more information, see External Authentication, on page 992.
Related Topics
• Managing Users, on page 979
Managing Users
The Users page lists the existing users for the system, including the username, full name, and user type or
group.
From the Users page, you can:
• Add new users. For more information, see Adding Users , on page 980.
• Delete users. For more information, see Deleting Users, on page 981.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
979
Distributing Administrative Tasks
Adding Users
• Edit users, such as changing a user’s passphrase and locking and unlocking a user’s account. For more
information, see Editing Users, on page 980.
• Force users to change their passphrases. See Force Users To Change Their Passphrases, on page 981.
• Configure user account and passphrase settings for local accounts. For more information, see Configuring
Restrictive User Account and Passphrase Settings, on page 991.
• Enable the email gateway to use an LDAP or RADIUS directory to authenticate users. For more
information, see External Authentication, on page 992.
• Enable two-factor authentication for specific user roles. For more information, see Two-Factor
Authentication, on page 995.
• Enable access for non-administrators to DLP Matched Content in Message Tracking. See Controlling
Access to Sensitive Information in Message Tracking, on page 981 for more information.
Adding Users
Before You Begin
• Determine the user roles you will use.
• For descriptions of predefined user roles, see User Roles , on page 978.
• To create custom roles, see Managing Custom User Roles for Delegated Administration, on page
982.
• Specify your passphrase requirements. See Configuring Restrictive User Account and Passphrase Settings,
on page 991.
Procedure
Step 1 Choose System Administration > Users.
Step 2 Click Add User.
Step 3 Enter a login name for the user. Some words are reserved (such as “operator” or “root”).
Step 4 Enter the user’s full name.
Step 5 Select a predefined or custom user role.
Step 6 Enter a passphrase.
Note In addition to creating a login passphrase manually, you can also create a system-generated passphrase
to log in to your email gateway.
Step 7 Submit and commit your changes.
Editing Users
Use this procedure to change a passphrase, etc.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
980
Distributing Administrative Tasks
Force Users To Change Their Passphrases
Procedure
Step 1 Choose System Administration > Users.
Step 2 Click the user’s name in the Users listing.
Step 3 Make changes to the user.
Step 4 Submit and commit your changes.
Force Users To Change Their Passphrases
Procedure
Step 1 Choose System Administration > Users.
Step 2 Select the users from the Users listing.
Step 3 Click Enforce Passphrase Change.
Step 4 Choose whether the users must change the passphrase during the next login or after a specified duration (in
days).
Step 5 (Optional) If you are enforcing a passphrase change after a specified duration, set the grace period (in days)
to reset the passphrase after the passphrase expires.
Step 6 Click OK.
Step 7 Submit and commit your changes.
Deleting Users
Procedure
Step 1 Click the trash can icon corresponding to the user’s name in the Users listing.
Step 2 Confirm the deletion by clicking Delete in the warning dialog that appears.
Step 3 Commit your changes.
Controlling Access to Sensitive Information in Message Tracking
You may want to restrict administrative access to message details that are likely to include sensitive information:
• Messages that violate Data Loss Prevention (DLP) policies may include information such as corporate
confidential information or personal information including credit card numbers and health records. By
default, this content is visible to all users who have access to the email gateway.
• URLs that are caught by outbreak filters or by content filters that are based on URL reputation or category
may also be considered sensitive. By default, only users with Administrator privileges can view this
content.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
981
Distributing Administrative Tasks
Managing Custom User Roles for Delegated Administration
This sensitive content appears in dedicated tabs on the Message Details page for messages listed in Message
Tracking results.
You can hide these tabs and their content from administrative users based on their user role. However, although
there is an option to hide this sensitive content from users who have the Administrator role, any user with the
Administrator role can change these permissions and thus view sensitive information at any time.
Before You Begin
Ensure that you have met the prerequisites for these features. See Displaying URL Details in Message Tracking
, on page 463.
Procedure
Step 1 Go to the System Administration > Users page.
Step 2 Under Access to Sensitive Information in Message Tracking, click Edit Settings.
Step 3 Select the roles for which you want to grant access to each type of sensitive information.
Custom roles without access to Message Tracking can never view this information and thus are not listed.
Step 4 Submit and commit your changes.
What to do next
Related Topics
• Message Tracking Details , on page 922
• Displaying Sensitive DLP Data in Message Tracking , on page 535
• Displaying URL Details in Message Tracking , on page 463
Managing Custom User Roles for Delegated Administration
You can design custom user roles and delegate specific responsibilities to users that align with their roles
within your organization, allowing these delegated administrators access only to the email security features
they are responsible for and not the system configuration features that are not related to their roles. Delegated
administration provides more flexible control over your users’ access to the email security features on the
email gateway than the predefined administrator, operator, and help desk user roles.
For example, you may have users who are responsible for managing mail policies for specific domains on the
email gateway, but you do not want these users to access the system administration and security services
configuration features, which the predefined administrator and operator roles grant. You can create a custom
user role for mail policy administrators who can grant these users access to the mail policies they manage,
along with other email security features that they can use to manage messages processed by these policies,
such as Message Tracking and policy quarantines.
Use the System Administration > User Roles page in the GUI (or the userconfig -> role command
in the CLI) to define custom user roles and manage the email security features for which they are responsible,
such as mail policies, DLP policies, email reports, and quarantines. For a full list of email security features
that delegated administrators can manage, see Assigning Access Privileges, on page 984. Custom roles can
also be created when adding or editing a local user account using the System Administration > Users page.
See Defining a Custom User Role When Adding a User Account, on page 988 for more information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
982
Distributing Administrative Tasks
Account Privileges Page
You should make sure when creating a custom user role so that its responsibilities don’t overlap too much
with the responsibilities of other delegated administrators. If multiple delegated administrators are responsible
for the same content filter, for example, and use the content filter in different mail policies, the changes made
to the filter by one delegated administrator may cause unintended side effects for the mail policies managed
by other delegated administrators.
When you have created the custom user roles, you can assign local users and external authentication groups
to them like any other user role. See Working with User Accounts, on page 977 for more information. Please
note that users assigned to custom roles cannot access the CLI.
Related Topics
• Account Privileges Page, on page 983
• Assigning Access Privileges, on page 984
• Defining a Custom User Role, on page 988
• Defining a Custom User Role When Adding a User Account, on page 988
• Updating Responsibilities for a Custom User Role , on page 989
• Editing a Custom User Role, on page 989
• Duplicating a Custom User Role, on page 989
• Deleting a Custom User Role, on page 990
Account Privileges Page
When a delegated administrator logs into the email gateway, the Account Privileges page displays links to
the security features for which the delegated administrator is responsible and brief descriptions of their access
privileges. A delegated administrator can return to this page by selecting Account Privileges in the Options
menu. Delegated administrators can also access the features that they manage using the menu at the top of
the web page.
The following figure shows an Account Privileges page for a delegated administrator with access to mail
policies, email reporting, message tracking, and quarantines.
Figure 72: Account Privileges Page for a Delegated Administrator
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
983
Distributing Administrative Tasks
Assigning Access Privileges
Assigning Access Privileges
When creating a custom user role, you define the levels of access to the security features for which delegated
administrators are responsible.
The security features available for delegated administrators to manage are:
• Incoming and outgoing mail policies and content filters.
• Data Loss Prevention (DLP) policies.
• Email reporting.
• Message Tracking.
• The Trace debugging tool.
• Spam, policy, virus, and outbreak quarantines.
• Cisco Email Encryption profiles.
• Log Subscription
After defining the access levels for a custom user role, you need to assign the specific mail policies, content
filters, DLP policies, quarantines, or encryption profiles for which the delegated administrators will be
responsible.
For example, you can create two different DLP policy administrator roles that are responsible for different
DLP policies. One role is only responsible for DLP violations related to company confidentiality and acceptable
use, while the other is responsible for DLP violations related to privacy protection. In addition to DLP policies
access, these custom user roles can also be assigned privileges for tracking message data and viewing
quarantines and reports. They can search for DLP violations related to the policies that they are responsible
for in using Message Tracking.
You can view which responsibilities are available to assign to a custom user role by clicking on the links for
the assigned privileges in the Custom User Roles for Delegated Administration table on the User Roles page.
See Updating Responsibilities for a Custom User Role , on page 989.
Related Topics
• Mail Policies and Content Filters, on page 984
• DLP Policies, on page 985
• Email Reporting, on page 986
• Message Tracking, on page 987
• Trace, on page 987
• Quarantines, on page 987
• Encryption Profiles, on page 987
• Log Subscription, on page 988
Mail Policies and Content Filters
The Mail Policies and Content Filters access privileges define a delegated administrator’s level of access to
the incoming and outgoing mail policies and content filters on the email gateway. You can assign specific
mail policies and content filters to a custom user role, allowing only the delegated administrators belonging
to this role, along with operators and administrators, to manage the mail policies and content filters.
All delegated administrators with this access privilege can view the default incoming and outgoing mail
policies but they can only edit these policies if they have full access.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
984
Distributing Administrative Tasks
DLP Policies
All delegated administrators with access privileges can create new content filters to use with their mail policies.
A content filter created by a delegated administrator is available to the other delegated administrators assigned
to the custom user role. Content filters that are not assigned to any custom user role are public and can be
viewed by all delegated administrators with the mail policy access privilege. Content filters created by operators
and administrators are public by default. Delegated administrators can enable or disable any existing content
filters on mail policies assigned to their custom user role, but they cannot modify or delete public content
filters.
If a delegated administrator deletes a content filter used by mail policies other than their own, or if the content
filter is assigned to other custom user roles, AsyncOS does not delete the content filter from the system.
AsyncOS instead unlinks the content filter from the custom user role and removes it from the delegated
administrator’s mail policies. The content filter remains available to other custom user roles and mail policies.
Delegated administrators can use any text resource or dictionary in their content filters, but they cannot access
the Text Resources or Dictionaries pages in the GUI to view or modify them. Delegated administrators also
cannot create new text resources or dictionaries.
For outgoing mail policies, delegated administrators can enable or disable DLP policies but they cannot
customize the DLP settings unless they also have DLP policy privileges.
You can assign one of the following access levels for mail policies and content filters to a custom user role:
• No access: Delegated administrators cannot view or edit mail policies and content filters on the email
gateway.
• View assigned, edit assigned: Delegated administrators can view and edit the mail policies and content
filters assigned to the custom user role and create new content filters. Delegated administrators can edit
a policy’s Anti-Spam, Anti-Virus, and Outbreak Filters settings. They can enable their content filters for
the policy, as well as disable any existing content filter assigned to the policy, regardless of whether they
are responsible for it. Delegated administrators cannot modify a mail policy’s name or its senders,
recipients, or groups. Delegated administrators can modify the order of the content filters for mail policies
assigned to their custom user role.
• View all, edit assigned: Delegated administrators can view all mail policies and content filters on the
email gateway, but they can only edit the ones assigned to the custom user role.
View all, edit all (full access): Delegated administrators have full access to all of the mail policies and content
filters on the email gateway, including the default mail policies, and have the ability to create new mail policies.
Delegated administrators can modify the senders, recipients, and groups of all mail policies. They can also
reorder mail policies.
You can assign individual mail policies and content filters to the custom user role using either the Email
Security Manager or the Custom User Roles for Delegated Administration table on the User Roles page.
See Updating Responsibilities for a Custom User Role , on page 989 for information on using the Custom User
Roles for Delegated Administration table to assign mail policies and content filters.
DLP Policies
The DLP Policies access privileges define a delegated administrator’s level of access to the DLP policies via
the DLP Policy Manager on the email gateway. You can assign DLP policies to specific custom user roles,
allowing delegated administrators, in addition to operators and administrators, to manage these policies.
Delegated administrators with DLP access can also export DLP configuration files from the Data Loss
Prevention Global Settings page.
If a delegated administrator also has mail policy privileges, they can customize the DLP policies. Delegated
administrators can use any custom DLP dictionary for their DLP policies, but they cannot view or modify the
custom DLP dictionaries.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
985
Distributing Administrative Tasks
Email Reporting
You can assign one of the following access levels for DLP policies to a custom user role:
• No access: Delegated administrators cannot view or edit DLP policies on the email gateway.
• View assigned, edit assigned: Delegated administrators can use the DLP Policy Manager to view and
edit the DLP policies assigned to the custom user role. Delegated administrators cannot rename or reorder
DLP policies in the DLP Policy Manager. Delegated administrators can export DLP configurations.
• View all, edit assigned: Delegated administrators can view and edit the DLP policies assigned to the
custom user role. They can export DLP configurations. They can also view all DLP policies that are not
assigned to the custom user role but they cannot edit them. Delegated administrators cannot reorder DLP
policies in the DLP Policy Manager or rename the policy.
• View all, edit all (full access): Delegated administrators have full access to all of the DLP policies on
the email gateway, including the ability to create new ones. Delegated administrators can reorder DLP
policies in the DLP Policy Manager. They cannot change the DLP mode that the email gateway uses.
You can assign individual DLP policies to the custom user role using either the DLP Policy Manager or the
Custom User Roles for Delegated Administration table on the User Roles page.
See Data Loss Prevention, on page 509 for more information on DLP policies and the DLP Policy Manager.
See Updating Responsibilities for a Custom User Role , on page 989 for information on using the Custom User
Roles for Delegated Administration list to assign DLP policies.
Email Reporting
The Email Reporting access privileges define which reports and Email Security Monitor pages a delegated
administrator can view, depending on the custom user role’s access to mail policies, content filters, and DLP
policies. These reports are not filtered for assigned policies; delegated administrators can view reports for
mail and DLP policies that for which they are not responsible.
You can assign one of the following access levels for email reporting to a custom user role:
• No access: Delegated administrators cannot view reports on the email gateway.
• View relevant reports: Delegated administrators can view reports on the Email Security Monitor pages
related to their Mail Policies and Content Filters and DLP Policies access privileges. Delegated
administrators with Mail Policies and Content Filters access privileges can view the following Email
Security Monitor pages:
• Overview
• Incoming Mail
• Outgoing Destinations
• Outgoing Senders
• Internal Users
• Content Filters
• Virus Outbreaks
• Virus Types
• Archived Reports
Delegated administrators with DLP Policies access privileges can view the following Email Security
Monitor pages:
• Overview
• DLP Incidents
• Archived Reports
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
986
Distributing Administrative Tasks
Message Tracking
• View all reports: Delegated administrators can view all reports and Email Security Monitor pages on
the email gateway.
See the Using Email Security Monitor, on page 833 chapter for more information on email reporting and the
Email Security Monitor.
Message Tracking
The Message Tracking access privileges define whether delegated administrators assigned to the custom user
role have access to Message Tracking, including message content that may violate your organization’s DLP
policies if the DLP Tracking Policies option has been enabled on the System Administration > Users page
and the custom user role also has DLP policies access privileges.
Delegated administrators can only search for the DLP violations for the DLP policies assigned to them.
See Tracking Messages, on page 915 for more information on Message Tracking.
See Controlling Access to Sensitive Information in Message Tracking, on page 981 for information for allowing
delegated administrators access to viewing matched DLP content in Message Tracking.
Trace
The Trace access privileges define whether delegated administrators assigned to the custom user role can use
Trace to debug the flow of messages through the system. Delegated administrators with access can run Trace
and view all of the generated output. Trace results are not filtered based on the delegated administrator’s mail
or DLP policy privileges.
See Debugging Mail Flow Using Test Messages: Trace, on page 1249 for more information on using Trace.
Quarantines
The Quarantines access privileges define whether delegated administrators can manage assigned quarantines.
Delegated administrators can view and take actions on any message in an assigned quarantine, such as releasing
or deleting messages, but cannot change the quarantine’s configuration (e.g. the size, retention period, etc.),
or create or delete quarantines.
You can assign any of the quarantines to the custom user role using either the Monitor > Quarantines page or
the Custom User Roles for Delegated Administration table on the User Roles page.
See About Distributing Message Processing Tasks to Other Users , on page 936 and Configuring Administrative
User Access to the Spam Quarantine , on page 951 for more information on assigning Quarantine management
tasks to administrative users.
See Updating Responsibilities for a Custom User Role , on page 989 for information on using the Custom User
Roles for Delegated Administration list to assign quarantines.
Encryption Profiles
The Encryption Profiles access privileges define whether delegated administrators can use encryption profiles
assigned to their custom user role when editing content filters or DLP policies. Encryption profiles can only
be assigned to custom user roles with mail or DLP policy access privileges. Encryption profiles that are not
assigned to a custom role are available for use by all delegated administrators with mail or DLP policy
privileges. Delegated administrators cannot view or modify any encryption profiles.
You can assign encryption profiles when creating or editing an encryption profile using the Security Services
> IronPort Email Encryption page.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
987
Distributing Administrative Tasks
Log Subscription
Log Subscription
The Log Subscription access privileges define whether delegated administrators assigned to the custom user
role can access log subscriptions or Logging APIs to view or download log files.
Defining a Custom User Role
User the User Roles page in the GUI (or the userconfig -> role command in the CLI) to define a new user role
and assign its access privileges. The User Roles page displays all existing custom user roles on the email
gateway and the access privileges for each role.
Procedure
Step 1 Choose System Administration > User Roles.
Step 2 Click Add User Role.
Step 3 Enter a name for the user role.
Step 4 Enter a description of the user role and its privileges.
Step 5 Select the user role’s access privileges. (See Assigning Access Privileges, on page 984 for more information
on each type of access privilege.)
Step 6 Submit and commit your changes.
Defining a Custom User Role When Adding a User Account
You can create a new custom user role when adding or editing a local user account on the email gateway.
See Managing Users, on page 979 for more information on adding a user account.
Procedure
Step 1 Go to the System Administration > Users page.
Step 2 Click Add User.
Step 3 When creating the user account, select Custom Roles.
Step 4 Select Add Role.
Step 5 Enter the name for the new role.
Step 6 Submit the new user account.
AsyncOS displays a notification that the new user account and custom user role have been added.
Step 7 Go to the System Administration > User Roles page.
Step 8 Click on the name of the custom user role in the Custom User Roles for Delegated Administration table.
Step 9 Enter a description of the user role and its privileges.
Step 10 Select the user role’s access privileges. (See Assigning Access Privileges, on page 984 for more information
on each type of access privilege.)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
988
Distributing Administrative Tasks
Updating Responsibilities for a Custom User Role
Step 11 Submit and commit your changes.
Updating Responsibilities for a Custom User Role
Procedure
Step 1 Go to the System Administration > User Roles page.
Step 2 Click the name of the access privilege for the custom user role you want to update.
AsyncOS displays a list of all the mail policies, content filters, DLP policies, or quarantines available on the
email gateway, along with the names of any other assigned custom user roles.
Step 3 Select the mail policies, content filters, DLP policies, or quarantines for which you want the delegated
administrators assigned to be responsible.
Step 4 Submit and commit your changes.
Editing a Custom User Role
Procedure
Step 1 Go to the System Administration > User Roles page.
Step 2 Click the user role’s name in the Custom User Roles for Delegated Administration listing.
Step 3 Make changes to the user role.
Step 4 Submit and commit your changes.
Duplicating a Custom User Role
You may want to create multiple custom user roles with similar access privileges but assign different
responsibilities to different sets of users. For example, if the email gateway handles messages for multiple
domains, you may want to create custom user roles with similar access rights but for different mail policies
based on the domain. This allows delegated administrators to manage mail policies for their domains without
interfering with the responsibilities of other delegated administrators.
Procedure
Step 1 Go to the System Administration > User Roles page.
Step 2 Click the duplicate icon corresponding to the user role you want to duplicate in the Custom User Roles for
Delegated Administration listing.
Step 3 Change the name of the custom user role.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
989
Distributing Administrative Tasks
Deleting a Custom User Role
Step 4 Make any access privilege changes required for the new custom user role.
Step 5 Submit and commit your changes.
Deleting a Custom User Role
When a custom role is deleted, users become unassigned and do not have access to the email gateway. If you
delete a custom user role that is assigned to one or more users, you do not receive a warning message. You
should reassign any users that were assigned to the custom user role that you deleted.
Procedure
Step 1 Go to the System Administration > User Roles page.
Step 2 Click the trash can icon corresponding to the user role you want to delete in the Custom User Roles for
Delegated Administration list.
Step 3 Confirm the deletion by clicking Delete in the warning dialog that appears.
Step 4 Commit your changes.
Passphrases
• Changing Your Passphrase, on page 990
• Locking and Unlocking a User Account, on page 991
• Configuring Restrictive User Account and Passphrase Settings, on page 991
• External Authentication, on page 992
• Two-Factor Authentication, on page 995
Changing Your Passphrase
Administrative users can change their own passphrases via the Options > Change Passphrase link at the top
of the GUI.
As soon as you submit a new passphrase, you are logged out and taken to the log in screen.
In the CLI, use the passphrase or passwd command to change your passphrase. If you forget the passphrase
for the admin user account, contact your customer support provider to reset the passphrase.
Note In addition to creating a login passphrase manually, you can also create a system-generated passphrase to log
in to your email gateway.
The passphrase command requires you to enter the old passphrase for security.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
990
Distributing Administrative Tasks
Locking and Unlocking a User Account
Note Changes to the passphrase take effect immediately and do not require you commit the change.
Locking and Unlocking a User Account
Locking a user account prevents a local user from logging into the email gateway. A user account can be
locked in one of the following ways:
• AsyncOS locks a user account if the user exceeded the maximum number of failed login attempts defined
in the Local User Account & Passphrase Settings section.
• Administrators can manually lock user accounts for security purposes using the System Administration
> Users page.
AsyncOS displays the reason why the user account was locked when you view the user account on the Edit
User page.
To unlock a user account, open the user account by clicking on the user name in the Users listing and click
Unlock Account.
To manually lock a local user account, open the user account by clicking on the user name in the Users listing
and click Lock Account. AsyncOS displays a message saying that the user will be unable to log into the email
gateway and asks if you want to continue.
You can also configure all local user accounts to lock after users fail to login successfully after a configured
number of attempts. For more information, see Configuring Restrictive User Account and Passphrase Settings,
on page 991.
Note If you lock the admin account, you can only unlock it by logging in as the admin through a serial
communications connection to the serial console port. The admin user can always access the email gateway
using the serial console port, even when the admin account is locked. See Connecting to the Email Gateway,
on page 33 for more information on accessing the email gateway using the serial console port.
Configuring Restrictive User Account and Passphrase Settings
You can define user account and passphrase restrictions to enforce organizational passphrase policies. The
user account and passphrase restrictions apply to local users defined on the email gateway. You can configure
the following settings:
• User account locking. You can define how many failed login attempts cause the user to be locked out
of the account.
• Passphrase lifetime rules. You can define how long a passphrase can exist before the user is required
to change the passphrase after logging in.
• Passphrase rules. You can define what kinds of passphrases users can choose, such as which characters
are optional or mandatory.
You define user account and passphrase restrictions on the System Administration > Users page in the Local
User Account & Passphrase Settings section.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
991
Distributing Administrative Tasks
External Authentication
External Authentication
If you store user information in an LDAP or RADIUS directory on your network, you can configure your
email gateway to use the external directory to authenticate users who log in to the email gateway. To set up
the email gateway to use an external directory for authentication, use the System Administration > Users page
in the GUI or the userconfig command and the external subcommand in the CLI.
When external authentication is enabled and a user logs into the email gateway, the email gateway first
determines if the user is the system defined “admin” account. If not, then the email gateway checks the first
configured external server to determine if the user is defined there. If the email gateway cannot connect to
the first external server, the email gateway checks the next external server in the list.
For LDAP servers, if the user fails authentication on any external server, the email gateway tries to authenticate
the user as a local user defined on the email gateway. If the user does not exist on any external server or on
the email gateway, or if the user enters the wrong passphrase, access to the email gateway is denied.
If an external RADIUS server cannot be contacted, the next server in the list is tried. If all servers cannot be
contacted, the email gateway tries to authenticate the user as a local user defined on the email gateway.
However, if an external RADIUS server rejects a user for any reason, such as an incorrect passphrase or the
user being absent, access to the email gateway is denied.
Related Topics
• Enabling LDAP Authentication, on page 992
• Enabling RADIUS Authentication, on page 993
• Enable SAML Authentication, on page 995
Enabling LDAP Authentication
In addition to using an LDAP directory to authenticate users, you can assign LDAP groups to Cisco user roles.
For example, you can assign users in the IT group to the Administrator user role, and you can assign users in
the Support group to the Help Desk User role. If a user belongs to multiple LDAP groups with different user
roles, AsyncOS grants the user the permissions for the most restrictive role. For example, if a user belongs
to a group with Operator permissions and a group with Help Desk User permissions, AsyncOS grants the user
the permissions for the Help Desk User role.
Note If an external user changes the user role for their LDAP group, the user should log out of the email gateway
and then log back in. The user will have the permissions of their new role.
Before You Begin
Define an LDAP server profile and an external authentication query for the LDAP server. For more information,
see LDAP Queries, on page 775
Procedure
Step 1 Choose System Administration > Users.
Step 2 Scroll down to the External Authentication section.
Step 3 Click Enable.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
992
Distributing Administrative Tasks
Enabling RADIUS Authentication
Step 4 Select the Enable External Authentication check box.
Step 5 Select LDAP for the authentication type.
Step 6 Enter the amount of time to store external authentication credentials in the web user interface.
Step 7 Select the LDAP external authentication query that authenticates users.
Step 8 Enter the number of seconds that the email gateway waits for a response from the server before timing out.
Step 9 Enter the name of a group from the LDAP directory that you want the email gateway to authenticate, and
select the role for the users in the group.
Step 10 Optionally, click Add Row to add another directory group. Repeat steps 9 and 10 for each directory group
that the email gateway authenticates.
Step 11 Submit and commit your changes.
Enabling RADIUS Authentication
You can also use a RADIUS directory to authenticate users and assign groups of users to Cisco roles. The
RADIUS server should support the CLASS attribute, which AsyncOS uses to assign users in the RADIUS
directory to Cisco user roles. AsyncOS supports two authentication protocols for communicating with the
RADIUS server: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol
(CHAP).
To assign RADIUS users to Cisco user roles, first set the CLASS attribute on the RADIUS server with a string
value of <radius-group> , which will be mapped to Cisco user roles. The CLASS attribute may contain letters,
numbers, and a dash, but cannot start with a dash. AsyncOS does not support multiple values in the CLASS
attribute. RADIUS users belonging to a group without a CLASS attribute or an unmapped CLASS attribute
cannot log into the email gateway.
If the email gateway cannot communicate with the RADIUS server, the user can log in with a local user
account on the email gateway.
Note If an external user changes the user role for their RADIUS group, the user should log out of the appliance and
then log back in. The user will have the permissions of their new role.
Procedure
Step 1 On the System Administration > Users page, click Enable.
Step 2 Check the Enable External Authentication option if it is not enabled already.
Step 3 Enter the hostname for the RADIUS server.
Step 4 Enter the port number for the RADIUS server. The default port number is 1812.
Step 5 Enter the Shared Secret password for the RADIUS server.
Step 6 Enter the number of seconds for the email gateway to wait for a response from the server before timing out.
Step 7 (Optional) Click Add Row to add another RADIUS server. Repeat steps 3 – 6 for each RADIUS server.
Note You can add up to ten RADIUS servers.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
993
Distributing Administrative Tasks
Enabling RADIUS Authentication
Step 8 Enter the number of seconds AsyncOS stores the external authentication credentials before contacting the
RADIUS server again to re-authenticate in the “External Authentication Cache Timeout” field. Default is
zero (0).
Note If the RADIUS server uses one-time passwords, for example passwords created from a token, enter
zero (0). When the value is set to zero, AsyncOS does not contact the RADIUS server again to
authenticate during the current session.
Step 9 Configure Group Mapping:
Setting Description
Map externally authenticated users to AsyncOS assigns RADIUS users to email gateway roles based on
multiple local roles. the RADIUS CLASS attribute. CLASS attribute requirements:
• 3 character minimum
• 253 character maximum
• no colons, commas, or newline characters
• one or more mapped CLASS attributes for each RADIUS user
(With this setting, AsyncOS denies access to RADIUS users
without a mapped CLASS attribute.)
For RADIUS users with multiple CLASS attributes, AsyncOS
assigns the most restrictive role. For example, if a RADIUS user
has two CLASS attributes, which are mapped to the Operator and
Read-Only Operator roles, AsyncOS assigns the RADIUS user to
the Read-Only Operator role, which is more restrictive than the
Operator role.
These are the email gateway roles ordered from least restrictive to
most restrictive:
• admin
• Administrator
• Technician
• Operator cloudadmin
• Read-only Operator
• Help Desk User
• Guest
Map all externally authenticated users AsyncOS assigns RADIUS users to the Administrator role.
to the Administrator role.
Step 10 Choose whether to map all externally authenticated users to the Administrator role or to different email gateway
user role types.
Step 11 If you map users to different role types, enter the group name as defined in the RADIUS CLASS attribute in
the Group Name or Directory field, and choose an email gateway role type from the Role field. You can add
more role mappings by clicking Add Row.
For more information on user role types, see Working with User Accounts, on page 977.
Step 12 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
994
Distributing Administrative Tasks
Enable SAML Authentication
Enable SAML Authentication
You can enable Single Sign On using SAML to authenticate users and assign groups of users to Cisco rules.
Before you begin
Make sure that you have configured the SAML profiles with Service Provider and Identity Provider settings.
See How to Configure SSO on your Email Gateway, on page 1073.
Procedure
Step 1 Navigate to System Administration > Users.
Step 2 Scroll down to the External Authentication section.
Step 3 Click Enable.
Step 4 Select the Enable External Authentication check box.
Step 5 Select SAML as the authentication type from the drop-down list.
Step 6 (Optional) In the External Authentication Attribute Name Map field, enter the attribute name to search
from the Group Mapping.
The Attribute Name depends on the attributes that you configure for the Identity Provider to relay the SAML
response. The email gateway will search for matching entries of the Attribute Name from SAML response
against the attributes that you configure in the Group Mapping field. This is optional and if you do not
configure, the email gateway will search for matching entries of all attributes present in SAML response
against configured Group Mapping field.
Step 7 In the Group Mapping field, enter the group name attribute as defined in the SAML directory based on the
predefined or custom user role. You can click Add Row to add multiple role mappings.
The Group Mapping must contain a group attribute. You can add 'Unspecified Groups' attribute to authenticate
SAML assertions or response.
For more information on types of user roles, see Working with User Accounts, on page 977.
Note The Group Mapping attributes are case-sensitive and must match exactly in order to return the
proper results.
Step 8 Submit and commit your changes.
What to do next
After you enable SAML external authentication, you can use the Use Single Sign On link on the login page
of the email gateway and enter the username to log in to the email gateway.
Two-Factor Authentication
You can use a RADIUS directory to configure two-factor authentication for specific user roles. The email
gateway supports the following authentication protocols for communicating with the RADIUS server:
• Password Authentication Protocol (PAP)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
995
Distributing Administrative Tasks
Enabling Two-Factor Authentication
• Challenge Handshake Authentication Protocol (CHAP)
You can enable two-factor authentication for the following user roles:
• predefined
• custom
The feature has been tested with:
• RSA Authentication Manager v8.2
• FreeRADIUS v1.1.7 and above
• ISE v1.4 and above
Related Topics
• Enabling Two-Factor Authentication, on page 996
• Disabling Two-Factor Authentication, on page 996
Enabling Two-Factor Authentication
Before You Begin
Make sure that you get the required RADIUS server details for two-factor authentication from your IT
administrator.
Procedure
Step 1 On the System Administration > Users page, click Enable under Two-Factor Authentication.
Step 2 Enter the hostname or IP address of the RADIUS server.
Step 3 Enter the port number of the RADIUS server.
Step 4 Enter the Shared Secret password of the RADIUS server.
Step 5 Enter the number of seconds to wait for a response from the server before timing out.
Step 6 Select the appropriate authentication protocol.
Step 7 (Optional) Click Add Row to add another RADIUS server. Repeat steps 2 to 6 for each RADIUS server.
Note You can add up to ten RADIUS servers.
Step 8 Select the required user roles for which you want to enable two-factor authentication.
Step 9 Submit and commit your changes.
When two-factor authentication is enabled, the user is prompted to enter a passcode after entering the username
and passphrase, to login to the email gateway.
Disabling Two-Factor Authentication
Before You Begin
Make sure you have enabled two-factor authentication on your email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
996
Distributing Administrative Tasks
Configuring Access to the Email Gateway
Procedure
Step 1 On the System Administration > Users page, click Edit Global Settings under Two-Factor Authentication
Step 2 Deselect Enable Two-Factor Authentication.
Step 3 Submit and commit your changes.
Configuring Access to the Email Gateway
AsyncOS provides administrators controls to manage users’ access to the email gateway, including a timeout
for Web UI session and an access list that specifies the IP addresses from which users and your organization’s
proxy servers can access the email gateway.
Related Topics
• Configuring IP-Based Network Access, on page 997
• Configuring Session Timeouts, on page 999
Configuring IP-Based Network Access
You can control from which IP addresses users access the email gateway by creating access lists for users
who connect directly to the appliance and users who connect through a reverse proxy, if your organization
uses reverse proxies for remote users.
Related Topics
• Direct Connections, on page 997
• Connecting Through a Proxy, on page 997
• Important Precautions When Restricting Network Access , on page 998
• Creating the Access List , on page 998
Direct Connections
You can specify the IP addresses, subnets, or CIDR addresses for machines that can connect to the email
gateway. Users can access the email gateway from any machine with IP address from the access list. Users
attempting to connect to the email gateway from an address not included in the list are denied access.
Connecting Through a Proxy
If your organization’s network uses reverse proxy servers between remote users’ machines and the email
gateway, AsyncOS allows you create an access list with the IP addresses of the proxies that can connect to
the email gateway.
Even when using a reverse proxy, AsyncOS still validates the IP address of the remote user’s machine against
a list of IP addresses allowed for user connections. To send the remote user’s IP address to the email gateway,
the proxy needs to include the x-forwarded-for HTTP header in its connection request to the email gateway.
The x-forwarded-for header is a non-RFC standard HTTP header with the following format:
x-forwarded-for: client-ip, proxy1, proxy2,... CRLF .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
997
Distributing Administrative Tasks
Important Precautions When Restricting Network Access
The value for this header is a comma-separated list of IP addresses with the left-most address being the address
of the remote user’s machine, followed by the addresses of each successive proxy that forwarded the connection
request. (The header name is configurable.) The email gateway matches the remote user’s IP address from
the header and the connecting proxy’s IP address against the allowed user and proxy IP addresses in the access
list.
Note AsyncOS supports only IPv4 addresses in the x-forwarded-for header.
Important Precautions When Restricting Network Access
Caution! You may lose access to the email gateway after submitting and committing network access changes
if one of the following conditions is true:
• If you select Only Allow Specific Connections and do not include the IP address of your current machine
(PC, email gateway in a clustered environment, or Cisco Secure Manager Email and Web Gateway, etc.)
in the list.
• If you select Only Allow Specific Connections Through Proxy and the IP address of the proxy currently
connected to the email gateway is not in the proxy list and the value of the Origin IP header is not in the
list of allowed IP addresses.
• If you select Only Allow Specific Connections Directly or Through Proxy and
• the value of the Origin IP header is not in the list of allowed IP addresses
OR
• the value of the Origin IP header is not in the list of allowed IP Addresses and the IP address of the
proxy connected to the email gateway is not in the list of allowed proxies.
Creating the Access List
You can create the network access list either via the GUI or the adminaccessconfig > ipaccess
CLI command.
Before You Begin
Ensure that you will not lock yourself out of the email gateway after changing network access settings. See
Important Precautions When Restricting Network Access , on page 998.
Procedure
Step 1 Select System Administration > Network Access.
Step 2 Click Edit Settings.
Step 3 Select the mode of control for the access list:
Option Description
Allow All This mode allows all connections to the email gateway.
This is the default mode of operation.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
998
Distributing Administrative Tasks
Configuring Session Timeouts
Option Description
Only Allow Specific Connections This mode allows a user to connection to the email gateway if
the user’s IP address matches the IP addresses, IP ranges, or CIDR
ranges included in the access list.
Only Allow Specific Connections This mode allows a user to connect to the email gateway through
Through Proxy a reverse proxy if the following conditions are met:
• The connecting proxy’s IP address is included in the access
list’s IP Address of Proxy Server field.
• The proxy includes the x-forwarded-header HTTP
header in its connection request.
• The value of x-forwarded-header is not empty.
• The remote user’s IP address is included in
x-forwarded-header and it matches the IP addresses, IP
ranges, or CIDR ranges defined for users in the access list.
Only Allow Specific Connections This mode allows users to connect through a reverse proxy or
Directly or Through Proxy directly to the email gateway if their IP address matches the IP
addresses, IP ranges, or CIDR ranges included in the access list.
The conditions for connecting through a proxy are the same as
in the Only Allow Specific Connections Through Proxy mode.
Step 4 Enter the IP addresses from which users will be allowed to connect to the email gateway.
You can enter an IP address, IP address range or CIDR range. Use commas to separate multiple entries.
Step 5 If connecting through a proxy is allowed, enter the following information:
a. The IP addresses of the proxies allowed to connect to the email gateway. Use commas to separate multiple
entries.
b. The name of the origin IP header that the proxy sends to the email gateway, which contains the IP addresses
of the remote user’s machine and the proxy servers that forwarded the request. By default, the name of
the header is x-forwarded-for .
Step 6 Ensure that you have not configured a change that will lock you out of the email gateway after you submit
and commit your changes.
Step 7 Submit and commit your changes.
Configuring Session Timeouts
• Configuring the Web UI Session Timeout, on page 999
• Configuring the CLI Session Timeout, on page 1000
Configuring the Web UI Session Timeout
You can specify how long a user can be logged into the email gateway's Web UI before AsyncOS logs the
user out due to inactivity. This Web UI session timeout applies to:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
999
Distributing Administrative Tasks
Configuring the CLI Session Timeout
• All users, including administrator
• HTTP and HTTPS sessions
• Cisco Spam Quarantine
Once AsyncOS logs a user out, the email gateway redirects the user’s web browser to login page.
Procedure
Step 1 Select System Administration > Network Access.
Step 2 Click Edit Settings.
Step 3 In the Web UI Inactivity Timeout field, enter the number of minutes users can be inactive before being
logged out. You can define a timeout period between 5 and 1440 minutes.
Step 4 Submit and commit your changes.
What to do next
You can also use the adminaccessconfig command in CLI to configure Web UI session timeout. See CLI
Reference Guide for AsyncOS for Cisco Secure Email Gateway .
Configuring the CLI Session Timeout
You can specify how long a user can be logged into the email gateway's CLI before AsyncOS logs the user
out due to inactivity. The CLI session timeout applies:
• To all users, including administrator
• Only to the connections using Secure Shell (SSH), SCP, and direct serial connection
Note Any uncommitted configuration changes at the time of CLI session timeout will be lost. Make sure that you
commit the configuration changes as soon as they are made.
Procedure
Step 1 Select System Administration > Network Access.
Step 2 Click Edit Settings.
Step 3 In the CLI Inactivity Timeout field, enter the number of minutes users can be inactive before being logged
out. You can define a timeout period between 5 and 1440 minutes.
Step 4 Submit and commit your changes.
What to do next
You can also use the adminaccessconfig command in CLI to configure CLI session timeout. See CLI Reference
Guide for AsyncOS for Cisco Secure Email Gateway .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1000
Distributing Administrative Tasks
Displaying Messages to Administrative Users
Displaying Messages to Administrative Users
• Displaying a Message Before Login , on page 1001
• Displaying a Message After Login , on page 1001
Displaying a Message Before Login
You can configure the email gateway to display a message before a user attempts to log into the email gateway
through SSH, FTP, or Web UI. The login banner is customizable text that appears above the login prompt.
You can use the login banner to display internal security information or best practice instructions for the email
gateway. For example, you can create a simple note that saying that unauthorized use of the email gateway
is prohibited or a detailed warning concerning the organization’s right to review changes made by the user to
the email gateway.
Use the adminaccessconfig > banner command in the CLI to create the login banner. The maximum length
of the login banner is 2000 characters to fit 80x25 consoles. A login banner can be imported from a file in the
/data/pub/configuration directory on the email gateway. After creating the banner, commit your changes.
Displaying a Message After Login
You can configure AsyncOS to display a welcome banner after a user successfully logs into the email gateway
through SSH, FTP, or Web UI. You can use the welcome banner to display internal security information or
best practice instructions for the email gateway.
Use the adminaccessconfig > welcome command in CLI to create the welcome banner. The maximum length
of the welcome banner is 1600 characters.
You can import a welcome banner from a file in the /data/pub/configuration directory on your email gateway.
After creating the banner, commit your changes.
For more information, see CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway .
Managing Secure Shell (SSH) Keys
Use the sshconfig command to:
• Add or delete secure shell (SSH) public User keys to the authorized_keys file of user accounts that have
been configured on the system, including the admin account. This allows authentication to user accounts
using SSH keys rather than passphrase challenge.
• Edit the following SSH server configuration settings:
• Public Key Authentication Algorithms
• Cipher Algorithms
• KEX Algorithms
• MAC Methods
• Minimum Server Key Size.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1001
Distributing Administrative Tasks
Example: Install a New Public Key
Note To configure Host keys, which are used when performing SCP pushes of log files from the email gateway to
other host machines, use logconfig -> hostkeyconfig . For more information, see Logging, on page
1141.
Using hostkeyconfig , you can scan for keys of remote hosts and add them to the email gateway.
Related Topics
• Example: Install a New Public Key, on page 1002
• Example: Edit SSH Server Configuration, on page 1002
Example: Install a New Public Key
In the following example, a new public key is installed for the administrator account:
mail.example.com> sshconfig
Choose the operation you want to perform:
- SSHD - Edit SSH server settings.
- USERKEY - Edit SSH User Key settings
[]> userkey
Currently installed keys for admin:
Choose the operation you want to perform:
- NEW - Add a new key.
- USER - Switch to a different user to edit.
[]> new
Please enter the public SSH key for authorization.
Press enter on a blank line to finish.
[-paste public key for user authentication here-]
Choose the operation you want to perform:
- SSHD - Edit SSH server settings.
- USERKEY - Edit SSH User Key settings
[]>
Example: Edit SSH Server Configuration
The following example shows how to edit the SSH server configuration.
mail.example.com> sshconfig
Choose the operation you want to perform:
- SSHD - Edit SSH server settings.
- USERKEY - Edit SSH User Key settings
[]> sshd
ssh server config settings:
Public Key Authentication Algorithms:
rsa1
ssh-dss
ssh-rsa
Cipher Algorithms:
aes128-ctr
aes192-ctr
aes256-ctr
arcfour256
arcfour128
aes128-cbc
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1002
Distributing Administrative Tasks
Remote SSH Command Execution
3des-cbc
blowfish-cbc
cast128-cbc
aes192-cbc
aes256-cbc
arcfour
[email protected]
MAC Methods:
hmac-md5
hmac-sha1
[email protected]
hmac-ripemd160
[email protected]
hmac-sha1-96
hmac-md5-96
Minimum Server Key Size:
1024
KEX Algorithms:
diffie-hellman-group-exchange-sha256
diffie-hellman-group-exchange-sha1
diffie-hellman-group14-sha1
diffie-hellman-group1-sha1
Choose the operation you want to perform:
- SETUP - Setup SSH server configuration settings
[]> setup
Enter the Public Key Authentication Algorithms do you want to use
[rsa1,ssh-dss,ssh-rsa]> rsa1
Enter the Cipher Algorithms do you want to use
[aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,
cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]]> aes192-ctr
Enter the MAC Methods do you want to use
[hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,
hmac-md5-96]> hmac-sha1
Enter the Minimum Server Key Size do you want to use
[1024]> 2048
Enter the KEX Algorithms do you want to use
[diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,
diffie-hellman-group1-sha1]> diffie-hellman-group-exchange-sha1
ssh server config settings:
Public Key Authentication Algorithms:
rsa1
Cipher Algorithms:
aes192-ctr
MAC Methods:
hmac-sha1
Minimum Server Key Size:
2048
KEX Algorithms:
diffie-hellman-group-exchange-sha1
Choose the operation you want to perform:
- SETUP - Setup SSH server configuration settings
[]>
Remote SSH Command Execution
The CLI allows commands to be run via remote SSH command execution. For example, the following command
can be run from a remote host unchallenged if an SSH public key has been configured for the admin account
on the email gateway:
# ssh [email protected] status
Enter "status detail" for more information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1003
Distributing Administrative Tasks
Monitoring Administrative User Access
Status as of: Mon Jan 20 17:24:15 2003
Last counter reset: Mon Jan 20 17:08:21 2003
System status: online
[rest of command deleted]
Monitoring Administrative User Access
To Do This
View session details of all active users of the email Click Options > Active Sessions at the top right of
gateway the page
In the command-line interface, use the w , whoami
and who commands.
View users who have recently logged into the email In the command-line interface, use the l ast
gateway. command.
The IP address of the remote host, and the login, logout,
and total time are also displayed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1004
CHAPTER 39
System Administration
This chapter contains the following sections:
Note Several of the features or commands described in this section will affect, or be affected by routing precedence.
Please see Appendix B "IP Addresses Interfaces and Routing" for more information.
• Management of the Email Gateway, on page 1006
• Email Gateway Licensing, on page 1008
• Virtual Email Gateway License, on page 1017
• Managing the Configuration File, on page 1017
• Configuration File Page, on page 1022
• Managing Disk Space , on page 1023
• Managing Security Services, on page 1025
• Service Updates , on page 1026
• Setting Up to Obtain Upgrades and Updates , on page 1027
• Upgrading AsyncOS, on page 1034
• Enabling Remote Power Cycling , on page 1038
• Reverting to a Previous Version of AsyncOS, on page 1039
• Configuring the Return Address for Email Gateway Generated Messages, on page 1041
• Setting Thresholds for System Health Parameters, on page 1041
• Checking the Health of Email Gateway, on page 1043
• Alerts, on page 1043
• Changing Network Settings, on page 1066
• Single Sign-On (SSO) Using SAML 2.0, on page 1071
• Configuring OpenID Connect 1.0 on Email Gateway for AsyncOS APIs, on page 1080
• System Time, on page 1083
• Customizing Your View , on page 1085
• General Settings, on page 1086
• Configuring Maximum HTTP Header Size, on page 1087
• Restarting and Viewing Status of Service Engines, on page 1087
• Receiving and Delivering Messages with Internationalised Domain Names (IDNs), on page 1088
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1005
System Administration
Management of the Email Gateway
Management of the Email Gateway
The following tasks allow you to easily manage the common functions within the email gateway.
• Shutting Down or Rebooting the Email Gateway , on page 1006
• Suspending Email Receiving and Delivery , on page 1006
• Resuming Suspended Email Receiving and Delivery , on page 1007
Shutting Down or Rebooting the Email Gateway
After you shut down or reboot, you may restart the email gateway later without losing any messages in the
delivery queue.
You can use the s hutdown or reboot command in the CLI, or use the web interface:
Procedure
Step 1 Select System Administration > Shutdown/Suspend.
Step 2 In the System Operations section, choose Shutdown or Reboot from the Operation drop-down list.
Step 3 Enter a number of seconds to wait to allow open connections to complete before forcing them to close.
The default delay is thirty (30) seconds.
Step 4 Click Commit.
Suspending Email Receiving and Delivery
AsyncOS allows you to suspend receiving and delivering of emails. You can suspend:
• Receiving of emails on a particular listener or multiple listeners.
• Delivery of all emails or emails to a particular domain or multiple domains.
Use the suspend command in the CLI, or use the web interface:
Procedure
Step 1 Select System Administration > Shutdown/Suspend.
Step 2 Suspend receiving of emails on a particular listener or multiple listeners.
In the Mail Operations section, select the functions and/or listeners to suspend. If the email gateway has
multiple listeners, you can suspend email receiving on individual listeners.
Step 3 Suspend the delivery of all emails or emails to a particular domain or multiple domains. Depending on your
requirements, do one of the following:
a. To suspend the delivery of all emails, in Specify Domain(s)/Subdomain(s) field, enter ALL, and press
Enter.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1006
System Administration
Resuming Suspended Email Receiving and Delivery
b. To suspend the delivery of emails to a specific domain or subdomain, in Specify Domain(s)/Subdomain(s)
field, enter the domain or subdomain name or IP address, and press Enter. Use comma-separated text to
add multiple entries.
Step 4 Enter number of seconds to wait to allow open connections to complete before forcing them to close.
If there are no open connections, the system goes offline immediately.
The default delay is 30 seconds.
Step 5 Click Commit.
What to do next
When you are ready to resume suspended services, see Resuming Suspended Email Receiving and Delivery
, on page 1007.
Resuming Suspended Email Receiving and Delivery
Use the Shutdown/Suspend page or the r esume command to resume the suspended receiving and delivery of
emails.
Procedure
Step 1 Select System Administration > Shutdown/Suspend.
Step 2 In the Mail Operations section, select the functions and/or listeners to resume.
If the email gateway has multiple listeners, you can resume email receiving on individual listeners.
Step 3 Resume the delivery of all emails or emails to a particular domain or multiple domains.
In Specify Domain(s)/Subdomain(s) field, click the close icon on the intended entry.
Step 4 Click Commit.
Resetting to Factory Defaults
Caution Do not reset to factory defaults if you are not able to reconnect to the web interface or CLI using the Serial
interface or the default settings on the Management port through the default Admin user account.
When physically transferring the email gateway, you may want to start with factory defaults. Resetting to
factory settings is extremely destructive, and it should only be used when you are transferring the unit or as
a last resort to solving configuration issues. Resetting to factory defaults disconnects you from the web interface
or CLI, disabling services that you used to connect to the email gateway (FTP, SSH, HTTP, HTTPS), and
even removing additional user accounts you had created. You can reset to factory default:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1007
System Administration
Next Steps
• On web interface, click the Reset button in the System Administration > Configuration File page, or
click the Reset Configuration button in the System Administration> System Setup Wizard.
• On CLI, use the resetconfig command.
Note The resetconfig command only works when the email gateway is in the offline state. The email gateway
returns to the online state after resetting to factory settings.
Next Steps
• Run the System Setup wizard. For more information, refer to Using the System Setup Wizard , on page
38
• Turn on mail delivery to resume mail delivery.
Displaying the Version Information for AsyncOS
To determine which version of AsyncOS is currently installed on your email gateway, use the System Overview
page from the Monitor menu in the web interface (see System Status, on page 863), or use the version command
in the CLI.
Email Gateway Licensing
• Feature Keys, on page 1008
• Smart Software Licensing, on page 1010
Feature Keys
• Adding and Managing Feature Keys , on page 1008
• Automating Feature Key Download and Activation , on page 1009
• Expired Feature Keys, on page 1010
Adding and Managing Feature Keys
For physical email gateways, feature keys are specific to the serial number of the email gateway and specific
to the feature being enabled (you cannot re-use a key from one system on another system).
To work with feature keys in the CLI, use the featurekey command.
Procedure
Step 1 Select System Administration > Feature Keys.
Step 2 Perform actions:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1008
System Administration
Automating Feature Key Download and Activation
To Do This
View the status of active feature keys Look at the Feature Keys for <serial number> section.
View feature keys that have been issued for Look at the Pending Activation section.
your email gateway but are not yet activated
If you have enabled automatic download and activation,
feature keys will never appear in this list.
Check for recently-issued feature keys Click the Check for New Keys button in the Pending
Activation section.
This is useful if you have not enabled automatic download
and activation of feature keys, or if you need to download
feature keys before the next automatic check.
Activate an issued feature key Select the key in the Pending Activation list and click
Activate Selected Keys.
Add a new feature key Use the Feature Activation section.
What to do next
Related Topics
• Automating Feature Key Download and Activation , on page 1009
• Configuration File Page, on page 1022
Automating Feature Key Download and Activation
You can set the email gateway to automatically check for, download, and activate feature keys that are issued
for this email gateway.
Procedure
Step 1 Select System Administration > Feature Key Settings.
Step 2 Click Edit Feature Key Settings.
Step 3 To see frequency of checks for new feature keys, click the (?) help button.
Step 4 Specify settings.
Step 5 Submit and commit your changes.
What to do next
Related Topics
• Adding and Managing Feature Keys , on page 1008
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1009
System Administration
Expired Feature Keys
Expired Feature Keys
If a feature key is expiring, the email gateway sends out alerts 90 days, 60 days, 30 days, 15 days, 5 days, one
day prior to the key expiration, and at the time of key expiration. To receive these alerts, make sure that you
have subscribed to the System Alerts. For more information, see Alerts, on page 1043.
If the feature key for the feature you are trying to access (using the web interface) has expired, please contact
your Cisco representative or support organization.
Smart Software Licensing
• Overview, on page 1010
• Enabling Smart Software Licensing, on page 1012
• Registering the Email Gateway with Cisco Smart Software Manager, on page 1012
• Requesting for Licenses, on page 1013
• Deregistering the Email Gateway from Smart Cisco Software Manager , on page 1014
• Reregistering the Email Gateway with Smart Cisco Software Manager , on page 1014
• Changing Transport Settings, on page 1015
• Renewing Authorization and Certificate, on page 1015
• Updating Smart Agent, on page 1016
• Alerts, on page 1015
• Smart Licensing in Cluster Mode, on page 1016
Overview
Smart Software Licensing enables you to manage and monitor email gateway licenses seamlessly. To activate
Smart Software licensing, you must register your email gateway with Cisco Smart Software Manager (CSSM)
which is the centralized database that maintains the licensing details about all the Cisco products that you
purchase and use. With Smart Licensing, you can register with a single token rather than registering them
individually on the website using Product Authorization Keys (PAKs).
Once you register the email gateway, you can track your email gateway licenses and monitor license usage
through the CSSM portal. The Smart Agent installed on the email gateway connects the appliance with CSSM
and passes the license usage information to the CSSM to track the consumption.
See https://www.cisco.com/c/en/us/td/docs/wireless/technology/mesh/8-2/b_Smart_Licensing_Deployment_
Guide.html to know about Cisco Smart Software Manager.
Before you begin
• Make sure that your email gateway has internet connectivity.
• Contact Cisco sales team to create a smart account in Cisco Smart Software Manager portal
(https://software.cisco.com/#module/SmartLicensing) or install a Cisco Smart Software Manager Satellite
on your network.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1010
System Administration
Overview
See https://www.cisco.com/c/en/us/td/docs/wireless/technology/mesh/8-2/b_Smart_Licensing_
Deployment_Guide.html to know more about Cisco Smart Software Manager user account creation or
installing a Cisco Smart Software Manager Satellite.
For users who do not want to directly send the license usage information to the internet, the Smart
Software Manager Satellite can be installed on the premises, and it provides a subset of CSSM
functionality. Once you download and deploy the satellite application, you can manage licenses locally
and securely without sending data to CSSM using the internet. The CSSM Satellite periodically transmits
the information to the cloud.
Note If you want to use Smart Software Manager Satellite, use Smart Software Manager
Satellite Enhanced Edition 6.1.0.
• The existing users of classical licenses (traditional) should migrate their classical licenses to smart licenses.
See https://video.cisco.com/detail/video/5841741892001/
convert-classic-licenses-to-smart-licenses?autoStart=true&q=classic.
• The system clock of the email gateway must be in sync with that of the CSSM. Any deviation in the
system clock of the email gateway with that of the CSSM, will result in failure of smart licensing
operations.
Note If you have internet connectivity and want to connect to the CSSM through a proxy, you must use the same
proxy that is configured for the email gateway using Security Services -> Service updates
Note For virtual users, every time you receive a new PAK file (new or renewal), generate the license file and load
the file on the email gateway. After loading the file, you must convert the PAK to Smart Licensing. In Smart
Licensing mode, the feature keys section in the license file will be ignored while loading the file and only the
certificate information will be used.
Note If you already have a Cisco SecureX account, make sure you first register your email gateway with Cisco
SecureX before you enable the Smart Licensing mode on your email gateway.
You must perform the following procedures to activate Smart Software Licensing for your email gateway:
Do This More Informaton
Step 1 Enable Smart Software Licensing Enabling Smart Software
Licensing, on page 1012
Step 2 Register the email gateway with Registering the Email Gateway
Cisco Smart Software Manager with Cisco Smart Software
Manager, on page 1012
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1011
System Administration
Enabling Smart Software Licensing
Do This More Informaton
Step 3 Request for licenses (feature keys) Requesting for Licenses, on page
1013
Enabling Smart Software Licensing
Procedure
Step 1 Choose System Administration > Smart Software Licensing.
Step 2 Click Enable Smart Software Licensing.
To know about Smart Software Licensing, click on the Learn More about Smart Software Licensing link.
Step 3 Click OK after reading the information about Smart Software Licensing.
Step 4 Commit your changes.
What to do next
After you enable Smart Software Licensing, all the features in the Classic Licensing mode will be automatically
available in the Smart Licensing mode. If you are an existing user in Classic Licensing mode, you have 90-days
evaluation period to use the Smart Software Licensing feature without registering your email gateway with
the CSSM.
You will get notifications on regular intervals (90th, 60th, 30th, 15th, 5th, and last day) prior to the expiry
and also upon expiry of the evaluation period. You can register your email gateway with the CSSM during
or after the evaluation period.
Note New virtual email gateway users with no active licenses in Classic Licensing mode will not have the evaluation
period even if they enable the Smart Software Licensing feature. Only the existing virtual email gateway users
with active licenses in Classic Licensing mode will have evaluation period. If new virtual email gateway users
want to evaluate the smart licensing feature, contact Cisco Sales team to add the evaluation license to the
smart account. The evaluation licenses are used for evaluation purpose after registration.
Note After you enable the Smart Licensing feature on your email gateway, you will not be able to roll back from
Smart Licensing to Classic Licensing mode.
Registering the Email Gateway with Cisco Smart Software Manager
You must enable the Smart Software Licensing feature under System Administration menu in order to register
your email gateway with the Cisco Smart Software Manager.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1012
System Administration
Requesting for Licenses
Procedure
Step 1 Choose System Administration > Smart Software Licensing.
Step 2 Click Edit, if you want to change the Transport Settings. The available options are:
• Direct: Connects the email gateway directly to the Cisco Smart Software Manager through HTTPs. This
option is selected by default.
• Transport Gateway: Connects the email gateway to the Cisco Smart Software Manager through a Transport
Gateway or Smart Software Manager Satellite. When you choose this option, you must enter the URL
of the Transport Gateway or the Smart Software Manager Satellite and click OK. This option supports
HTTP and HTTPS. In FIPS mode, Transport Gateway supports only HTTPS. See
https://www.cisco.com/c/en/us/td/docs/wireless/technology/mesh/8-2/b_Smart_Licensing_
Deployment_Guide.html to know about Transport Gateway.
Access the Cisco Smart Software Manager portal
(https://software.cisco.com/#module/SmartLicensing using your login credentials. Navigate to the Virtual
Account page of the portal and access the General tab to generate a new token. Copy the Product Instance
Registration Token for your email gateway.
See https://www.cisco.com/c/en/us/td/docs/wireless/technology/mesh/8-2/b_Smart_Licensing_
Deployment_Guide.html to know about Product Instance Registration Token creation.
Step 3 Switch back to your email gateway and paste the Product Instance Registration Token.
Step 4 Click Register.
Step 5 On the Smart Software Licensing page, you can check the Reregister this product instance if it is already
registered check box to reregister your email gateway. See Reregistering the Email Gateway with Smart Cisco
Software Manager , on page 1014.
What to do next
The product registration process takes a few minutes and you can view the registration status on the Smart
Software Licensing page.
Note After you have enabled smart software licensing and registered your email gateway with the Cisco Smart
Software Manager, the Cisco Cloud Services portal is automatically enabled and registered on your email
gateway.
Requesting for Licenses
Once you complete the registration process successfully, you must request for licenses for the email gateway's
features as required.
Procedure
Step 1 Choose System Administration > Licenses.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1013
System Administration
Deregistering the Email Gateway from Smart Cisco Software Manager
Step 2 Click Edit Settings.
Step 3 Check the checkboxes under the License Request/Release column corresponding to the licenses you want to
request for.
Step 4 Click Submit.
Note By default the licenses for Mail Handling and Cisco Secure Email Gateway Bounce Verification
are available. You cannot activate, deactivate, or release these licenses.
There is no evaluation period or out of compliance for Mail Handling and Cisco Secure Email
Gateway Bounce Verification licenses. This is not applicable for virtual email gateways.
What to do next
When the licenses are overused or expired, they will go into out of compliance (OOC) mode and 30-days
grace period is provided to each license. You will get notifications on regular intervals (30th, 15th, 5th, and
last day) prior to the expiry and also upon the expiry of the OOC grace period.
After the expiry of the OOC grace period, you cannot use the licenses and the features will be unavailable.
To access the features again, you must update the licenses on the CSSM portal and renew the authorization.
Deregistering the Email Gateway from Smart Cisco Software Manager
Procedure
Step 1 Choose System Administration > Smart Software Licensing.
Step 2 From the Action drop-down list, choose Deregister and click Go.
Step 3 Click Submit.
Reregistering the Email Gateway with Smart Cisco Software Manager
Procedure
Step 1 Choose System Administration > Smart Software Licensing.
Step 2 From the Action drop-down list, choose Reregister and click Go.
What to do next
See Registering the Email Gateway with Cisco Smart Software Manager, on page 1012 to know about registration
process.
You can reregister the email gateway after you reset the email gateway configurations during unavoidable
scenarios.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1014
System Administration
Changing Transport Settings
Changing Transport Settings
You can change the transport settings only before registering the email gateway with CSSM.
Note You can change the transport settings only when the smart licensing feature is enabled.If you have already
registered your email gateway, you must deregister the email gateway to change the transport settings. After
changing the transport settings, you must register the email gateway again.
See Registering the Email Gateway with Cisco Smart Software Manager to know how to change the transport
settings.
Renewing Authorization and Certificate
After you register your email gateway with the Smart Cisco Software Manager, you can renew the certificate.
Note You can renew authorization only after the successful registration of the email gateway.
Procedure
Step 1 Choose System Administration > Smart Software Licensing.
Step 2 From the Action drop-down list, choose the appropriate option:
• Renew Authorization Now
• Renew Certificates Now
Step 3 Click Go.
Alerts
You will receive notifications on the following scenarios:
• Smart Software Licensing successfully enabled
• Smart Software Licensing enabling failed
• Beginning of the evaluation period
• Expiry of evaluation period (on regular intervals during evaluation period and upon expiry)
• Successfully registered
• Registration failed
• Successfully authorized
• Authorization failed
• Successfully deregistered
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1015
System Administration
Updating Smart Agent
• Deregistration failed
• Successfully renewed Id certificate
• Renewal of Id certificate failed
• Expiry of authorization
• Expiry of Id certificate
• Expiry of out of compliance grace period (on regular intervals during out of compliance grace period
and upon expiry)
• First instance of the expiry of a feature
Updating Smart Agent
To update the Smart Agent version installed on your email gateway, perform the following steps:
Procedure
Step 1 Choose System Administration > Smart Software Licensing.
Step 2 In the Smart Agent Update Status section, click Update Now and follow the process.
Note If you try to save any configuration changes using the CLI command saveconfig or through the
web interface using System Administration > Configuration Summary, then Smart Licensing
related configuration will not be saved.
Smart Licensing in Cluster Mode
In a clustered configuration, you can enable smart software licensing and register all the machines
simultaneously with the Cisco Smart Software Manager.
Procedure:
1. Switch from the cluster mode to the machine mode in the logged-in email gateway.
2. Go to System Administration > Smart Software Licensing page.
3. Click Enable.
4. Check the Enable Smart Software Licensing on all machines in the cluster check box.
5. Click OK.
6. Check the Register Smart Software Licensing across machines in cluster check box.
7. Click Register.
Note You can use the license_smart command in the CLI to enable smart software licensing and register all the
machines simultaneously with the Cisco Smart Software Manager.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1016
System Administration
Virtual Email Gateway License
Note In a clustered configuration, you can also enable smart software licensing and register all the machines
individually with the Cisco Smart Software Manager. In smart licensing cluster mode, you can log into any
of the email gateways and configure smart licensing feature. You can log into an email gateway and access
other email gateways one by one in the cluster and configure the smart licensing feature without logging off
from the first email gateway.
For more information, see Centralized Management Using Clusters, on page 1219.
Virtual Email Gateway License
To set up and license a virtual email gateway, see the Cisco Content Security Virtual Appliance Installation
Guide . This document is available from the location specified in Documentation .
Note You cannot open a Technical Support tunnel or run the System Setup Wizard before installing the virtual
email gateway license.
Virtual Email Gateway License Expiration
After the virtual email gateway license expires, the email gateway will continue to deliver mail without security
services for 180 days. Security service updates do not occur during this period.
Alerts will be sent 180 days, 150 days, 120 days, 90 days, 60 days, 30 days, 15 days, 5 days, 1 day and 0
seconds before the license expires, and at the same intervals before the grace period ends. These alerts will
be of type “System” at severity level “Critical.” To ensure that you receive these alerts, see Adding Alert
Recipients, on page 1045.
These alerts are also logged in the system log.
Individual feature keys may expire earlier than the virtual email gateway license. You will also receive alerts
when these approach their expiration dates.
Related Topics
• Reverting AsyncOS on Virtual Email Gateways May Impact the License , on page 1040
Managing the Configuration File
All configuration settings within the email gateway can be managed via a single configuration file. The file
is maintained in XML (Extensible Markup Language) format.
You can use this file in several ways:
• You can save the configuration file to a different system to back up and preserve crucial configuration
data. If you make a mistake while configuring your email gateway, you can “roll back” to the most
recently saved configuration file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1017
System Administration
Managing Multiple Email Gateways with XML Configuration Files
• You can download the existing configuration file to view the entire configuration for an email gateway
quickly. (Many newer browsers include the ability to render XML files directly.) This may help you
troubleshoot minor errors (like typographic errors) that may exist in the current configuration.
• You can download an existing configuration file, make changes to it, and upload it to the same email
gateway. This, in effect, “bypasses” both the CLI and the web interface for making configuration changes.
• You can upload entire configuration file via FTP access, or you can paste portions of or an entire
configuration file directly into the CLI.
• Because the file is in XML format, an associated DTD (document type definition) that describes all of
the XML entities in the configuration file is also provided. You can download the DTD to validate an
XML configuration file before uploading it. (XML Validation tools are readily available on the Internet.)
Managing Multiple Email Gateways with XML Configuration Files
• You can download an existing configuration file from one email gateway, make changes to it, and upload
it to a different email gateway. This lets you manage an installation of multiple email gateways more
easily. Currently you may not load configuration files from C/X-Series email gateways onto an M-Series
Cisco Secure Manager Email and Web Gateway.
• You can divide an existing configuration file downloaded from one email gateway into multiple
subsections. You can modify those sections that are common among all email gatewayS (in a multiple
email gateway environment) and load them onto other email gateways as the subsections are updated.
For example, you could use an email gateway in a test environment for testing the Global Unsubscribe
command. When you feel that you have configured the Global Unsubscribe list appropriately, you could then
load the Global Unsubscribe configuration section from the test email gateway to all of your production email
gateways.
Managing Configuration Files
To manage configuration files on your email gateway, click the System Administration> Configuration File.
The Configuration File page contains the following sections:
• Current Configuration - used to save and export the current configuration file.
• Load Configuration - used to load a complete or partial configuration file.
• End-User Safelist/Blocklist Database (Spam Quarantine) - For information, see Using Safelists and
Blocklists to Control Email Delivery Based on Sender , on page 953 and Backing Up and Restoring the
Safelist/Blocklist , on page 962.
• Reset Configuration - used to reset the current configuration back to the factory defaults (you should
save your configuration prior to resetting it).
Note The private keys and certificates are included in unencrypted PEM format along with the configuration file
with encrypted passphrase.
Related Topics
• Saving and Exporting the Current Configuration File, on page 1019
• Loading a Configuration File, on page 1019
• Mailing the Configuration File, on page 1019
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1018
System Administration
Saving and Exporting the Current Configuration File
• Resetting the Current Configuration, on page 1022
Saving and Exporting the Current Configuration File
Using the Current Configuration section of the System Administration > Configuration File page, you
can save the current configuration file to your local machine, save it on the email gateway (placed in the
configuration directory in the FTP/SCP root), or email it to the address specified.
The following information is not saved with the configuration file:
• Certificates used for secure communications with services used by the URL filtering feature.
• CCO User IDs and Contract ID saved on the Contact Technical Support page.
You can mask the user’s passphrases by clicking the Mask passphrases in the Configuration Files checkbox.
Masking a passphrase causes the original, encrypted passphrase to be replaced with “*****” in the exported
or saved file. Please note, however, that configuration files with masked passphrases cannot be loaded back
into AsyncOS.
You can encrypt the user’s passphrases by clicking the Encrypt passphrases in the Configuration Files
checkbox. The following are the critical security parameters in the configuration file that will be encrypted.
• Certificate private keys
• RADIUS passwords
• LDAP bind passwords
• Local users' password hashes
• SNMP password
• DK/DKIM signing keys
• Outgoing SMTP authentication passwords
• PostX encryption keys
• PostX encryption proxy password
• FTP Push log subscriptions' passwords
• IPMI LAN password
• Updater server URLs
You can also configure this in the command-line interface using the saveconfig command.
Mailing the Configuration File
Use the Email file to field in the System Administration > Configuration File or use the m ailconfig command
to email the current configuration to a user as an attachement.
Loading a Configuration File
Use the Load Configuration section of the System Administration > Configuration File page to load new
configuration information into the email gateway. You can also configure this in the command-line interface
using the loadconfig command.
You can load information in one of three methods:
• Placing information in the configuration directory and uploading it.
• Uploading the configuration file directly from your local machine.
• Pasting configuration information directly.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1019
System Administration
Loading a Configuration File
Note Configuration files with masked passphrases cannot be loaded.
In cluster mode, you can either choose to load the configuration for a cluster or an email gateway. For
instructions to load cluster configuration, see Loading a Configuration in Clustered Email Gateway, on page
1241.
Regardless of the method, you must include the following tags at the top of your configuration:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE config SYSTEM "config.dtd">
<config>
... your configuration information in valid XML
</config>
The closing </config> tag should follow your configuration information. The values in XML syntax are
parsed and validated against the DTD (document type definition) located in the configuration directory on
your email gateway. The DTD file is named config.dtd . If validation errors are reported at the command
line when you use the loadconfig command, the changes are not loaded. You can download the DTD to
validate configuration files outside of the email gateway before uploading them.
In either method, you can import an entire configuration file (the information defined between the highest
level tags: <config></config> ), or a complete and unique sub-section of the configuration file, as long as it
contains the declaration tags (above) and is contained within the <config></config> tags.
“Complete” means that the entire start and end tags for a given subsection as defined by the DTD are included.
For example, uploading or pasting this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE config SYSTEM "config.dtd">
<config>
<autosupport_enabled>0</autosu
</config>
will cause validation errors, while uploading. This, however:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE config SYSTEM "config.dtd">
<config>
<autosupport_enabled>0</autosupport_enabled>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1020
System Administration
Empty vs. Omitted Tags
</config>
will not.
“Unique” means that the subsection of the configuration file being uploaded or pasted is not ambiguous for
the configuration. For example, a system can have only one hostname, so uploading this (including the
declarations and <config></config> tags):
<hostname>mail4.example.com</hostname>
is allowed. However, a system can have multiple listeners defined, each with different Recipient Access Tables
defined, so uploading only this:
<rat>
<rat_entry>
<rat_address>ALL</rat_address>
<access>RELAY</access>
</rat_entry>
</rat>
is considered ambiguous and is not allowed, even though it is “complete” syntax.
Caution When uploading or pasting a configuration file or subsections of a configuration file, you have the potential
to erase uncommitted changes that may be pending.
If disk space allocations in the configuration file are smaller than the amount of data currently stored on the
email gateway, the oldest data will be deleted to meet the quota specified in the configuration file.
Empty vs. Omitted Tags
Use caution when uploading or pasting sections of configuration files. If you do not include a tag, then its
value in the configuration is not modified when you load a configuration file. However, if you include an
empty tag, then its configuration setting is cleared.
For example, uploading this:
<listeners></listeners>
will remove all listeners from the system!
Caution When uploading or pasting subsections of a configuration file, you have the potential to disconnect yourself
from the web interface or CLI and to destroy large amounts of configuration data. Do not disable services
with this command if you are not able to reconnect to the email gateway using another protocol, the Serial
interface, or the default settings on the Management port. Also, do not use this command if you are unsure
of the exact configuration syntax as defined by the DTD. Always back up your configuration data prior to
loading a new configuration file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1021
System Administration
Note About Loading Passphrases for Log Subscriptions
Note About Loading Passphrases for Log Subscriptions
If you attempt to load a configuration file that contains a log subscription that requires a passphrase (for
example, one that will use FTP push), the loadconfig command does not warn you about the missing passphrase.
The FTP push will fail and alerts will be generated until you configure the correct passphrase using the
logconfig command.
Note About Character Set Encoding
The “encoding” attribute of the XML configuration file must be “ ISO-8859-1 ” regardless of the character
set you may be using to manipulate the file offline. Note that the encoding attribute is specified in the file
whenever you issue the showconfig , saveconfig , or mailconfig commands:
<?xml version="1.0" encoding="ISO-8859-1"?>
Currently, only configuration files with this encoding can be loaded.
Related Topics
• Loading a Configuration in Clustered Email Gateway, on page 1241
Resetting the Current Configuration
Resetting the current configuration causes your email gateway to revert back to the original factory defaults.
You should save your configuration prior to resetting it. Resetting the configuration via this button in the GUI
is not supported in a clustering environment.
See Resetting to Factory Defaults, on page 1007.
Viewing the Configuration File
You can view the configuration file details using the showconfig command only. The showconfig command
prints the current configuration to the screen.
mail3.example.com> showconfig
Do you want to include passphrases? Please be aware that a configuration without
passphrases will fail when reloaded with loadconfig.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE config SYSTEM "config.dtd">
<!--
Product: IronPort model number Messaging Gateway Appliance(tm)
Model Number: model number
Version: version of AsyncOS installed
Serial Number: serial number
Current Time: current time and date
[The remainder of the configuration file is printed to the screen.]
Configuration File Page
• Managing the Configuration File, on page 1017
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1022
System Administration
Managing Disk Space
• Resetting to Factory Defaults, on page 1007
• Backing Up and Restoring the Safelist/Blocklist , on page 962
Managing Disk Space
• (Virtual Email Gateways Only) Increasing Available Disk Space , on page 1023
• Viewing and Allocating Disk Space Usage , on page 1023
• Managing Disk Space for the Miscellaneous Quota , on page 1024
• Ensuring That You Receive Alerts About Disk Space , on page 1024
(Virtual Email Gateways Only) Increasing Available Disk Space
For virtual email gateways running ESXi 5.5 and VMFS 5, you can allocate more than 2TB of disk space.
For email gateways running ESXi 5.1, the limit is 2 TB.
To add disk space to the virtual email gateway instance:
Note Disk space reduction is not supported. See the VMWare documentation for information.
Before You Begin
Carefully determine the disk space increase needed.
Procedure
Step 1 Bring down the email gateway instance.
Step 2 Increase disk space using utilities or administrative tools provided by VMWare.
See information about changing the virtual disk configuration in the VMWare documentation. At time of
release, this information for ESXi 5.5 was available here: http://pubs.vmware.com/vsphere-55/index.jsp?topic=
%2Fcom.vmware.vsphere.hostclient.doc%2FGUID-81629CAB-72FA-42F0-9F86-F8FD0DE39E57.html.
Step 3 Go to System Administration > Disk Management and verify that your change has taken effect.
Viewing and Allocating Disk Space Usage
You can optimize disk usage by allocating disk space on the email gateway among the features that your
deployment uses.
To Do This
• View disk space quotas and Go to System Administration > Disk Management.
current usage for each service
• Reallocate disk space on your
email gateway at any time
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1023
System Administration
Managing Disk Space for the Miscellaneous Quota
To Do This
Manage data volume • For reporting and tracking services and the spam quarantine, the
oldest data will be deleted automatically.
• For Policy, Virus and Outbreak quarantines, the default action
configured in the quarantine will be taken. See Default Actions
for Automatically Processed Quarantined Messages , on page 931.
• For the Miscellaneous quota, you must first manually delete data
to reduce usage below the new quota you will set. See Managing
Disk Space for the Miscellaneous Quota , on page 1024.
Managing Disk Space for the Miscellaneous Quota
The Miscellaneous quota includes System data and User data. You cannot delete System data. User data that
you can manage includes the following types of files:
To Manage Do this
Log files Go to System Administration > Log Subscriptions and:
• Look to see which log directories consume the most disk space.
• Verify that you need all of the log subscriptions that are being
generated.
• Verify that the log level is no more verbose than necessary.
• If feasible, reduce the rollover file size.
Packet captures Go to Help and Support (near the upper right side of your screen) >
Packet Capture.
Configuration files FTP to the /data/pub directory on the email gateway.
(These files are unlikely to To configure FTP access to the email gateway, see FTP, SSH, and SCP
consume much disk space.) Access, on page 1297
Quota size Go to System Administration > Disk Management.
Ensuring That You Receive Alerts About Disk Space
You will begin to receive system alerts at warning level when Miscellaneous disk usage reaches 75% of the
quota. You should take action when you receive these alerts.
To ensure that you receive these alerts, see Alerts, on page 1043.
Disk Space and Centralized Management
Disk space management is available only in machine mode, not in group or cluster mode.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1024
System Administration
Managing Security Services
Managing Security Services
The Services Overview page lists the current service and rule versions of the following engines:
• Graymail
• McAfee
• Sophos
You can perform the following tasks in the Services Overview page:
• Manually update the engines. For more information, see Manually Updating the Engines, on page 1025
• Rollback to previous version of the engine. For more information, see Rollback to Previous Version of
Engine, on page 1026
The Auto Update column shows the status of the automatic updates of a particular engine. If you want to
enable or disable Automatic Updates, go to the Global Settings page of particular engine.
When automatic updates are disabled for a specific service engine, you will receive alerts periodically. If you
want to change the alert interval, use the Alert Interval for Disabled Automatic Engine Updates option in
the Security Services > Service Updates page.
Note Auto Updates are disabled automatically for the engine on which the rollback is applied.
Related Topics
• Manually Updating the Engines, on page 1025
• Rollback to Previous Version of Engine, on page 1026
• Viewing Logs, on page 1026
• System Alerts, on page 1051
Manually Updating the Engines
Procedure
Step 1 Go to Security Services > Services Overview page.
Step 2 Click Update in the Available Updates column for the latest service or rule version of the service engine.
Note The Update option is available only if new updates are available for the particular engine.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1025
System Administration
Rollback to Previous Version of Engine
Rollback to Previous Version of Engine
Procedure
Step 1 Go to Security Services > Services Overview page.
Step 2 Click Change in the Modify Versions column.
Step 3 Select the required rule and service version of the update and click Apply.
The email gateway rolls back the engine to the previous version.
Note A Service Updates includes the service version and the rule version together as a package.
Once you click Apply, the automatic updates for the particular engine is automatically disabled. To enable
the automatic updates, go to the Global Settings page of the particular engine.
Viewing Logs
The information about engine rollback and disabling automatic updates is posted to the following logs:
• Updater Logs: Contains information about the engine rollback and automatic updating of the engine.
Most information is at Info or Debug level.
For more information, see Updater Log Example, on page 1191.
Service Updates
The following services require updates for maximum effectiveness:
• Feature Keys
• McAfee Anti-Virus definitions
• PXE Engine
• Sophos Anti-Virus definitions
• IronPort Anti-Spam rules
• Outbreak Filters rules
• Time zone rules
• URL categories (Used for URL filtering features. For details, see Future URL Category Set Changes ,
on page 480)
• Enrollment client (Used for updating certificates needed for communication with cloud-based services
used for URL filtering features. For information, see About the Connection to Talos Intelligence Services
, on page 452.)
• Graymail rules
Note Settings for the DLP engine and content matching classifiers are handled on the Security Services > Data
Loss Prevention page. See About Updating the DLP Engine and Content Matching Classifiers, on page 536
for more information.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1026
System Administration
Setting Up to Obtain Upgrades and Updates
Service update settings are used for all services that receive updates except DLP updates. You cannot specify
unique settings for any individual service except DLP updates.
To set up the network and the email gateway to obtain these critical updates, see Setting Up to Obtain Upgrades
and Updates , on page 1027.
Setting Up to Obtain Upgrades and Updates
• Options for Distributing Upgrades and Updates , on page 1027
• Configuring Your Network to Download Upgrades and Updates from the Cisco Servers , on page 1027
• Configuring the Email Gateway for Upgrades and Updates in Strict Firewall Environments, on page 1028
• Upgrading and Updating from a Local Server, on page 1028
• Hardware and Software Requirements for Upgrading and Updating from a Local Server, on page 1029
• Hosting an Upgrade Image on a Local Server, on page 1030
• Configuring Server Settings for Downloading Upgrades and Updates , on page 1030
• Configuring Automatic Updates , on page 1032
• Configuring the Email Gateway to Verify the Validity of Updater Server Certificate, on page 1033
• Configuring the Appliance to Trust Proxy Server Communication, on page 1034
Options for Distributing Upgrades and Updates
There are several ways to distribute AsyncOS upgrade and update files to your email gateways:
• Each email gateway can download the files directly from the Cisco update servers. This is the default
method.
• You can download the files from Cisco once, and then distribute them to your email gateways from a
server within your network. See Upgrading and Updating from a Local Server, on page 1028.
To choose and configure a method, see Configuring Server Settings for Downloading Upgrades and Updates
, on page 1030.
Configuring Your Network to Download Upgrades and Updates from the Cisco
Servers
The email gateway connect directly to the Cisco update servers to find and download upgrades and updates:
Figure 73: Streaming Update Method
Cisco update servers use dynamic IP addresses. If you have strict firewall policies, you may need to configure
a static location instead. For more information, see Configuring the Email Gateway for Upgrades and Updates
in Strict Firewall Environments, on page 1028.
Create a firewall rule to allow downloading of upgrades from Cisco update servers on ports 80 and 443.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1027
System Administration
Configuring the Email Gateway for Upgrades and Updates in Strict Firewall Environments
Configuring the Email Gateway for Upgrades and Updates in Strict Firewall
Environments
The Cisco IronPort upgrade and update servers use dynamic IP addresses. If you have strict firewall policies,
you may need to configure a static location for updates and AsyncOS upgrades.
Procedure
Step 1 Contact Cisco Customer support to obtain the static URL address.
Step 2 Create a firewall rule to allow downloading of upgrades and updates from the static IP address on port 80.
Step 3 Choose Security Services > Service Updates.
Step 4 Click Edit Update Settings.
Step 5 On the Edit Update Settings page, in the “Update Servers (images)” section, choose Local Update Servers
and enter the static URL received in step 1 in the Base URL field for AsyncOS upgrades and McAfee Anti-Virus
definitions.
Step 6 Verify that IronPort Update Servers is selected for the “Update Servers (list)” section.
Step 7 Submit and commit your changes.
Upgrading and Updating from a Local Server
You can download AsyncOS upgrade images to a local server and host upgrades from within your own network
rather than obtaining upgrades directly from Cisco’s update servers. Using this feature, an upgrade image is
downloaded via HTTP to any server in your network that has access to the Internet. If you choose to download
the upgrade image, you can then configure an internal HTTP server (an “update manager”) to host the AsyncOS
images to your appliances.
Use a local server if your email gateway does not have access to the internet, or if your organization restricts
access to mirror sites used for downloads. Downloading AsyncOS upgrades to each email gateway from a
local server is generally faster than downloading from the Cisco IronPort servers.
Note Cisco recommends using a local server only for AsyncOS upgrades. If you use a local update server for
security update images, the local server does not automatically receive security updates from Cisco IronPort,
so the email gateways in your network may not always have the most current security services.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1028
System Administration
Hardware and Software Requirements for Upgrading and Updating from a Local Server
Figure 74: Remote Update Method
Procedure
Step 1 Configure a local server to retrieve and serve the upgrade files.
Step 2 Download the upgrade files.
Step 3 Configure the appliance to use the local server using either the Security Services > Service Updates page
in the GUI or the updateconfig command in the CLI.
Step 4 Upgrade the appliance using either the System Administration > System Upgrade page or the upgrade
command in the CLI.
Hardware and Software Requirements for Upgrading and Updating from a
Local Server
For downloading AsyncOS upgrade and update files, you must have a system in your internal network that
has:
• Internet access to the Cisco Systems update servers.
• A web browser (see Browser Requirements, on page 21).
Note For this release, if you need to configure a firewall setting to allow HTTP access
to this address, you must configure it using the DNS name and not a specific IP
address.
For hosting AsyncOS update files, you must have a server in your internal network that has:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1029
System Administration
Hosting an Upgrade Image on a Local Server
• A web server — for example, Microsoft IIS (Internet Information Services) or the Apache open source
server — which:
• supports the display of directory or filenames in excess of 24 characters
• has directory browsing enabled
• is configured for anonymous (no authentication) or basic (“simple”) authentication
• contains at least 350MB of free disk space for each AsyncOS update image
Hosting an Upgrade Image on a Local Server
After setting up a local server, go to http://updates.ironport.com/fetch_manifest.html to download a ZIP file
of an upgrade image. To download the image, enter your serial number (for a physical email gateway) or a
VLN (for a virtual email gateway) and the version number of the email gateway. You will then be presented
with a list of available upgrades. Click on the upgrade version that you want to download, and unzip the ZIP
file in the root directory on the local server while keeping the directory structure intact. To use the upgrade
image, configure the email gateway to use the local server on the Edit Update Settings page (or use updateconfig
in the CLI).
The local server also hosts an XML file that limits the available AsyncOS upgrades for the email gateways
on your network to the downloaded upgrade image. This file is called the “manifest.” The manifest is located
in the asyncos directory of the upgrade image ZIP file. After unzipping the ZIP file in the root directory of
the local server, enter the full URL for the XML file, including the filename, on the Edit Update Settings page
(or use updateconfig in the CLI).
For more information about remote upgrades, please see the Knowledge Base or contact your Cisco Support
provider.
UpdatesThrough a Proxy Server
The email gateway is configured (by default) to connect directly to Cisco’s update servers to receive updates.
This connection is made by HTTP on port 80 and the content is encrypted. If you do not want to open this
port in your firewall, you can define a proxy server and specific port from which the email gateway can receive
updated rules.
If you choose to use a proxy server, you can specify an optional authentication and port.
Note If you define a proxy server, it will automatically be used for all service updates that are configured to use a
proxy server. There is no way to turn off the proxy server for updates to any individual service.
Configuring Server Settings for Downloading Upgrades and Updates
Specify the server and connection information required to download upgrades and updates to your email
gateway.
You can use the same or different settings for AsyncOS upgrades and for service updates.
Before You Begin
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1030
System Administration
Configuring Server Settings for Downloading Upgrades and Updates
Determine whether the email gateway will download upgrades and updates directly from Cisco, or whether
you will host these images from a local server on your network instead. Then set up your network to support
the method you choose. See all topics under Setting Up to Obtain Upgrades and Updates , on page 1027.
Procedure
Step 1 Choose Security Services > Service Updates.
Step 2 Click Edit Update Settings.
Step 3 Enter options:
Setting Description
Update Servers (images) Choose whether to download Cisco IronPort AsyncOS upgrade images and
service updates from the Cisco IronPort update servers or a from a local
server on your network. The default is the Cisco IronPort update servers
for both upgrades and updates.
To use the same settings for upgrades and updates, enter information in the
visible fields.
If you choose a local update server, enter the base URL and port number
for the servers used to download the upgrades and updates. If the server
requires authentication, you can also enter a valid username and passphrase.
To enter separate settings solely for AsyncOS upgrades and McAfee
Anti-Virus definitions, click the Click to use different settings for
AsyncOS link.
Note Cisco Intelligent Multi-Scan requires a second local server to
download updates for third-party anti-spam rules.
Update Servers (lists) To ensure that only upgrades and updates that are appropriate to your
deployment are available to each email gateway, Cisco IronPort generates
a manifest list of the relevant files.
Choose whether to download the lists of available upgrades and service
updates (the manifest XML files) from the Cisco IronPort update servers
or from a local server on your network.
There are separate sections for specifying servers for updates and for
AsyncOS upgrades. The default for upgrades and updates is the Cisco
IronPort update servers.
If you choose local update servers, enter the full path to the manifest XML
file for each list, including the file name and HTTP port number for the
server. If you leave the port field blank, AsyncOS uses port 80. If the server
requires authentication, enter a valid user name and passphrase.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1031
System Administration
Configuring Automatic Updates
Setting Description
Automatic Updates Enable automatic updates and the update interval (how often the email
gateway checks for updates) for Sophos and McAfee Anti-Virus definitions,
Cisco Anti-Spam rules, Cisco Intelligent Multi-Scan rules, PXE Engine
updates, Outbreak Filter rules, and time zone rules.
Include a trailing s, m, or h to indicate seconds, minutes, or hours. Enter 0
(zero) to disable automatic updates.
Note You can only turn on automatic updates for DLP using the
Security Services > Data Loss Prevention page. However, you
must enable automatic updates for all services first. See About
Updating the DLP Engine and Content Matching Classifiers, on
page 536 for more information.
Alert Interval for Disabled Enter specific frequency of alerts to be sent when the ‘Automatic Updates’
Automatic Engine Updates feature is disabled for a specific engine.
Include a trailing m, h, or d to indicate months, hours, or days. The default
value is 30 days.
Interface Choose which network interface to use when contacting the update servers
for the listed security component updates. The available proxy data
interfaces are shown. By default, the email gateway selects an interface to
use.
HTTP Proxy Server An optional proxy server used for the services listed in the GUI.
If you specify a proxy server, it will be used to update ALL services.
HTTPS Proxy Server An optional proxy server using HTTPS. If you define the HTTPS proxy
server, it will be used to update the services listed in the GUI.
Step 4 Submit and commit your changes.
Configuring Automatic Updates
Procedure
Step 1 Navigate to the Security Services > Service Updates page, and click Edit Update Settings.
Step 2 Select the check box to enable automatic updates.
Step 3 Enter an update interval (time to wait between checks for updates). Add a trailing m for minutes and h for
hours. The maximum update interval is 1 hour.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1032
System Administration
Configuring the Email Gateway to Verify the Validity of Updater Server Certificate
Configuring the Email Gateway to Verify the Validity of Updater Server
Certificate
The email gateway can check the validity of Cisco updater server certificate every time the email gateway
communicates the updater server. If you configure this option and the verification fails, updates are not
downloaded and the details are logged in Updater Logs.
Use the updateconfig command to configure this option. The following example shows how to configure this
option.
mail.example.com> updateconfig
Service (images): Update URL:
------------------------------------------------------------------------------------------
Feature Key updates http://downloads.ironport.com/asyncos
Timezone rules Cisco IronPort Servers
Enrollment Client Updates Cisco IronPort Servers
Support Request updates Cisco IronPort Servers
Cisco IronPort AsyncOS upgrades Cisco IronPort Servers
Service (list): Update URL:
------------------------------------------------------------------------------------------
Timezone rules Cisco IronPort Servers
Enrollment Client Updates Cisco IronPort Servers
Support Request updates Cisco IronPort Servers
Service (list): Update URL:
------------------------------------------------------------------------------------------
Cisco IronPort AsyncOS upgrades Cisco IronPort Servers
Update interval: 5m
Proxy server: not enabled
HTTPS Proxy server: not enabled
Choose the operation you want to perform:
- SETUP - Edit update configuration.
- VALIDATE_CERTIFICATES - Validate update server certificates
- TRUSTED_CERTIFICATES - Manage trusted certificates for updates
[]> validate_certificates
Should server certificates from Cisco update servers be validated?
[Yes]>
Service (images): Update URL:
------------------------------------------------------------------------------------------
Feature Key updates http://downloads.ironport.com/asyncos
Timezone rules Cisco IronPort Servers
Enrollment Client Updates Cisco IronPort Servers
Support Request updates Cisco IronPort Servers
Cisco IronPort AsyncOS upgrades Cisco IronPort Servers
Service (list): Update URL:
------------------------------------------------------------------------------------------
Timezone rules Cisco IronPort Servers
Enrollment Client Updates Cisco IronPort Servers
Support Request updates Cisco IronPort Servers
Service (list): Update URL:
------------------------------------------------------------------------------------------
Cisco IronPort AsyncOS upgrades Cisco IronPort Servers
Update interval: 5m
Proxy server: not enabled
HTTPS Proxy server: not enabled
Choose the operation you want to perform:
- SETUP - Edit update configuration.
- VALIDATE_CERTIFICATES - Validate update server certificates
- TRUSTED_CERTIFICATES - Manage trusted certificates for updates
[]>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1033
System Administration
Configuring the Appliance to Trust Proxy Server Communication
Configuring the Appliance to Trust Proxy Server Communication
If you are using a non-transparent proxy server, you can add the CA certificate used to sign the proxy certificate
to the email gateway. By doing so, the email gateway trusts the proxy server communication.
Use the updateconfig command to configure this option. The following example shows how to configure this
option.
mail.example.com> updateconfig
...
...
...
Choose the operation you want to perform:
- SETUP - Edit update configuration.
- VALIDATE_CERTIFICATES - Validate update server certificates
- TRUSTED_CERTIFICATES - Manage trusted certificates for updates
[]> trusted_certificates
Choose the operation you want to perform:
- ADD - Upload a new trusted certificate for updates.
[]> add
Paste certificates to be trusted for secure updater connections, blank to quit
Trusted Certificate for Updater:
Paste cert in PEM format (end with '.'):
-----BEGIN CERTIFICATE-----
MMIICiDCCAfGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBgDELMAkGA1UEBhMCSU4x
DDAKBgNVBAgTA0tBUjENM............................................
-----END CERTIFICATE-----
.
Choose the operation you want to perform:
- ADD - Upload a new trusted certificate for updates.
- LIST - List trusted certificates for updates.
- DELETE - Delete a trusted certificate for updates.
[]>
Upgrading AsyncOS
Procedure
Command or Action Purpose
Step 1 If you have not yet done so, configure settings Setting Up to Obtain Upgrades and Updates ,
that apply to all update and upgrade downloads, on page 1027
and set up your network to support and
optionally distribute these downloads.
Step 2 Understand when an upgrade is available and Notifications of Available Upgrades, on page
determine whether to install it. 1035
Step 3 Perform required and recommended tasks Preparing to Upgrade AsyncOS, on page 1036
before each upgrade.
Upgrading Machines in a Cluster, on page 1231
Step 4 Perform the upgrade. Downloading and Installing the Upgrade , on
page 1036
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1034
System Administration
About Upgrading Clustered Systems
About Upgrading Clustered Systems
If you are upgrading clustered machines, please see Upgrading Machines in a Cluster, on page 1231.
About Batch Commands for Upgrade Procedures
Batch commands for upgrade procedures are documented in the CLI Reference Guide for AsyncOS for Cisco
Email Security Appliances at
http://www.cisco.com/en/US/products/ps10154/prod_command_reference_list.html.
Notifications of Available Upgrades
By default, users with administrator and technician privileges will see a notification at the top of the web
interface when an AsyncOS upgrade is available for the email gateway.
On clustered machines, actions apply only to the machine to which you are logged in.
To Do This
View more information about the latest upgrade Hover over the upgrade notification.
View a list of all available upgrades Click the down arrow in the notification.
Dismiss a current notification. Click the down arrow, then select Clear the
notification, then click Close.
The email gateway will not display another notification
until a new upgrade becomes available.
Prevent future notifications (Users with Administrator Go to Management Appliance > System
privileges only.) Administration > System Upgrade.
Notifications of Available Upgrades
By default, users with administrator and technician privileges will see a notification at the top of the web
interface when an AsyncOS upgrade is available for the email gateway.
On clustered machines, actions apply only to the machine to which you are logged in.
To Do This
View more information about the latest upgrade Hover over the upgrade notification.
View a list of all available upgrades Click the down arrow in the notification.
Dismiss a current notification. Click the down arrow, then select Clear the
notification, then click Close.
The email gateway will not display another notification
until a new upgrade becomes available.
Prevent future notifications (Users with Administrator Go to Management Appliance > System
privileges only.) Administration > System Upgrade.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1035
System Administration
Preparing to Upgrade AsyncOS
Preparing to Upgrade AsyncOS
As a best practice, Cisco recommends preparing for an upgrade by taking the following steps.
Before you begin
Clear all the messages in your work queue. You cannot perform the upgrade without clearing your work
queue.
Procedure
Step 1 Save the XML configuration file off-box. If you need to revert to the pre-upgrade release for any reason, you
will need this file.
Step 2 If you are using the Safelist/Blocklist feature, export the list off-box.
Step 3 Suspend all listeners. If you perform the upgrade from the CLI, use the suspendlistener command. If you
perform the upgrade from the GUI, listener suspension occurs automatically.
Step 4 Wait for the queue to empty. You can use the workqueue command to view the number of messages in the
work queue or the rate command in the CLI to monitor the message throughput on your email gateway.
Note Re-enable the listeners post-upgrade.
Downloading and Installing the Upgrade
You can download and install in a single operation, or download in the background and install later.
Note When downloading and upgrading AsyncOS in a single operation from a local server instead of from a Cisco
IronPort server, the upgrade installs immediately while downloading . A banner displays for 10 seconds at
the beginning of the upgrade process. While this banner is displayed, you have the option to type Control-C
to exit the upgrade process before downloading starts.
Before You Begin
• Choose whether you will download upgrades directly from Cisco or will host upgrade images from a
server on your network. Then set up your network to support the method you choose. Then configure
the email gateway to obtain upgrades from your chosen source. See Setting Up to Obtain Upgrades and
Updates , on page 1027 and Configuring Server Settings for Downloading Upgrades and Updates , on page
1030.
• If you will install the upgrade now, follow the instructions in Preparing to Upgrade AsyncOS, on page
1036.
• If you are installing the upgrade in a clustered system, see Upgrading Machines in a Cluster, on page
1231.
• If you will only download the upgrade, there are no prerequisites until you are ready to install it.
• After you upgrade, you cannot use TLS v1.0 in FIPS mode. However, you can re-enable TLS v1.0 on
the email gateway, if necessary.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1036
System Administration
Downloading and Installing the Upgrade
Procedure
Step 1 Choose System Administration > System Upgrade.
Step 2 Click Upgrade Options.
Step 3 Click Upgrade to proceed with the upgrade process.
Step 4 Choose an option:
To Do This
Download and install the upgrade in Click Download and Install.
a single operation
If you have already downloaded an installer, you will be prompted to
overwrite the existing download.
Download an upgrade installer Click Download only.
If you have already downloaded an installer, you will be prompted to
overwrite the existing download.
The installer downloads in the background without interrupting service.
Install a downloaded upgrade installer Click Install.
This option appears only if an installer has been downloaded.
The AsyncOS version to be installed is noted below the Install option.
Step 5 Unless you are installing a previously-downloaded installer, select an AsyncOS version from the list of
available upgrades.
Step 6 If you are installing:
a) Choose whether or not to save the current configuration to the configuration directory on the email gateway.
b) Choose whether or not to mask the passphrases in the configuration file.
Note You cannot load a configuration file with masked passphrases using the Configuration File page
in the GUI or the loadconfig command in the CLI.
c) If you want to email copies of the configuration file, enter the email addresses to which you want to email
the file. Use commas to separate multiple email addresses.
Step 7 Click Proceed.
Step 8 If you are installing:
a) Be prepared to respond to prompts during the process.
The process pauses until you respond.
A progress bar appears near the top of the page.
b) At the prompt, click Reboot Now.
c) After about 10 minutes, access the email gateway again and log in.
If you feel you need to power-cycle the email gateway to troubleshoot an upgrade issue, do not do so until
at least 20 minutes have passed since you rebooted.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1037
System Administration
Viewing Status of, Canceling, or Deleting a Background Download
What to do next
• If the process was interrupted, you must start the process again.
• If you downloaded but did not install the upgrade:
When you are ready to install the upgrade, follow these instructions from the beginning, including the
prerequisites in the Before You Begin section, but choose the Install option.
• If you installed the upgrade:
• Re-enable (resume) the listeners.
• Save a configuration file for the new system. For information, see Managing the Configuration File,
on page 1017.
• After upgrade is complete, re-enable listeners.
Viewing Status of, Canceling, or Deleting a Background Download
Procedure
Step 1 Choose System Administration > System Upgrade.
Step 2 Click Upgrade Options.
Step 3 Choose an option:
To Do This
View download status Look in the middle of the page.
If there is no download in progress and no completed download waiting
to be installed, you will not see download status information.
Cancel a download Click the Cancel Download button in the middle of the page.
This option appears only while a download is in progress.
Delete a downloaded installer Click the Delete File button in the middle of the page.
This option appears only if an installer has been downloaded.
Step 4 (Optional) View the Upgrade Logs.
Enabling Remote Power Cycling
The ability to remotely reset the power for the email gateway chassis is available only on 80 - and 90- series
hardware.
If you want to be able to remotely reset email gateway power, you must enable and configure this functionality
in advance, using the procedure described in this section.
Before You Begin
• Cable the dedicated Remote Power Cycle (RPC) port directly to a secure network. For information, see
the Hardware Installation Guide.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1038
System Administration
Reverting to a Previous Version of AsyncOS
• Ensure that the email gateway is accessible remotely; for example, open any necessary ports through the
firewall.
• This feature requires a unique IPv4 address for the dedicated Remote Power Cycle interface. This interface
is configurable only via the procedure described in this section; it cannot be configured using the
ipconfig command.
• In order to cycle email gateway power, you will need a third-party tool that can manage devices that
support the Intelligent Platform Management Interface (IPMI) version 2.0. Ensure that you are prepared
to use such a tool.
• For more information about accessing the command-line interface, see the CLI reference guide.
Procedure
Step 1 Use SSH or the serial console port to access the command-line interface.
Step 2 Sign in using an account with Administrator access.
Step 3 Enter the following commands:
remotepower
setup
Step 4 Follow the prompts to specify the following:
a. The dedicated IP address for this feature, plus netmask and gateway.
b. The username and passphrase required to execute the power-cycle command.
These credentials are independent of other credentials used to access your email gateway.
Step 5 Enter commit to save your changes.
Step 6 Test your configuration to be sure that you can remotely manage email gateway power.
Step 7 Ensure that the credentials that you entered will be available to you in the indefinite future. For example, store
this information in a safe place and ensure that administrators who may need to perform this task have access
to the required credentials.
What to do next
Related Topics
• Remotely Resetting Email Gateway Power , on page 1269
Reverting to a Previous Version of AsyncOS
AsyncOS includes the ability to revert the AsyncOS operating system to a previous qualified build for
emergency uses.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1039
System Administration
Reversion Impact
Reversion Impact
Using the revert command on an email gateway is a very destructive action. This command destroys all
configuration logs and databases. Only the network information for the management interface is preserved--all
other network configuration is deleted. In addition, reversion disrupts mail handling until the email gateway
is reconfigured. Because this command destroys network configuration, you may need physical local access
to the email gateway when you want to issue the revert command.
Caution You must have a configuration file for the version you want to revert to. Configuration files are not
backwards-compatible.
Reverting AsyncOS on Virtual Email Gateways May Impact the License
If you revert from AsyncOS 9.0 for Email to AsyncOS 8.5 for Email, the license does not change.
If you revert from AsyncOS 9.0 for Email to AsyncOS 8.0 for Email, there is no longer a 180-day grace period
during which the email gateway delivers mail without security features.
Feature key expiration dates do not change in either case.
Related Topics
• Virtual Email Gateway License Expiration , on page 1017
Reverting AsyncOS
Procedure
Step 1 Ensure that you have the configuration file for the version you wish to revert to. Configuration files are not
backwards-compatible. To do this, you can email the file to yourself or FTP the file. For information, see
Mailing the Configuration File, on page 1019.
Step 2 Save a backup copy of the current configuration of your email gateway (with passphrases unmasked) on
another machine.
Note This is not the configuration file you will load after reverting.
Step 3 If you use the Safelist/Blocklist feature, export the Safelist/Blocklist database to another machine.
Step 4 Wait for the mail queue to empty.
Step 5 Log into the CLI of the email gateway you want to revert.
When you run the revert command, several warning prompts are issued. After these warning prompts are
accepted, the revert action takes place immediately. Therefore, do not begin the reversion process until after
you have completed the pre-reversion steps.
Step 6 From the CLI, Issue the revert command.
Note The reversion process is time-consuming. It may take fifteen to twenty minutes before reversion is
complete and console access to the email gateway is available again.
Step 7 Wait for the email gateway to reboot twice.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1040
System Administration
Configuring the Return Address for Email Gateway Generated Messages
Step 8 After the machine reboots twice, use the serial console to configure an interface with an accessible IP address
using the interfaceconfig command.
Step 9 Enable FTP or HTTP on one of the configured interfaces.
Step 10 Either FTP the XML configuration file you created, or paste it into the GUI interface.
Step 11 Load the XML configuration file of the version you are reverting to.
Step 12 If you use the Safelist/Blocklist feature, import and restore the Safelist/Blocklist database.
Step 13 Commit your changes.
The reverted email gateway should now run using the selected AsyncOS version.
Configuring the Return Address for Email Gateway Generated
Messages
You can configure the envelope sender for mail generated by AsyncOS for the following circumstances:
• Anti-Virus notifications
• Bounces
• DMARC feedback
• Notifications ( notify() and notify-copy() filter actions)
• Quarantine notifications (and “Send Copy” in quarantine management)
• Reports
• All other messages
You can specify the display, user, and domain names of the return address. You can also choose to use the
Virtual Gateway domain for the domain name.
You can modify the return address for system-generated email messages in the GUI or in the CLI using the
addressconfig command.
Procedure
Step 1 Navigate to the System Administration > Return Addresses page.
Step 2 Click Edit Settings.
Step 3 Make changes to the address or addresses you want to modify
Step 4 Submit and commit your changes.
Setting Thresholds for System Health Parameters
Depending on your organization's requirements, you can configure the threshold for various health parameters
of your email gateway such as CPU usage, maximum messages in the workqueue, and so on. You can also
configure the email gateway to send alerts when the specified threshold values are crossed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1041
System Administration
Setting Thresholds for System Health Parameters
Note To configure the threshold for system health parameters using CLI, use the healthconfig command. For more
information, see the CLI inline help or CLI Reference Guide for AsyncOS for Cisco Email Security Appliances
.
Before You Begin
Carefully determine the threshold values.
Procedure
Step 1 Click System Administration > System Health.
Step 2 Click Edit Settings.
Step 3 Configure the following options:
• Specify the threshold level for CPU usage (in percent).
Also, specify if you want to receive an alert if the current CPU usage has crossed the configured threshold
value. After the first alert is sent, if the CPU usage crosses the running average from the time the first
alert was triggered by five percent in 15 minutes, an additional alert is sent.
Note These alerts are triggered based only on the CPU usage of the mail handling process.
• Specify the threshold level for memory page swapping (in percent).
Also, specify if you want to receive an alert if the overall memory swap usage crosses the configured
threshold value. After the first alert is sent, if the memory page swapping crosses the value that triggered
the first alert by 150 percent or after a 15 minutes alert interval, an additional alert is sent. For example,
if the threshold is set to 10,
• When the memory swap usage reaches 10.1%, the first alert is sent.
• When the memory swap usage reaches 15.1% in 15 minutes, one more alert is sent.
• Specify the threshold level for maximum messages in workqueue (in number of messages).
Also, specify if you want to receive an alert if the number of messages in work queue has crossed the
configured threshold value. After the first alert is sent, if the maximum messages in work queue crosses
the value that triggered the first alert by 150 percent within 15 minutes, an additional alert is sent. For
example, if the threshold is set to 1000,
• When the maximum messages in work queue reached 1002, the first alert was sent.
• When the maximum messages in work queue reached 1510 with 15 minutes, one more alert is sent.
Note All the alerts for this feature belong to the System Alert category.
Step 4 Submit and commit your changes.
What to do next
If you have configured alerts for this feature, make sure that you subscribe to the System Alerts. For instructions,
see Adding Alert Recipients, on page 1045.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1042
System Administration
Checking the Health of Email Gateway
Checking the Health of Email Gateway
You can use the health check functionality to check the health of your email gateway. When you run the health
check, the system analyzes historical data (up to three months) in the current Status Logs to determine the
health of the email gateway.
Note For the system to perform this analysis, the Status Logs must contain a minimum of one month of logging
data.
To run the health check,
• On web interface, go to System Administration > System Health page and click Run Health Check.
• On CLI, run the command: healthcheck .
The analysis results will indicate whether system has experienced one or more of the following problems in
the last few months:
• Resource conservation mode
• Delay in mail processing
• High CPU usage
• High memory usage
• High memory page swapping
If the health check is indicating that your email gateway has experienced one or more of the above problems,
consider reviewing and fine-tuning your system configuration. For more information, see:
http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118881-technote-esa-00.html
.
Alerts
Alert messages are automatically-generated standard email messages that contain information about events
occurring on the appli email gatewaysance. These events can be of varying levels of importance (or severity)
from minor to major and pertain generally to a specific component or feature on your email gateway. Alerts
are generated by the email gateway. You can specify, at a much more granular level, which alert messages
are sent to which users and for which severity of event they are sent. Manage alerts via the System
Administration > Alerts page in the GUI (or via the alertconfig command in the CLI).
Alert Severities
Alerts can be sent for the following severities:
• Critical: Requires immediate attention.
• Warning: Problem or error requiring further monitoring and potentially immediate attention.
• Information: Information generated in the routine functioning of this device.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1043
System Administration
AutoSupport
AutoSupport
To allow Cisco to better support and design future system changes, the email gateway can be configured to
send Cisco Systems a copy of all alert messages generated by the system. This feature, called AutoSupport,
is a useful way to allow our team to be proactive in supporting your needs. AutoSupport also sends weekly
reports noting the uptime of the system, the output of the status command, and the AsyncOS version used.
By default, alert recipients set to receive Information severity level alerts for System alert types will receive
a copy of every message sent to Cisco. This can be disabled if you do not want to send the weekly alert
messages internally. To enable or disable this feature, see Configuring Alert Settings, on page 1045.
Alert Delivery
Alerts sent from the email gateway to addresses specified in the Alert Recipient follow SMTP routes defined
for those destinations
Since alert messages can be used to inform you of problems within your email gateway, they are not sent
using AsyncOS’s normal mail delivery system. Instead, alert messages pass through a separate and parallel
email system designed to operate even in the face of significant system failure in AsyncOS.
The alert mail system does not share the same configuration as AsyncOS, which means that alert messages
may behave slightly differently from other mail delivery:
• Alert messages are delivered using standard DNS MX and A record lookups.
• They do cache the DNS entries for 30 minutes and the cache is refreshed every 30 minutes, so in
case of DNS failure the alerts still go out.
• Alert messages do not pass through the work queue, so they are not scanned for viruses or spam. They
are also not subjected to message filters or content filters.
• Alert messages do not pass through the delivery queue, so they are not affected by bounce profiles or
destination control limits.
Note [Optional - Only if TLS support is enabled using the alertconfig CLI command and FQDN validation
enabled in the SSL Configuration settings page]: Check whether the 'Common Name,' 'SAN: DNS Name'
fields, or both present in the server certificate, are in the FQDN format.
Note [Optional - Only if TLS support is enabled using the alertconfig CLI command and X 509 validation enabled
in the SSL Configuration settings page]: Check for signature algorithm of the server certificate.
Example Alert Message
Date: 23 Mar 2005 21:10:19 +0000
From: IronPort C60 Alert [[email protected]]
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1044
System Administration
Adding Alert Recipients
Subject: Critical-example.com: (Anti-Virus) update via http://newproxy.example.com
failed
The Critical message is:
update via http://newproxy.example.com failed
Version: 4.5.0-419
Serial Number: XXXXXXXXXXXX-XXXXXXX
Timestamp: Tue May 10 09:39:24 2005
For more information about this error, please see
http://support.ironport.com
If you desire further information, please contact your support provider.
Adding Alert Recipients
The alerting engine allows for granular control over which alerts are sent to which alert recipients. For example,
you can configure the system to send only specific alerts to an alert recipient, configuring an alert recipient
to receive notifications only when Critical (severity) information about the System (alert type) is sent.
Note If you enabled AutoSupport during System Setup, the email address specified will receive alerts for all severities
and classes by default. You can change this configuration at any time.
Procedure
Step 1 Select System Administration > Alerts.
Step 2 Click Add Recipient.
Step 3 Enter the recipient’s email address. You can enter multiple addresses, separated by commas.
Step 4 (Optional) If you want to receive software release and critical support notification alerts from Cisco Support,
check the Release and Support Notifications checkbox.
Step 5 Select the alert types and severities that this recipient will receive.
Step 6 Submit and commit your changes.
Configuring Alert Settings
The following settings apply to all alerts.
Note Use the alertconfig CLI command to define the number of alerts to save on the email gateway to view later.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1045
System Administration
Alert Settings
Procedure
Step 1 Click Edit Settings on the Alerts page.
Step 2 Enter a Header From: address to use when sending alerts, or select Automatically Generated
(“alert@<hostname>”).
Step 3 Mark the checkbox if you want to specify the number of seconds to wait between sending duplicate alerts.
For more information, see Sending Duplicate Alerts, on page 1046.
• Specify the initial number of seconds to wait before sending a duplicate alert.
• Specify the maximum number of seconds to wait before sending a duplicate alert.
Step 4 You can enable AutoSupport by checking the IronPort AutoSupport option. For more information about
AutoSupport, see AutoSupport, on page 1044.
• If AutoSupport is enabled, the weekly AutoSupport report is sent to alert recipients set to receive System
alerts at the Information level. You can disable this via the checkbox.
Step 5 Submit and commit your changes.
Alert Settings
Alert settings control the general behavior and configuration of alerts, including:
• The RFC 2822 Header From: when sending alerts (enter an address or use the default
“alert@<hostname>”). You can also set this via the CLI, using the alertconfig -> from command.
• The initial number of seconds to wait before sending a duplicate alert.
• The maximum number of seconds to wait before sending a duplicate alert.
• The status of AutoSupport (enabled or disabled).
• The sending of AutoSupport’s weekly status reports to alert recipients set to receive System alerts at the
Information level.
Sending Duplicate Alerts
You can specify the initial number of seconds to wait before AsyncOS will send a duplicate alert. If you set
this value to 0, duplicate alert summaries are not sent and instead, all duplicate alerts are sent without any
delay (this can lead to a large amount of email over a short amount of time). The number of seconds to wait
between sending duplicate alerts (alert interval) is increased after each alert is sent. The increase is the number
of seconds to wait plus twice the last interval. So a 5 second wait would have alerts sent at 5 seconds, 15,
seconds, 35 seconds, 75 seconds, 155 seconds, 315 seconds, etc.
Eventually, the interval could become quite large. You can set a cap on the number of seconds to wait between
intervals via the maximum number of seconds to wait before sending a duplicate alert field. For example, if
you set the initial value to 5 seconds, and the maximum value to 60 seconds, alerts would be sent at 5 seconds,
15 seconds, 35 seconds, 60 seconds, 120 seconds, etc.
Viewing Recent Alerts
The email gatewayssaves the latest alerts so you can view them in both the GUI and the CLI in case you lose
or delete the alert messages. These alerts cannot be downloaded from the email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1046
System Administration
Alert Descriptions
To view a list of the latest alerts, click the View Top Alerts button on the Alerts page or use the displayalerts
command in the CLI. You can arrange the alerts in the GUI by date, level, class, text, and recipient.
By default, the email gateway saves a maximum of 50 alerts to displays in the Top Alerts window. Use the
alertconfig -> setup command in the CLI to edit the number of alerts that the email gateway saves. If you
want to disable this feature, change the number of alerts to 0.
Alert Descriptions
The following tables list alerts by classification, including the alert name (internal descriptor used by Cisco),
actual text of the alert, description, severity (critical, information, or warning) and the parameters (if any)
included in the text of the message. The value of the parameter is replaced in the actual text of the alert. For
example, an alert message below may mention “$ip” in the message text. “$ip” is replaced by the actual IP
address when the alert is generated.
• Anti-Spam Alerts, on page 1047
• Anti-Virus Alerts, on page 1048
• Directory Harvest Attack Prevention (DHAP) Alerts, on page 1048
• Hardware Alerts, on page 1049
• Spam Quarantine Alerts, on page 1050
• Safelist/Blocklist Alerts, on page 1051
• System Alerts, on page 1051
• Updater Alerts, on page 1062
• Outbreak Filter Alerts, on page 1063
• Clustering Alerts, on page 1063
Anti-Spam Alerts
The following table contains a list of the various anti-spam alerts that can be generated by AsyncOS, including
a description of the alert and the alert severity.
Table 95: Listing of Possible Anti-Spam Alerts
Alert Name Message and Description Parameters
AS.SERVER.ALERT $engine anti-spam - $message $tb ‘engine’ - The type of anti-spam engine.
Critical. Sent when the anti-spam engine fails. ’message’ - The log message.
’tb’ - Traceback of the event.
AS.TOOL.INFO_ALERT Update - $engine - $message ‘engine’ - The anti-spam engine name
Information. Sent when there is a problem with the ’message’ - The message
anti-spam engine.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1047
System Administration
Anti-Virus Alerts
Alert Name Message and Description Parameters
AS.TOOL.ALERT Update - $engine - $message ‘engine’ - The anti-spam engine name
Critical. Sent when an update is aborted due to a ’message’ - The message
problem with one of the tools used to manage the
anti-spam engine.
Anti-Virus Alerts
The following table contains a list of the various Anti-Virus alerts that can be generated by AsyncOS, including
a description of the alert and the alert severity.
Table 96: Listing of Possible Anti-Virus Alerts
Alert Name Message and Description Parameters
AV.SERVER.ALERT $engine antivirus - $message $tb ‘engine’ - The type of anti-virus engine.
/AV.SERVER.CRITICAL
Critical. Sent when there is a critical problem ’message’ - The log message.
with the anti-virus scanning engine. ’tb’ - Traceback of the event.
AV.SERVER.ALERT.INFO $engine antivirus - $message $tb ‘engine’ - The type of anti-virus engine.
Information. Sent when an informational event ’message’ - The log message.
occurs with the anti-virus scanning engine. ’tb’ - Traceback of the event.
AV.SERVER.ALERT.WARN $engine antivirus - $message $tb ‘engine’ - The type of anti-virus engine.
Warning. Sent when there is a problem with ’message’ - The log message.
the anti-virus scanning engine. ’tb’ - Traceback of the event.
MAIL.ANTIVIRUS.ERROR_MESSAGE MID $mid antivirus $what error $tag ‘mid’ - MID
Critical. Sent when anti-virus scanning ’what’ - The error that happened.
produces an error while scanning a message. ’tag’ - Virus outbreak name if set.
MAIL.SCANNER. MID $mid is malformed and cannot be scanned ‘mid’ - MID
by $engine.
PROTOCOL_MAX_RETRY ’engine’ - The engine being used
Critical. The scanning engine attempted to scan
the message unsuccessfully because the
message is malformed. The maximum number
of retries has been exceeded, and the message
will be processed without being scanned by
this engine.
Directory Harvest Attack Prevention (DHAP) Alerts
The following table contains a list of the various DHAP alerts that can be generated by AsyncOS, including
a description of the alert and the alert severity.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1048
System Administration
Hardware Alerts
Table 97: Listing of Possible Directory Harvest Attack Prevention Alerts
Alert Name Message and Description Parameters
LDAP.DHAP_ALERT LDAP: Potential Directory Harvest Attack detected.
See the system mail logs for more information
about this attack.
Warning. Sent when a possible directory harvest
attack is detected.
Hardware Alerts
The following table contains a list of the various Hardware alerts that can be generated by AsyncOS, including
a description of the alert and the alert severity.
Table 98: Listing of Possible Hardware Alerts
Alert Name Message and Description Parameters
INTERFACE.ERRORS Port $port: has detected $in_err input errors, $out_err ‘port’ - Interface name.
output errors, $col collisions please check your media
’in_err’ - The number of input
settings.
errors since the last message.
Warning. Sent when interface errors are detected. ’out_err’ - The number of output
errors since the last message.
’col’ - The number of packet
collisions since the last message.
MAIL.MEASUREMENTS_FILESYSTEM The $file_system partition is at $capacity% capacity ‘file_system’ - The name of the
filesystem
Warning. Sent when a disk partition is nearing
capacity (75%). ’capacity’ - How full the
filesystem is in percent.
MAIL.MEASUREMENTS_FILESYSTEM. The $file_system partition is at $capacity% capacity ‘file_system’ - The name of the
CRITICAL filesystem
Critical. Sent when a disk partition reaches 90%
capacity (and at 95%, 96%, 97%, etc.). ’capacity’ - How full the
filesystem is in percent.
SYSTEM.RAID_EVENT_ALERT A RAID-event has occurred: $error ‘error’ - The text of the RAID
error.
Warning. Sent when a critical RAID-event occurs.
SYSTEM.RAID_EVENT_ALERT_INFO A RAID-event has occurred: $error ‘error’ - The text of the RAID
error.
Information. Sent when a RAID-event occurs.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1049
System Administration
Spam Quarantine Alerts
Spam Quarantine Alerts
The following table contains a list of the various spam quarantine alerts that can be generated by AsyncOS,
including a description of the alert and the alert severity.
Table 99: Listing of Possible Spam Quarantine Alerts
Alert Name Message and Description Parameters
ISQ.CANNOT_CONNECT_OFF_BOX ISQ: Could not connect to off-box quarantine at $host:$port ‘host’ - address of off-box
quarantine
Information. Sent when AsyncOS was unable to connect to
the (off-box) IP address. ’port’ - port to connect to
on off-box quarantine
ISQ.CRITICAL ISQ: $msg ’msg’ - message to be
displayed
Critical. Sent when a critical spam quarantine error is
encountered.
ISQ.DB_APPROACHING_FULL ISQ: Database over $threshold% full ‘threshold’ - the percent
full threshold at which
Warning. Sent when the spam quarantine database is nearly alerting begins
full.
ISQ.DB_FULL ISQ: database is full
Critical. Sent when the spam quarantine database is full.
ISQ.MSG_DEL_FAILED ISQ: Failed to delete MID $mid for $rcpt: $reason ’mid’ - MID
Warning. Sent when an email is not successfully deleted from ’rcpt’ - Recipient or “all”
the spam quarantine. ’reason’ - Why the
message was not deleted
ISQ.MSG_NOTIFICATION_FAILED ISQ: Failed to send notification message: $reason ’reason’ - Why the
notification was not sent
Warning. Sent when a notification message is not successfully
sent.
ISQ.MSG_QUAR_FAILED Warning. Sent when a message is not successfully quarantined.
ISQ.MSG_RLS_FAILED ISQ: Failed to release MID $mid to $rcpt: $reason ‘mid’ - MID
Warning. Sent when a message is not successfully released. ’rcpt’ - Recipient or “all”
’reason’ - Why the
message was not released
ISQ.MSG_RLS_FAILED_UNK_RCPTS ISQ: Failed to release MID $mid: $reason ‘mid’ - MID
Warning. Sent when a message is not successfully released ’reason’ - Why the
because the recipient is unknown. message was not released
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1050
System Administration
Safelist/Blocklist Alerts
Alert Name Message and Description Parameters
ISQ.NO_EU_PROPS ISQ: Could not retrieve $user’s properties. Setting defaults ’user’ - end user name
Information. Sent when AsyncOS is unable to retrieve
information about a user.
ISQ.NO_OFF_BOX_HOST_SET ISQ: Setting up off-box ISQ without setting host
Information. Sent when AsyncOS is configured to reference
an external quarantine, but the external quarantine is not
defined.
Safelist/Blocklist Alerts
The following table contains a list of the various Safelist/Blocklist alerts that can be generated by AsyncOS,
including a description of the alert and the alert severity
Table 100: Listing of Possible Safelist/Blocklist Alerts
Alert Name Message and Description Parameters
SLBL.DB.RECOVERY_FAILED SLBL: Failed to recover End-User Safelist/Blocklist database: ’error’ - error reason
’$error’.
Critical. Failed to recover the Safelist/Blocklist database.
SLBL.DB.SPACE_LIMIT SLBL: End-User Safelist/Blocklist database exceeded allowed disk ’current’ - how much it has
space: $current of $limit. used, in MB
Critical. The safelist/blocklist database exceeded the allowed disk ’limit’ - the configured limit,
space. in MB
System Alerts
The following table contains a list of the various System alerts that can be generated by AsyncOS, including
a description of the alert and the alert severity.
Table 101: Listing of Possible System Alerts
Component/Alert Name Message and Description Parameters
AMP.ENGINE.ALERT See Ensuring That You Receive Alerts About -
Advanced Malware Protection Issues, on page 501
AsyncOS API Alerts See “Alerts” section in the AsyncOS API for Cisco -
Secure Email Gateway - Getting Started Guide .
Mailbox Auto Remediation Alerts See “Alerts” section in Remediating Messages in -
Mailboxes, on page 577
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1051
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
COMMON.APP_FAILURE An application fault occurred: $error ’error’ - The text of the error, typically a
traceback.
Warning. Sent when there is an unknown
application failure.
COMMON.ENGINE_AUTO_UPDATE_ <$level>: <$class> '$engine' - The name of the Service Engine.
ENABLED The values can be:
Information: Automatic updates have been enabled
for the particular engine <$engine>. You will now • Sophos
receive automatic engine updates for this engine. • McAfee
• Graymail
COMMON.ENGINE_AUTO_UPDATE_ <$level>: <$class> '$engine' - The name of the Service Engine.
DISABLED The values can be:
Information: Automatic updates have been disabled
for the particular engine <$engine>. You will not • Sophos
receive any automatic updates for this engine, • McAfee
unless you enable automatic updates in the global
setting page of the particular engine. • Graymail
COMMON.KEY_EXPIRED_ Your "$feature" key has expired. Please contact ’feature’ - The name of the feature that is
ALERT your authorized Cisco sales representative. about to expire.
Warning. Sent when a feature key has expired.
COMMON.KEY_EXPIRING_ Your "$feature" key will expire in under $days ’feature’ - The name of the feature that is
ALERT day(s). Please contact your authorized Cisco sales about to expire.
representative.
’days’ - The number of days it will expire.
Warning. Sent when a feature key is about to
expire.
COMMON.KEY_FINAL_EXPIRING_ This is a final notice. Your "$feature" key will ’feature’ - The name of the feature that is
ALERT expire in under $days day(s). Please contact your about to expire.
authorized Cisco sales representative.
’days’ - The number of days it will expire.
Warning. Sent as a final notice that a feature key
is about to expire.
KEYS.GRACE_EXPIRING_ All security services licenses for this email ’days’ - The number of days remaining in
ALERT gateway have expired. The email gateway will the grace period at the time the alert was
continue to deliver mail without security services sent.
for $days days.
For more information about the grace
To renew security services licenses, Please contact period, see Virtual Email Gateway License
your authorized Cisco sales representative. Expiration , on page 1017.
Critical. Sent periodically from the start of the
grace period for virtual email gateway license
expiration.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1052
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
KEYS.GRACE_FINAL_EXPIRING_ This is the final notice. All security services For more information about the grace
ALERT licenses for this email gateway have expired. The period, see Virtual Email Gateway License
email gateway will continue to deliver mail without Expiration , on page 1017.
security services for 1 day.
To renew security services licenses, Please contact
your authorized Cisco sales representative.
Critical. Sent one day before the virtual email
gateway license expires.
KEYS.GRACE_EXPIRED_ALERT Your grace period has expired. All security sevice For more information about the grace
have expired, and your email gateway is period, see Virtual Email Gateway License
non-functional. The email gateway will no longer Expiration , on page 1017.
deliver mail until a new license is applied.
To renew security services licenses, Please contact
your authorized Cisco sales representative.
Critical. Sent when the grace period for virtual
email gateway has expired.
DNS.BOOTSTRAP_FAILED Failed to bootstrap the DNS resolver. Unable to
contact root servers.
Warning. Sent when the email gateway is unable
to contact the root DNS servers.
COMMON.INVALID_FILTER Invalid $class: $error ‘class’ - Either "Filter", "SimpleFilter", etc.
Warning. Sent when an invalid filter is ’error’ - Additional why-filter-is-invalid
encountered. info.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1053
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
IPBLOCKD.HOST_ADDED_TO_ The host at $ip has been added to the blocked list ’ip’ - IP address from which a login attempt
ALLOWED_LIST because of an SSH DOS attack. occurred.
IPBLOCKD.HOST_ADDED_TO_ The host at $ip has been permanently added to the
BLOCKED_LIST ssh allowed list.
IPBLOCKD.HOST_REMOVED_ The host at $ip has been removed from the blocked
FROM_BLOCKED_LIST list.
Warning.
IP addresses that try to connect to the email
gateway over SSH but do not provide valid
credentials are added to the SSH blocked list if
more than 10 failed attempts occur within two
minutes.
When a user logs in successfully from the same
IP address, that IP address is added to the allowed
list.
Addresses on the allowed list. are allowed access
even if they are also on the blocked list.
Entries are automatically removed from the
blocked list after about a day.
LDAP.GROUP_QUERY_FAILED_ LDAP: Failed group query $name, comparison in ’name’ - The name of the query.
ALERT filter will evaluate as false
Critical. Sent when an LDAP group query fails.
LDAP.HARD_ERROR LDAP: work queue processing error in $name ’name’ - The name of the query.
reason $why
’why’ - Why the error happened.
Critical. Sent when an LDAP query fails
completely (after trying all servers).
LOG.ERROR.* Critical. Various logging errors.
MAIL.FILTER.RULE_MATCH_ MID $mid matched the $rule_name rule. \n ‘mid’ - Unique identification number of
ALERT Details: $details the message.
Information. Sent every time when a Header ‘rule_name’ - The name of the rule that
Repeats rule evaluates to true . matched.
‘details’ - More information about the
message or the rule.
MAIL.PERRCPT.LDAP_GROUP_ LDAP group query failure during per-recipient
QUERY_FAILED scanning, possible LDAP misconfiguration or
unreachable server.
Critical. Sent when an LDAP group query fails
during per-recipient scanning.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1054
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
MAIL.QUEUE.ERROR.* Critical. Various mail queue hard errors.
MAIL.OMH.DELIVERY_RETRY Subject - 'Alert: Message Delivery failed for ‘host’ - The host for which the DANE
$hostname. DANE verification failed for one or verification has failed.
more Domain(s).'
Message - The message delivery failed due to
DANE verification failure for all mail exchange
(MX) hosts in $hostname. The email gateway will
attempt message delivery again or bounce the
message.
MAIL.RES_CON_START_ This system (hostname: $hostname) has entered a ’hostname’ - The name of the host.
ALERT. MEMORY ‘resource conservation’ mode in order to prevent
’memory_threshold_start’ - The percent
the rapid depletion of critical system resources.
threshold where memory tarpitting starts.
RAM utilization for this system has exceeded the
resource conservation threshold of ’memory_threshold_halt’ - The percent
$memory_threshold_start%. The allowed receiving threshold where the system will halt due to
rate for this system will be gradually decreased as memory being too full.
RAM utilization approaches
$memory_threshold_halt%.
Critical. Sent when RAM utilization has exceeded
the system resource conservation threshold.
MAIL.RES_CON_START_ This system (hostname: $hostname) has entered a ’hostname’ - The name of the host.
ALERT. QUEUE_SLOW ‘resource conservation’ mode in order to prevent
the rapid depletion of critical system resources.
The queue is overloaded and is unable to maintain
the current throughput.
Critical. Sent when the mail queue is overloaded
and system resource conservation is enabled.
MAIL.RES_CON_START_ This system (hostname: $hostname) has entered a ‘hostname’ - The name of the host.
ALERT. QUEUE ‘resource conservation’ mode in order to prevent
‘queue_threshold_start’ - The percent
the rapid depletion of critical system resources.
threshold where queue tarpitting starts.
Queue utilization for this system has exceeded the
resource conservation threshold of ‘queue_threshold_halt’ - The percent
$queue_threshold_start%. The allowed receiving threshold where the system will halt due to
rate for this system will be gradually decreased as the queue being too full.
queue utilization approaches
$queue_threshold_halt%.
Critical. Sent when queue utilization has exceeded
the system resource conservation threshold.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1055
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
MAIL.RES_CON_START_ This system (hostname: $hostname) has entered a ‘hostname’ - The name of the host.
ALERT. WORKQ ‘resource conservation’ mode in order to prevent
‘suspend_threshold’ - Work queue size
the rapid depletion of critical system resources.
above which listeners are suspended.
Listeners have been suspended because the current
work queue size has exceeded the threshold of ‘resume_threshold’ - Work queue size
$suspend_threshold. Listeners will be resumed below which listeners are resumed.
once the work queue size has dropped to
$resume_threshold. These thresholds may be
altered via use of the ‘tarpit’ command on the
system CLI.
Information. Sent when listeners are suspended
because the work queue size is too big.
MAIL.RES_CON_START_ This system (hostname: $hostname) has entered a ‘hostname’ - The name of the host.
ALERT ‘resource conservation’ mode in order to prevent
the rapid depletion of critical system resources.
Critical. Sent when the email gateway enters
“resource conservation” mode.
MAIL.RES_CON_STOP_ALERT This system (hostname: $hostname) has exited ‘hostname’ - The name of the host.
‘resource conservation’ mode as resource
utilization has dropped below the conservation
threshold.
Information. Sent when the email gateway leaves
‘resource conservation’ mode.
MAIL.URL_REP_ See Future URL Category Set Changes , on page —
480.
CLIENT.CATEGORY_CHANGE
MAIL.BEAKER_ See Troubleshooting URL Filtering, on page 463.
CONNECTOR.CERTIFICATE_INVALID
MAIL.BEAKER_CONNECTOR.ERROR_
FETCHING_CERTIFICATE
MAIL.WORK_QUEUE_PAUSED_ work queue paused, $num msgs, $reason ‘num’ - The number of messages in the
NATURAL work queue.
Critical. Sent when the work queue is paused.
‘reason’ - The reason the work queue is
paused.
MAIL.WORK_QUEUE_UNPAUSED_ work queue resumed, $num msgs ‘num’ - The number of messages in the
NATURAL work queue.
Critical. Sent when the work queue is resumed.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1056
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
NTP.NOT_ROOT Not running as root, unable to adjust system time
Warning. Sent when the email gateway is unable
to adjust time because NTP is not running as root.
QUARANTINE.ADD_DB_ERROR Unable to quarantine MID $mid - quarantine ’mid’ - MID
system unavailable
Critical. Sent when a message cannot be sent to a
quarantine.
QUARANTINE.DB_UPDATE_ Unable to update quarantine database (current ’version’ - The schema version detected.
FAILED version: $version; target $target_version)
’target_version’ - The target schema
Critical. Sent when a quarantine database cannot version.
be updated.
QUARANTINE.DISK_SPACE_ The quarantine system is unavailable due to a lack ’file_system’ - The name of the filesystem.
LOW of space on the $file_system partition.
Critical. Sent when the disk space for quarantines
is full.
QUARANTINE.THRESHOLD_ Quarantine "$quarantine" is $full% full ’quarantine’ - The name of the quarantine.
ALERT
Warning. Sent when a quarantine reaches 5%, ’full’ - The percentage of how full the
50%, or 75% of capacity. quarantine is.
QUARANTINE.THRESHOLD_ Quarantine "$quarantine" is $full% full ’quarantine’ - The name of the quarantine.
ALERT.SERIOUS
Critical. Sent when a quarantine reaches 95% of ’full’ - The percentage of how full the
capacity. quarantine is.
REPORTD.DATABASE_OPEN_ The reporting system has encountered a critical ’err_msg’ - The error message raised
FAILED_ALERT error while opening the database. In order to
prevent disruption of other services, reporting has
been disabled on this machine. Please contact
customer support to have reporting enabled. The
error message is: $err_msg
Critical. Sent if the reporting engine is unable to
open the database.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1057
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
REPORTD.AGGREGATION_ Processing of collected reporting data has been ’threshold’ - The threshold value
DISABLED_ALERT disabled due to lack of logging disk space. Disk
usage is above $threshold percent. Recording of
reporting events will soon become limited and
reporting data may be lost if disk space is not freed
up (by removing old logs, etc.). Once disk usage
drops below $threshold percent, full processing of
reporting data will be restarted automatically.
Warning. Sent if the system runs out of disk space.
When the disk usage for a log entry exceeds the
log usage threshold, reportd disables aggregation
and sends the alert.
REPORTING.CLIENT.UPDATE_ Reporting Client: The reporting system has not ’duration’ - Length of time the client has
FAILED_ALERT responded for an extended period of time been trying to contact the reporting daemon.
($duration). This is a string in a human readable format
(’1h 3m 27s’).
Warning. Sent if the reporting engine was unable
to save reporting data.
REPORTING.CLIENT.JOURNAL. Reporting Client: The reporting system is unable
FULL to maintain the rate of data being generated. Any
new data generated will be lost.
Critical. Sent if the reporting engine is unable to
store new data.
REPORTING.CLIENT.JOURNAL. Reporting Client: The reporting system is now able
FREE to handle new data.
Information. Sent when the reporting engine is
again able to store new data.
PERIODIC_REPORTS.REPORT_ A failure occurred while building periodic report ‘report_title’ - the report title
TASK.BUILD_FAILURE ‘$report_title’. This subscription has been removed
from the scheduler.
Critical. Sent when the reporting engine is unable
to build a report.
PERIODIC_REPORTS.REPORT_ A failure occurred while emailing periodic report ’report_title’ - the report title
TASK.EMAIL_FAILURE ‘$report_title’. This subscription has been removed
from the scheduler.
Critical. Sent when a report could not be emailed.
PERIODIC_REPORTS.REPORT_ A failure occurred while archiving periodic report ’report_title’ - the report title
TASK.ARCHIVE_FAILURE ’$report_title’. This subscription has been removed
from the scheduler.
Critical. Sent when a report could not be archived.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1058
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
SENDERBASE.ERROR Error processing response to query $query: ’query’ - The query address.
response was $response
’response’ - Raw data of response received.
Information. Sent when an error occurred while
processing a response from SenderBase.
SMTPAUTH.FWD_SERVER_ SMTP Auth: could not reach forwarding server ’ip’ - The IP of the remote server.
FAILED_ ALERT $ip with reason: $why
’why’ - Why the error happened.
Warning. Sent when the SMTP Authentication
forwarding server is unreachable.
SMTPAUTH.LDAP_QUERY_ SMTP Auth: LDAP query failed, see LDAP debug
FAILED logs for details.
Warning. Sent when an LDAP query fails.
SYSTEM.HERMES_SHUTDOWN_ While preparing to ${what}, failed to stop mail ’error’ - The error that happened.
FAILURE. server gracefully: ${error}$what:=reboot
REBOOT Warning. Sent when there was a problem shutting
down the system on reboot.
SYSTEM.HERMES_SHUTDOWN_ While preparing to ${what}, failed to stop mail ’error’ - The error that happened.
FAILURE. server gracefully: ${error}$what:=shut down
SHUTDOWN Warning. Sent when there was a problem shutting
down the system.
SYSTEM.LOGIN_FAILURES_LOCK_ALERT User "$user" is locked after $numlogins 'user' - The name of the user
consecutive login failures. Last login attempt was
'numlogins' - The configured alert threshold
from $rhost
'rhost' - The address of the remote host
Information: Sent when the user account is locked
because of maximum number of failed login
attempts
SYSTEM.RCPTVALIDATION.UPDATE_ Error updating recipient validation data: $why ’why’ - The error message.
FAILED
Critical. Sent when a recipient validation update
failed.
SYSTEM.SERVICE_TUNNEL. Tech support: Service tunnel has been disabled
DISABLED
Information. Sent when a tunnel created for Cisco
Support Services is disabled.
SYSTEM.SERVICE_TUNNEL. Tech support: Service tunnel has been enabled, ’port’ - The port used for the service
ENABLED port $port tunnel.
Information. Sent when a tunnel created for Cisco
Support Services is enabled.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1059
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
IPBLOCKD.HOST_ADDED_TO_ The host at $ip has been added to the blocked list ’ip’ - IP address from which a login attempt
ALLOWED_LIST because of an SSH DOS attack. occurred.
IPBLOCKD.HOST_ADDED_TO_ The host at $ip has been permanently added to the
BLOCKED_LIST ssh allowed list.
IPBLOCKD.HOST_REMOVED_FROM_ The host at $ip has been removed from the blocked
BLOCKED_LIST list.
Warning.
IP addresses that try to connect to the email
gateway over SSH but do not provide valid
credentials are added to the SSH blocked list if
more than 10 failed attempts occur within two
minutes.
When a user logs in successfully from the same
IP address, that IP address is added to the allowed
list.
Addresses on the allowed list are allowed access
even if they are also on the blocked list .
Entries are automatically removed from the
blocked list after about a day.
WATCHDOG_RESTART_ALERT_ <$level>: <$class>, <$hostname>: $subject $text 'subject'- Watchdog alert subject specific
MSG to the engine
Warning.
'text' - Watchdog alert text specific to the
The email gateway uses the watchdog service to
engine
monitor the health condition of the following
engines:
• Anti-Spam
• Anti-Virus
• Anti Malware Protection
• Graymail
If any of the above engines does not respond to
the watchdog service for a certain duration, the
watchdog service restarts the engine(s) and sends
an alert to the administrator.
MAIL.IMH.GEODB_UPDATE_ Warning. Geolocation Update - the list of ’added’ - The following countries are
COUNTRIES' supported countries has changed. added: <iso_code1>:<country_nam
e1>,<iso_code2>:<country_name2>,
Added Countries - <$added>
’deleted’ - The following countries are
Deleted Countries - <$deleted>
deleted: <iso_code1>:<country_nam
Review your HAT sender groups, Message Filters, e1>:<iso_code2>:<country_name2>,
and Content Filters settings accordingly.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1060
System Administration
System Alerts
Component/Alert Name Message and Description Parameters
MAIL.UPDATED_SHORT_URL_DOMAIN_LIST Info. The list of shortened URL domains has been ’added_domains’: The following domains
updated.. are added: <domains_1>, <domain_2>
Added Domains: <$added_domains> ’deleted_domains’ : The following domains
are deleted: <domain_3>, <domain_4>
Deleted Domains - <$deleted_domains>
MAIL.DOMAINS_NOT_REACHABLE Warning. The following domains are not reachable <$domains>: comma separated list of
by the email gateway for shortened URL support: domains
<$domains>
Check your firewall rules to allow your email
gateway to connect to these domains.
MAIL.UPGRADE_CONFIG_CHANGE.ALERT Info. Sent when the user configured value is 'text' - The Intelligent Multi-Scan and the
changed by the system during the upgrade. Graymail global configuration settings have
been modified during the upgrade. Please
review the global settings for the Intelligent
Multi-Scan and the Graymail
configurations.
CERTIFICATE.CERT_EXPIRING Your certificate "$certificate" will expire in $days 'certificate', 'The name of the certificate
day(s). that is about to expire.
_ALERT
Alert level : WARNING 'days', 'The number of days it will expire.'
CERTIFICATE.CERT_CRITICAL_ Your certificate "$certificate" will expire in $days 'certificate', 'The name of the certificate
hour(s). that is about to expire.
EXPIRING_ALERT
Alert level : CRITICAL A ‘CRITICAL’ certificate 'days', 'The number of days with remaining
validity period is less than 5 days. time (HH:MM:SS), for example, 4 days
10:12:20 hour(s).'
CERTIFICATE.CERT_EXPIRED_ALERT Your certificate "$certificate" has expired. 'certificate', 'The name of the certificate
that has expired.
Alert level : CRITICAL
MAIL.APP.NO_ACCESS_KEY Alert text: 'Failed to poll for the Cisco Advanced N/A
Phishing Protection Cloud Service expiry date,
add API AccessUID and API Access secret key.'
Description: Alert is sent when a query for the
APP expiry date failed because the API Access
key and the secret key was not entered.
MAIL.APP.INVALID_KEY Alert text: Failed to poll for the Cisco Advanced N/A
Phishing Protection Cloud Service expiry date
because the API Access Key is invalid. You need
to re-configure the API Access UID and secret
key.
Description: Alert is sent when a query for the
APP expiry date failed because the API Access
key and the secret key was not entered.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1061
System Administration
Updater Alerts
Component/Alert Name Message and Description Parameters
MAIL.APP.EXPIRED Alert text: The Cisco Advanced Phishing N/A
Protection Cloud Service has expired and is
disabled. Contact your Cisco Account Manager to
renew the service and enable it.
Description: The Cisco Advanced Phishing
Protection Cloud Service has expired and is
disabled. You need to renew the APP license and
enable the APP service.
MAIL.APP.EXPIRY_REMINDER Alert text: Cisco Advanced Phishing Protection Parameters: eaas_expiry_date
Cloud Service expires on $eaas_expiry_date. You eaas_expiry_date - date on which Cisco
need to contact your Cisco Account Manager to Advanced Phishing Protection Cloud
renew the service. Service will expire
Description: Alert is sent each day, starting from
three days before the expiry period.
MAIL.APP.SERVICE_ Alert text: Cisco Advanced Phishing Protection N/A
Cloud Service update. Unable to establish
UNAVAILABLE
communication with the cloud service.
Description: 'APP cloud service is unavailable
because ten consecutive mails failed to forward to
APP.
MAIL.APP.SERVICE_ Alert text: Cisco Advanced Phishing Protection N/A
Cloud Service update. Communication with the
AVAILABLE
cloud service has been established.
Description: APP cloud service is available.
Updater Alerts
The following table contains a list of the varius Updater alerts that can be generated by AsyncOS.
Table 102: Listing of Possible Updater Alerts
Alert Name Message and Description Parameters
UPDATER.APP.UPDATE_ $app abandoning updates until a new version ‘app’ - The application name.
ABANDONED is published. The $app application tried and
‘attempts’ - The number of attempts tried.
failed $attempts times to successfully complete
an update. This may be due to a network
configuration issue or temporary outage
Warning. The application is abandoning the
update.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1062
System Administration
Outbreak Filter Alerts
Alert Name Message and Description Parameters
UPDATER.UPDATERD. The updater has been unable to communicate ‘threshold’ - Human readable threshold string.
ANIFEST_FAILED_ALERT with the update server for at least $threshold.
Warning. Failed to acquire a server manifest.
UPDATER.UPDATERD. $mail_text ‘mail_text’ - The notification text.
RELEASE_NOTIFICATION
Warning. Release notification. ‘notification_subject’ - The notification text.
UPDATER.UPDATERD. Unknown error occured: $traceback ‘traceback’ - The traceback.
UPDATE_FAILED
Critical. Failed to run an update.
Outbreak Filter Alerts
The following table contains a list of the various Outbreak Filter alerts that can be generated by AsyncOS,
including a description of the alert and the alert severity. Please note that Outbreak Filters can also be referenced
in system alerts for quarantines (the Outbreak quarantine, specifically).
Table 103: Listing of Possible Outbreak Filter Alerts
Alert Name Message and Description Parameters
VOF.GTL_THRESHOLD_ALERT Outbreak Filters Rule Update Alert:$text All rules last updated at: ’text’ - Update alert text.
$time on $date.
’time’ - Time of last update.
Information. Sent when the Outbreak Filters threshold has changed. ’date’ - Date of last update.
AS.UPDATE_FAILURE $engine update unsuccessful. This may be due to transient network ’engine’ - The engine that
or DNS issues, HTTP proxy configuration causing update failed to update.
transmission errors or unavailability of downloads.ironport.com.
’error’ - The error that
The specific error on the email gateway for this failure is: $error
happened.
Warning. Sent when the anti-spam engine or CASE rules fail to
update.
Clustering Alerts
The following table contains a list of the various clustering alerts that can be generated by AsyncOS, including
a description of the alert and the alert severity.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1063
System Administration
Clustering Alerts
Table 104: Listing of Possible Clustering Alerts
Alert Name Message and Description Parameters
CLUSTER.CC_ERROR. Error connecting to cluster machine $name at IP ’name’ - The hostname and/or serial
AUTH_ERROR $ip - $error - $why$error:=Machine does not number of the machine.
appear to be in the cluster
’ip’ - The IP of the remote host.
Critical. Sent when there was an authentication ’why’ - Detailed text about the error.
error. This can occur if a machine is not a
member of the cluster.
CLUSTER.CC_ERROR.DROPPED Error connecting to cluster machine $name at IP ’name’ - The hostname and/or serial
$ip - $error - $why$error:=Existing connection number of the machine.
dropped
’ip’ - The IP of the remote host.
Warning. Sent when the connection to the cluster ’why’ - Detailed text about the error.
was dropped.
CLUSTER.CC_ERROR.FAILED Error connecting to cluster machine $name at IP ’name’ - The hostname and/or serial
$ip - $error - $why$error:=Connection failure number of the machine.
Warning. Sent when the connection to the cluster ’ip’ - The IP of the remote host.
failed. ’why’ - Detailed text about the error.
CLUSTER.CC_ERROR. Error connecting to cluster machine $name at IP ’name’ - The hostname and/or serial
FORWARD_FAILED $ip - $error - $why$error:=Message forward number of the machine.
failed, no upstream connection
’ip’ - The IP of the remote host.
Critical. Sent when the email gateway was ’why’ - Detailed text about the error.
unable to forward data to a machine in the
cluster.
CLUSTER.CC_ERROR.NOROUTE Error connecting to cluster machine $name at IP ’name’ - The hostname and/or serial
$ip - $error - $why$error:=No route found number of the machine.
Critical. Sent when the machine was unable to ’ip’ - The IP of the remote host.
obtain a route to another machine in the cluster. ’why’ - Detailed text about the error.
CLUSTER.CC_ERROR.SSH_KEY Error connecting to cluster machine $name at IP ’name’ - The hostname and/or serial
$ip - $error - $why$error:=Invalid host key number of the machine.
Critical. Sent when there was an invalid SSH ’ip’ - The IP of the remote host.
host key. ’why’ - Detailed text about the error.
CLUSTER.CC_ERROR.TIMEOUT Error connecting to cluster machine $name at IP ’name’ - The hostname and/or serial
$ip - $error - $why$error:=Operation timed out number of the machine.
Warning. Sent when the specified operation ’ip’ - The IP of the remote host.
timed out. ’why’ - Detailed text about the error.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1064
System Administration
Clustering Alerts
Alert Name Message and Description Parameters
CLUSTER.CC_ERROR_NOIP Error connecting to cluster machine $name - ’name’ - The hostname and/or serial
$error - $why number of the machine.
Critical. Sent when the email gateway could not ’why’ - Detailed text about the error.
obtain a valid IP address for another machine in
the cluster.
CLUSTER.CC_ERROR_NOIP. Error connecting to cluster machine $name - ’name’ - The hostname and/or serial
AUTH_ERROR $error - $why$error:=Machine does not appear number of the machine.
to be in the cluster
’why’ - Detailed text about the error.
Critical. Sent when there was an authentication
error connecting to a machine in a cluster. This
can occur if a machine is not a member of the
cluster.
CLUSTER.CC_ERROR_NOIP. Error connecting to cluster machine $name - ’name’ - The hostname and/or serial
DROPPED $error - $why$error:=Existing connection number of the machine.
dropped
’why’ - Detailed text about the error.
Warning. Sent when the machine was unable to
obtain a valid IP address for another machine in
the cluster and the connection to the cluster was
dropped.
CLUSTER.CC_ERROR_NOIP. Error connecting to cluster machine $name - ’name’ - The hostname and/or serial
FAILED $error - $why$error:=Connection failure number of the machine.
Warning. Sent when there was an unknown ’why’ - Detailed text about the error.
connection failure and the machine was unable
to obtain a valid IP address for another machine
in the cluster.
CLUSTER.CC_ERROR_NOIP. Error connecting to cluster machine $name - ’name’ - The hostname and/or serial
FORWARD_FAILED $error - $why$error:=Message forward failed, number of the machine.
no upstream connection
’why’ - Detailed text about the error.
Critical. Sent when the machine was unable to
obtain a valid IP address for another machine in
the cluster and the email gateway was unable to
forward data to the machine.
CLUSTER.CC_ERROR_NOIP. Error connecting to cluster machine $name - ’name’ - The hostname and/or serial
NOROUTE $error - $why$error:=No route found number of the machine.
Critical. Sent when the machine was unable to ’why’ - Detailed text about the error.
obtain a valid IP address for another machine in
the cluster and it was unable to obtain a route to
the machine.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1065
System Administration
Changing Network Settings
Alert Name Message and Description Parameters
CLUSTER.CC_ERROR_NOIP. Error connecting to cluster machine $name - ’name’ - The hostname and/or serial
SSH_KEY $error - $why$error:=Invalid host key number of the machine.
Critical. Sent when the machine was unable to ’why’ - Detailed text about the error.
obtain a valid IP address for another machine in
the cluster and was unable to obtain a valid SSH
host key.
CLUSTER.CC_ERROR_NOIP. Error connecting to cluster machine $name - ’name’ - The hostname and/or serial
TIMEOUT $error - $why$error:=Operation timed out number of the machine.
Warning. Sent when the machine was unable to ’why’ - Detailed text about the error.
obtain a valid IP address for another machine in
the cluster and the specified operation timed out.
CLUSTER.SYNC.PUSH_ALERT Overwriting $sections on machine $name ’name’ - The hostname and/or serial
number of the machine.
Critical. Sent when configuration data has gotten
out of sync and has been sent to a remote host. ’sections’ - List of cluster sections being
sent.
Changing Network Settings
This section describes the features used to configure the network operation of the email gateway. These
features give you direct access to the hostname, DNS, and routing settings that you configured via the System
Setup Wizard (or the systemsetup command) in Using the System Setup Wizard , on page 38.
The following features are described:
• sethostname
• DNS Configuration (GUI and via the dnsconfig command)
• Routing Configuration (GUI and via the routeconfig and setgateway commands )
• dnsflush
• Passphrase
• Network Access
• Login Banner
Changing the System Hostname
The hostname is used to identify the system. You must enter a fully-qualified hostname. To change the
hostname:
• On the web interface, click Network> IP Interfaces, click the Management and in the Hostname, change
the hostname.
• On the CLI, use the s ethostname command.
Note The new hostname does not take effect until you commit changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1066
System Administration
Configuring Domain Name System (DNS) Settings
Configuring Domain Name System (DNS) Settings
You can configure the DNS settings for your email gateway through the DNS page on the Network menu of
the GUI, or via the d nsconfig command.
You can configure the following settings:
• whether to use the Internet’s DNS servers or your own, and which specific server(s) to use
• which interface to use for DNS traffic
• the number of seconds to wait before timing out a reverse DNS lookup
• clear DNS cache
Specifying DNS Servers
AsyncOS can use the Internet root DNS servers, your own DNS servers, or the Internet root DNS servers and
authoritative DNS servers you specify. When using the Internet root servers, you may specify alternate servers
to use for specific domains. Since an alternate DNS server applies to a single domain, it must be authoritative
(provide definitive DNS records) for that domain.
AsyncOS supports “splitting” DNS servers when not using the Internet’s DNS servers. If you are using your
own internal server, you can also specify exception domains and associated DNS servers.
When setting up “split DNS,” you should set up the in-addr.arpa (PTR) entries as well. So, for example, if
you want to redirect “.eng” queries to the nameserver 1.2.3.4 and all the .eng entries are in the 172.16 network,
then you should specify “eng,16.172.in-addr.arpa” as the domains in the split DNS configuration.
Multiple Entries and Priority
For each DNS server you enter, you can specify a numeric priority. AsyncOS will attempt to use the DNS
server with the priority closest to 0. If that DNS server is not responding AsyncOS will attempt to use the
server at the next priority. If you specify multiple entries for DNS servers with the same priority, the system
randomizes the list of DNS servers at that priority every time it performs a query. The system then waits a
short amount of time for the first query to expire or “time out” and then a slightly longer amount of time for
the second, etc. The amount of time depends on the exact total number of DNS servers and priorities that have
been configured. The timeout length is the same for all IP addresses at any particular priority. The first priority
gets the shortest timeout, each subsequent priority gets a longer timeout. Further, the timeout period is roughly
60 seconds. If you have one priority, the timeout for each server at that priority will be 60 seconds. If you
have two priorities, the timeout for each server at the first priority will be 15 seconds, and each server at the
second priority will be 45 seconds. For three priorities, the timeouts are 5, 10, 45.
For example, suppose you configure four DNS servers, with two of them at priority 0, one at priority 1, and
one at priority 2:
Table 105: Example of DNS Servers, Priorities, and Timeout Intervals
Priority Server(s) Timeout
(seconds)
0 1.2.3.4, 5, 5
1.2.3.5
1 1.2.3.6 10
2 1.2.3.7 45
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1067
System Administration
Using the Internet Root Servers
AsyncOS will randomly choose between the two servers at priority 0. If one of the priority 0 servers is down,
the other will be used. If both of the priority 0 servers are down, the priority 1 server (1.2.3.6) is used, and
then, finally, the priority 2 (1.2.3.7) server.
The timeout period is the same for both priority 0 servers, longer for the priority 1 server, and longer still for
the priority 2 server.
Using the Internet Root Servers
The AsyncOS DNS resolver is designed to accommodate the large number of simultaneous DNS connections
required for high-performance email delivery.
Note If you choose to set the default DNS server to something other than the Internet root servers, that server must
be able to recursively resolve queries for domains for which it is not an authoritative server.
Reverse DNS Lookup Timeout
The email gateway attempts to perform a “double DNS lookup” on all remote hosts connecting to a listener
for the purposes of sending or receiving email. [That is: the system acquires and verifies the validity of the
remote host's IP address by performing a double DNS lookup. This consists of a reverse DNS (PTR) lookup
on the IP address of the connecting host, followed by a forward DNS (A) lookup on the results of the PTR
lookup. The system then checks that the results of the A lookup match the results of the PTR lookup. If the
results do not match, or if an A record does not exist, the system only uses the IP address to match entries in
the Host Access Table (HAT).] This particular timeout period applies only to this lookup and is not related
to the general DNS timeout discussed in Multiple Entries and Priority, on page 1067.
The default value is 20 seconds for each DNS server. When there are multiple entries for DNS servers, the
total timeout value is (number of DNS servers multiplied by the Reverse DNS Lookup Timeout value) seconds.
For example, if there are 8 DNS servers and the Reverse DNS Lookup Timeout value is 20 seconds, the total
timeout value is (8 * 20) = 160 seconds.
You can disable the reverse DNS lookup timeout globally across all listeners by entering ‘0’ as the number
of seconds. If the value is set to 0 seconds, the reverse DNS lookup is not attempted, and instead the standard
timeout response is returned immediately. This also prevents the email gateway from delivering mail to
domains that require TLS-verified connections if the receiving host’s certificate has a common name (CN)
that maps to the host’s IP lookup.
DNS Alert
Occasionally, an alert may be generated with the message “Failed to bootstrap the DNS cache” when an email
gateway is rebooted. The messages means that the system was unable to contact its primary DNS servers,
which can happen at boot time if the DNS subsystem comes online before network connectivity is established.
If this message appears at other times, it could indicate network issues or that the DNS configuration is not
pointing to a valid server.
Clearing the DNS Cache
The Clear Cache button from the GUI, or the d nsflush command (for more information about the dnsflush
command, see the CLI Reference Guide for AsyncOS for Cisco Secure Email Gateway), clears all information
in the DNS cache. You may choose to use this feature when changes have been made to your local DNS
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1068
System Administration
Configuring DNS Settings via the Graphical User Interface
system. The command takes place immediately and may cause a temporary performance degradation while
the cache is repopulated.
Configuring DNS Settings via the Graphical User Interface
Procedure
Step 1 Select Network > DNS.
Step 2 Click Edit Settings.
Step 3 Select whether to use the Internet’s root DNS servers or your own internal DNS server or the Internet’s root
DNS servers and specify alternate DNS servers.
Step 4 If you want to use your own DNS server(s) enter the server ID and click Add Row. Repeat this for each server.
When entering your own DNS servers, specify a priority as well. For more information, see Specifying DNS
Servers, on page 1067.
Step 5 If you want to specify alternate DNS servers for certain domains, enter the domain and the alternate DNS
server IP address. Click Add Row to add additional domains.
Note You can enter multiple domains for a single DNS server by using commas to separate domain names.
You can also enter multiple DNS servers by using commas to separate IP addresses.
Step 6 Choose an interface for DNS traffic.
Step 7 Enter the number of seconds to wait before cancelling a reverse DNS lookup.
Step 8 You can also clear the DNS cache by clicking Clear Cache.
Step 9 Submit and commit your changes.
Configuring TCP/IP Traffic Routes
Some network environments require the use of traffic routes other than the standard default gateway.
The email gateway can use both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6)
static routes.
You can manage static routes via the CLI, using the routeconfig command, or use the following procedure.
Procedure
Step 1 Select Network > Routing.
Step 2 Click Add Route for the type of static route you want to create (IPv4 or IPv6).
Step 3 Enter a name for the route.
Step 4 Enter the destination IP address.
Step 5 Enter the Gateway IP address.
Step 6 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1069
System Administration
Configuring the Default Gateway
Configuring the Default Gateway
You can configure the default gateway using the setgateway command in the CLI or use the following
procedure.
Procedure
Step 1 Select Network > Routing.
Step 2 Click Default Route in the route listing for the Internet Protocol version you want to modify.
Step 3 Change the Gateway IP address.
Step 4 Submit and commit your changes.
Configuring SSL Settings
You can configure the SSL settings for the email gateway using SSL Configuration Settings page or sslconfig
command.
Procedure
Step 1 Click System Administration > SSL Configuration Settings.
Step 2 Click Edit Settings.
Important If you have upgraded from a lower AsyncOS version (for example, 12.0 or 12.1), the default SSL
ciphers are changed in AsyncOS 14.x and later as follows:
• For GUI HTTPS-
AES128:AES256:!SRP:!AESGCM+DH+aRSA:!AESGCM+RSA:
!aNULL:!kRSA:@STRENGTH:-aNULL:-EXPORT:-IDEA:!DHE-RSA-AES256-SHA
• For Inbound SMTP -
AES128:AES256:!SRP:!AESGCM+DH+aRSA:!AESGCM+RSA:
!aNULL:!kRSA:@STRENGTH:-aNULL:-EXPORT:-IDEA:!DHE-RSA-AES256-SHA
• For Outbound SMTP -
ECDH+aRSA:ECDH+ECDSA:DHE+DSS+AES:AES128:AES256:!SRP:
!AESGCM+DH+aRSA:!AESGCM+RSA:!aNULL:!eNULL:!kRSA:@STRENGTH:-aNULL:-EXPORT
:-IDEA:!DHE-RSA-AES256-SHA
Step 3 Depending on your requirements, do the following:
• Set GUI HTTPS SSL settings. Under GUI HTTPS, specify the SSL methods and ciphers that you want
to use.
• Set Inbound SMTP SSL settings. Under Inbound SMTP, specify the SSL methods and ciphers that you
want to use.
• Set Outbound SMTP SSL settings. Under Outbound SMTP, specify the SSL methods and ciphers that
you want to use.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1070
System Administration
Single Sign-On (SSO) Using SAML 2.0
• Set other TLS Client Services. Under 'Other TLS Client Services,' the TLS v1.0 method is disabled by
default if your email gateway is in the non-FIPS mode. You can enable the TLS v1.0 method on your
email gateway for the following TLS client services - 'LDAP' and 'Updater.'
Keep in mind that,
• [In non-FIPS mode] You cannot enable TLS v1.0 and v1.1 methods simultaneously. However, you can
enable these methods in conjunction with TLS v1.2 method.
• If you plan to upgrade from a lower AsyncOS version (for example, 12.x or 13.0) in non-FIPS mode
with TLS v1.0 enabled, to AsyncOS 13.5.1 and later, then TLS v1.0 is disabled by default. You need to
enable TLS v1.0 method on your email gateway after upgrade.
• From AsyncOS 13.5.1 and later, there is no support for SSLv2 and SSL v3 methods.
• There is no support for the TLS v1.0 method if your email gateway is in the FIPS mode.
• The TLS v1.0 method is disabled by default if your email gateway is in the non-FIPS mode.
Step 4 [Optional] Check the Enable check box to allow the email gateway to perform a FQDN validation on the
peer certificate for 'Alerts over TLS,' 'Outbound SMTP,' 'Updater,' and 'LDAP' server services.
Step 5 [Optional] Check the Enable check box to allow the email gateway to perform a X.509 validation on the peer
certificate for 'Alerts over TLS,' 'Outbound SMTP,' 'Updater,' and 'LDAP' server services.
Step 6 Click Submit.
Step 7 Click Commit Changes.
Single Sign-On (SSO) Using SAML 2.0
• About Single Sign-On (SSO) and SAML 2.0, on page 1071
• SAML 2.0 SSO Workflow, on page 1071
• Guidelines and Limitations for SAML 2.0, on page 1072
• How to Configure SSO on your Email Gateway, on page 1073
About Single Sign-On (SSO) and SAML 2.0
The email gateway now supports SAML 2.0 SSO so that the administrative users can log in to the web interface
of the email gateway using the same credentials that are used to access other SAML 2.0 SSO enabled services
within their organization. For instance, if you enable Duo, Microsoft AD FS or Azure as your SAML Identity
Provider (IdP), then you can configure your email gateway as a Service Provider (SP) to support SAML 2.0
SSO. Users can sign in once and have access to all SAML 2.0 SSO enabled services.
SAML 2.0 SSO Workflow
The SAML 2.0 SSO workflow is displayed in the following figure:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1071
System Administration
Guidelines and Limitations for SAML 2.0
Figure 75: SAML Workflow
Guidelines and Limitations for SAML 2.0
• General, on page 1072
• Logout, on page 1073
• Limitations, on page 1073
General
You can use Single Sign-On using SAML only on the graphical user interface (GUI). You can use the GUI
and the command line interface (CLI) to configure SAML profiles.
You can configure only one instance of service provider and identity provider on the email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1072
System Administration
Logout
Logout
When a user logs out of the email gateway, they are not logged out of other SAML 2.0 SSO enabled
applications.
Limitations
You cannot configure SAML profiles at cluster level. All SAML configurations are restricted to machine
level.
How to Configure SSO on your Email Gateway
Procedure
Command or Action Purpose
Step 1 Review the prerequisites. Prerequisites, on page 1073
Step 2 Configure your email gateway as a service Configuring Email Gateway as a Service
provider. Provider, on page 1074
Step 3 [On IDP] Configure the identity provider to Configuring the Identity Provider to
work with your email gateway. Communicate with Email Gateway, on page 1077
Step 4 Configure identity provider settings on your Configure Identity Provider Settings on Email
email gateway. Gateway, on page 1079
Step 5 Enable External Authentication using SAML Enable SAML Authentication, on page 995
on your email gateway.
Prerequisites
• Supported Identity Providers, on page 1073
• Certificates for Secure Communication, on page 1074
Supported Identity Providers
Verify whether the identity provider used by your organization is supported by the email gateway. The
following are the pre-qualified identity providers:
• Microsoft Active Directory Federation Services (AD FS) 2.0 and later
• Duo Access Gateway
• Azure AD
Note You can use any standard SAML 2.0 identity provider to configure SSO using SAML on your email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1073
System Administration
Certificates for Secure Communication
Certificates for Secure Communication
Obtain the following certificates that are required to secure the communication between your email gateway
and the identity provider:
• If you want your email gateway to sign SAML authentication requests or if want your identity provider
to encrypt SAML assertions, obtain a self-signed certificate or a certificate from a trusted CA and the
associated private key.
• If you want the identity provider to sign SAML assertions, obtain the identity provider’s certificate and
import the same to your email gateway. Your email gateway will use this certificate to verify the signed
SAML assertions.
Converting Certificates
To create and export certificates from your email gateway, see Working with Certificates, on page 676.
Normally, the certificates obtained from the email gateway are in .pfx format and must be converted to .pem
format when you configure your email gateway as a service provider.
To convert the certificates from .pfx format to .pem format, do the following:
• Download and install OpenSSL tool and import the certificate file (.pfx) obtained from your email
gateway.
• Run the following command to export the certificate in .pem format: openssl pkcs12 -in
<certname>.pfx -nokeys -out cert.pem
• Run the following command to export the private key in .pem format: openssl pkcs12 -in certname.pfx
-nocerts -out key.pem -nodes
• Run the following command to remove the passphrase from the private key: openssl rsa -in key.pem
-out server.key
Configuring Email Gateway as a Service Provider
Note The service provider settings on the identity provider is configured based on the service provider configurations
on the email gateway.
Before you begin
Make sure that you review the Prerequisites, on page 1073.
Procedure
Step 1 Log in to your email gateway using the web interface.
Step 2 Navigate to System Administration > SAML.
Step 3 Click Add Service Provider.
Step 4 Enter the following details:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1074
System Administration
Configuring Email Gateway as a Service Provider
Field Description
Profile Name Enter a name for the service provider profile.
Configuration Settings
Entity ID Enter a globally unique name for the service provider (in this case, your
email gateway). The format of the service provider Entity ID is typically
a URI.
Name ID Format The format that the identity provider should use to specify the user in the
SAML assertion.
This field is not configurable. You will need this value while configuring
the service provider settings on the identity provider.
Assertion Consumer URL Enter the URL to which the identity provider should send the SAML
assertion after authentication has successfully completed.
The Assertion Consumer URL is the URL that is used to access your email
gateway. You will need this value while configuring the service provider
settings on the identity provider.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1075
System Administration
Configuring Email Gateway as a Service Provider
Field Description
SP Certificate You can choose to import service provider certificates in any one of the
following ways:
• Select a signed certificate available on your email gateway, from the
drop-down list.
• Import a certificate and the associated private key. The certificate
must be in (.cert) format and the private key in (.key) format.
• Import a certificate in PKCS #12 file format. Password is mandatory
for PKCS #12 format certificates.
(Optional) Signing Authentication Requests
If you want the appliance to sign the SAML authentication requests:
a. Upload the certificate obtained from the email gateway and the
associated private key.
You must upload the certificate in (.cert) format. For more
information, see Certificates for Secure Communication, on page 1074.
b. Enter the passphrase for the private key.
c. Select Sign Requests.
(Optional) Decrypt Encrypted Assertions
If you plan to configure your identity provider to encrypt SAML assertions:
a. Upload the certificate obtained from the email gateway and the
associated private key.
b. Enter the passphrase for the private key.
Note The private key must be in .key format. For information on the
usage of certificates, see Certificates for Secure
Communication, on page 1074.
Sign Assertions If you want the identity provider to sign the SAML assertions, select Sign
Assertions.
If you select this option, you must add the identity provider’s certificate
to the email gateway. See Configure Identity Provider Settings on Email
Gateway, on page 1079.
Organization Details Enter the details of your organization. Identity provider uses this
information in the error logs.
Technical Contact Enter the email address of the technical contact. Identity provider uses
this information in the error logs.
Step 5 Click Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1076
System Administration
Configuring the Identity Provider to Communicate with Email Gateway
Step 6 Note down the service provider metadata (Entity ID and Assertion Customer URL) displayed on the SSO
Settings page and the Name ID Format displayed on the Service Provider Settings page. You will need these
details while configuring the service provider settings on the identity provider.
Optionally, you can export the metadata as a file. After you configure the settings, click Export Metadata
and save the metadata file. Some identity providers allow you to load service provider details from a metadata
file.
What to do next
Configure the identity provider to communicate with your email gateway. See Configuring the Identity Provider
to Communicate with Email Gateway, on page 1077.
Configuring the Identity Provider to Communicate with Email Gateway
Before you begin
Make sure that you have:
• Configured your email gateway as a service provider. See Configuring Email Gateway as a Service
Provider, on page 1074.
• Copied the service provider metadata details or exported the metadata file. See Configuring Email
Gateway as a Service Provider, on page 1074.
Procedure
Step 1 On the identity provider, do one of the following:
• Manually configure the details of the service provider (your email gateway).
• If your identity provider allows you to load the service provider details from a metadata file, import the
metadata file.
If you have configured your email gateway to sign the SAML authentication requests or you plan to encrypt
SAML assertions, make sure that you add the relevant certificate to the identity provider.
For identity provider-specific instructions, see:
• Configure AD FS to Communicate with Email Gateway, on page 1078.
• Configure Duo Access Gateway to Communicate with Email Gateway, on page 1078.
• Configure Azure AD to Communicate with Email Gateway, on page 1079.
Step 2 Note down the identity provider metadata or export the metadata as a file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1077
System Administration
Configure AD FS to Communicate with Email Gateway
What to do next
Configure the identity provider settings on your email gateway. See Configure Identity Provider Settings on
Email Gateway, on page 1079.
Configure AD FS to Communicate with Email Gateway
The following are the high level tasks you need to perform to configure AD FS (2.0 and later) to communicate
with your email gateway. For complete and detailed instructions, see Microsoft documentation.
• Add the service provider’s ( email gateway's) Assertion Consumer URL as a relaying party.
• Enter the service provider’s ( email gateway's) Entity ID under Relaying Party Trusts > Properties >
Identifiers > Relaying Party Identifier. Make sure that this value is same as the Entity ID value in the
Service Provider settings on your email gateway.
• If you have configured your service provider (appliance) to send signed SAML authentication requests,
upload the service provider’s certificate (used to sign authentication requests) in .cer format under
Relaying Party Trusts > Properties > Signature.
• If you plan to configure AD FS to send encrypted SAML assertions, upload the service provider’s ( email
gateway's) certificate in .cer format under Relaying Party Trusts > Properties > Encryption.
• Set the Secure-hash Algorithm to SHA-1 under Relaying Party Trusts > Properties > Advanced.
• Add a custom rule to include SPNameQualifier in the response. The following is a sample custom rule:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] =>
issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
Issuer=
c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =
"urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
Properties ["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =
"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");
• Edit the Claim Rule and add an Issuance Transform Rule to send the LDAP attribute for email address
as an outgoing claim type (email address). Also ensure that you add an Issuance Transform Rule to send
the LDAP attribute for group attribute as an outgoing claim type (unspecified groups).
Configure Duo Access Gateway to Communicate with Email Gateway
The following are the high level tasks you need to perform to Duo Access Gateway to communicate with
your email gateway. For complete and detailed instructions, see Duo Security Documentation.
• Add the service provider’s ( email gateway's) Assertion Consumer URL as the service provider endpoint
that receives and processes SAML assertions.
• Enter the service provider’s ( email gateway's) Entity ID under Duo Admin Panel > Applications >
Protect an Application > SAML Service Provider. Make sure that this value is same as the Entity ID
value in the Service Provider settings on your email gateway.
• If you have configured your service provider ( email gateway) to send signed SAML authentication
requests, upload the service provider’s certificate (used to sign authentication requests) in .cer format
when you configure the authentication source on the Duo Access Gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1078
System Administration
Configure Azure AD to Communicate with Email Gateway
• If you plan to configure Duo to send encrypted SAML assertions, upload the service provider’s ( email
gateway's) certificate in .cer format when you configure the authentication source on the Duo Access
Gateway.
• Select the NameID format as “unspecified” under Duo Admin Panel > Applications > Protect an
Application > SAML Service Provider > SAML Response.
• Set the Secure-hash Algorithm to SHA-256 under Duo Admin Panel > Applications > Protect an
Application > SAML Service Provider > SAML Response.
• Save the SAML - Service Provider Setting as a configuration file on the Duo Admin Panel and import
the configuration file as a SAML application on the Duo Access Gateway.
Configure Azure AD to Communicate with Email Gateway
The following are the high level tasks you need to perform to Azure AD to communicate with your email
gateway. For complete and detailed instructions, see Microsoft Azure AD Documentation.
• Add the service provider’s ( email gateway's) Assertion Consumer URL as the service provider identifier
that receives and processes SAML assertions.
• Enter the service provider’s (email gateway's) Entity ID in the Azure Portal under Enterprise Application
> New Application > Non-gallery application > Single Sign-On > Basic SAML Configuration. Make
sure that this value is same as the Entity ID value in the Service Provider settings on your email gateway.
• If you have configured your service provider ( email gateway) to send signed SAML authentication
requests, upload the service provider’s certificate (used to sign authentication requests) under SAML
Signing Certificate section (Enterprise Application > New Application > Non-gallery application > Single
Sign-On > SAML Signing Certificate).
• Configure a Group Claim under User Attributes and Claims section (Enterprise Application > New
Application > Non-gallery application > Single Sign-On > User Attributes and Claims) and add the group
attribute.
• Add users and/or groups under Azure Application created for SAML > Users & Groups to control users
who can login to this Azure SAML application..
Configure Identity Provider Settings on Email Gateway
Before you begin
Make sure that you have:
• Configured the identity provider to communicate with your email gateway. See Configuring the Identity
Provider to Communicate with Email Gateway, on page 1077.
• Copied the identity provider metadata details or exported the identity provider metadata as file.
Procedure
Step 1 Log in to your email gateway on the web interface.
Step 2 Navigate to System Administration > SAML.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1079
System Administration
Configuring OpenID Connect 1.0 on Email Gateway for AsyncOS APIs
Step 3 Click Add Identity Provider.
Step 4 Enter the following details:
Field Description
Profile Name Enter a name for the identity provider profile.
Configuration Settings (Manually Configure Identity Provider Settings)
Entity ID Enter a globally unique name for the identity provider. The format of
the identity provider Entity ID is typically a URI.
SSO URL Specify the URL to which the service provider must send the SAML
authentication requests.
Certificate If the identity provider signs the SAML assertion, you must upload
the identity provider’s signing certificate.
Configuration Settings (Importing Identity Provider Metadata)
Import IDP Metadata Click Import Metadata and select the metadata file.
Step 5 Submit and commit your changes.
What to do next
Enable SAML Authentication, on page 995.
Configuring OpenID Connect 1.0 on Email Gateway for AsyncOS
APIs
• Overview, on page 1080
• Workflow, on page 1081
• Sample Access Token, on page 1081
• Prerequisites , on page 1082
• Configuring OpenID Connect on Email Gateway, on page 1082
Overview
The Cisco Secure Email Gateway supports integration with applications or clients that use Identity Providers
(IDPs) with OpenID Connect 1.0 authentication to connect seamlessly with AsyncOS APIs available in your
email gateway. Currently, your email gateway has been certified with OpenID Connect using Microsoft AD
FS only.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1080
System Administration
Workflow
Workflow
In the following workflow, AD FS is used as an identity provider, external application as a client, and your
email gateway as a resource provider.
Steps:
1. [One-time activity] Configure yor email gateway to validate the access token. For more information, see
Configuring OpenID Connect on Email Gateway, on page 1082.
2. [One-time activity] The email gateway fetches the OpenID Connect configuration metadata and the
required keys to validate the access token based on the configuration done in step1.
3. Obtain the access token after you authenticate the external application with AD FS. For more information
on how to authenticate and receive the access token, see your Authentication Provider or Identity Provider
documentation.
4. Send the API request along with the access token to the email gateway.
5. The email gateway validates the access token in the API request using the key set retrieved from step2.
6. The email gateway validates the required claim (issuer, audience) in the access token.
7. The email gateway uses the role claim value to authorize and allocate the user role privileges to access
the AsyncOS APIs.
8. The email gateway provides an appropriate response for the AsyncOS API request.
Sample Access Token
The following is the format of a sample access token:
Header
alg:RSA256
typ:JWT
[...]
Payload
claim: aud: CiscoEmailAPICaller
claim: iss: http://adfsserver/adfs/services/trust
claim: iat: 1594712147
claim: exp: 1594712807
claim: CustomOrgIdentifier: MyCustomOrgId
claim: LastName: Fernandes
claim: FirstName: Erik
claim: Email: [email protected]
claim: Role: LogCollector
claim: Role: ReadOnly
[...]
The email gateway supports the validation of access tokens signed by the following algorithms only:
• RSA256
• RSA384
• RSA512
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1081
System Administration
Prerequisites
Prerequisites
Make sure that you have met the following prerequisites before you configure your email gateway with OpenID
Connect:
• The authentication provider used by your organization is supported by the email gateway.
• The application can authenticate with the authentication provider and retrieve the access token.
• The email gateway can connect to the authentication provider over HTTPs to fetch the OpenID Connect
metadata configuration.
Configuring OpenID Connect on Email Gateway
Before you begin
Make sure that you have the following:
• A valid access token issued by the authentication provider (based on your authentication provider setup).
• The access token must include the role information to allow the email gateway to perform the required
authorization checks.
Procedure
Step 1 Click System Administration > OpenID Connect.
Step 2 Click Edit Settings.
Step 3 Enter the required parameters described in the following table to configure OpenID Connect:
OpenID Connect Parameters Description
Identity Provider Metadata URL Enter the identity provider URL used to fetch the
Open ID Connect configuration metadata. The
metadata is used to validate the access token.
The following is an example of an identity provider
URL -
https://example.com/adfs/.well-known/openid-configuration.
Issuer Enter the value of the issuer of the access token.
Note The value must match the issuer claim
value of the access token when validating
the access token.
The following is an example of an issuer -
http://example.com/adfs/services/trust.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1082
System Administration
System Time
OpenID Connect Parameters Description
Audience Enter the value of the audience that must match the
audience claim value of the access token.
Note Click Add Row if you want to add more
than one audience value.
Claim Name Enter the name of the claim in the access token, which
contains the user role information. The claim name
is used to retrieve the role information from the access
token.
Identity Provider to Appliance Role Mapping Enter a user group role defined in the Identity Provider
Server and choose a corresponding local user role
configured in the email gateway to map both roles.
Note Click Add Row if you want to add more
than one role mapping record.
Step 4 Submit and commit your changes.
What to do next
Include the access token in the Authorization Bearer header of the AsyncOS API call and send the API request.
The following is an example of invoking an AsynOS API with the access token in the Authorization Bearer
header of the API.
curl --location --request
GET 'https://esa.com/esa/api/v2.0/config/logs/subscriptions?retrievalMethod=manual'
--header 'Authorization: Bearer <add access_token here>’
System Time
To set the System Time on your email gateway, set the Time Zone used, or select an NTP server and query
interface, use the Time Zone or Time Settings page from the System Administration menu in the GUI or use
the following commands in the CLI: ntpconfig , settime , and settz .
You can also verify the time zone files used by AsyncOS on the System Administration > Time Settings
page or using the tzupdate CLI command.
Selecting a Time Zone
The Time Zone page (available via the System Administration menu in the GUI) displays the time zone for
your email gateway. You can select a specific time zone or GMT offset.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1083
System Administration
Selecting a GMT Offset
Procedure
Step 1 Click Edit Settings on the System Administration > Time Zone page.
Step 2 Select a Region, country, and time zone from the pull-down menus.
Step 3 Submit and commit your changes.
Selecting a GMT Offset
Procedure
Step 1 Click Edit Settings on the System Administration > Time Zone page.
Step 2 Select GMT Offset from the list of regions.
Step 3 Select an offset in the Time Zone list. The offset refers to the amount of hours that must be added/subtracted
in order to reach GMT (the Prime Meridian). Hours preceded by a minus sign (“-”) are east of the Prime
Meridian. A plus sign (“+”) indicates west of the Prime Meridian.
Step 4 Submit and commit your changes.
Editing Time Settings
You can edit the time settings for the email gateway using one of the following methods:
• (Recommended) Setting Email Gateway System Time Using the Network Time Protocol (NTP), on page
1084
• Setting Email Gateway System Time Manually , on page 1085
(Recommended) Setting Email Gateway System Time Using the Network Time Protocol (NTP)
This is the recommended time keeping method, especially if your email gateway is integrated with other
devices. All integrated devices should use the same NTP server.
Procedure
Step 1 Navigate to the System Administration > Time Settings page.
Step 2 Click Edit Settings.
Step 3 In the Time Keeping Method section, select Use Network Time Protocol.
Step 4 Enter an NTP server address and click Add Row. You can add multiple NTP servers.
Step 5 To delete an NTP server from the list, click the trash can icon for that server.
Step 6 Select an interface for NTP queries. This is the IP address from which NTP queries should originate.
Step 7 Submit and commit your changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1084
System Administration
Setting Email Gateway System Time Manually
Setting Email Gateway System Time Manually
This time keeping method is generally not recommended. Use a Network Time Protocol server instead.
Procedure
Step 1 Navigate to the System Administration > Time Settings page.
Step 2 Click Edit Settings.
Step 3 In the Time Keeping Method section, select Set Time Manually.
Step 4 Enter the month, day, year, hour, minutes, and seconds.
Step 5 Select A.M or P.M.
Step 6 Submit and commit your changes.
Customizing Your View
• Using Favorite Pages , on page 1085
• Setting User Preferences, on page 1085
Using Favorite Pages
(Locally-authenticated administrative users only.) You can create a quick-access list of the pages you use
most.
To Do This
Add pages to your favorites list Navigate to the page to add, then choose Add This Page To My
Favorites from the My Favorites menu near the top right corner
of the window.
No commit is necessary for changes to My Favorites.
Reorder favorites Choose My Favorites > View All My Favorites and drag favorites
into the desired order.
Delete favorites Choose My Favorites > View All My Favorites and delete
favorites.
Go to a favorite page Choose a page from the My Favorites menu near the top right
corner of the window.
View or build a custom reporting page See My Dashboard Page , on page 837.
Setting User Preferences
Local users can define preference settings, such as language, specific to each account. These settings apply
by default when the user first logs into the email gateway. The preference settings are stored for each user
and are the same regardless from which client machine the user logs into the email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1085
System Administration
General Settings
When users change these settings but do not commit the changes, the settings revert to the default values when
they log in again.
Note This feature is not available to externally-authenticated users. These users can choose a language directly
from the Options menu.
Procedure
Step 1 Log into the appliance with the user account for which you want to define preference settings.
Step 2 Choose Options > Preferences. The options menu is at the top right side of the window.
Step 3 Click Edit Preferences.
Step 4 Configure settings:
Preference Setting Description
Language Display The language AsyncOS for Web uses in the web interface and
CLI.
Landing Page The page that displays when the user logs into the email
gateway.
Reporting Time Range Displayed (default) The default time range that displays for reports on the
Reporting tab.
Number of Reporting Rows Displayed The number of rows of data shown for each report by default.
Step 5 Submit and commit your changes.
Step 6 Click the Return to previous page link at the bottom of the page.
General Settings
You can edit the following general settings for the email gateway:
• Overriding Internet Explorer Compatibility Mode, on page 1086
• Collecting Usage Statistics of the Email Gateway on the New Web Interface , on page 1087
Overriding Internet Explorer Compatibility Mode
For better web interface rendering, Cisco recommends that you enable Internet Explorer Compatibility Mode
Override.
Note If enabling this feature is against your organizational policy, you may disable this feature.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1086
System Administration
Collecting Usage Statistics of the Email Gateway on the New Web Interface
Procedure
Step 1 Click System Administration > General Settings.
Step 2 Select Override IE Compatibility Mode check box.
Step 3 Submit and commit your changes.
Collecting Usage Statistics of the Email Gateway on the New Web Interface
Usage Analytics is used to provide insight into your site activity data for analytical statistics. If Usage Analytics
is enabled, the email gateway collects the feature usage data of the email gateway on the new web interface.
The usage statistics are used to analyze and provide insight to improve the user experience of the email
gateway.
Usage Analytics is enabled on the email gateway by default. If you want to disable Usage Analytics, do the
following:
Procedure
Step 1 Click System Administration > General Settings.
Step 2 Clear the Usage Analytics check box.
Step 3 Submit and commit your changes.
Configuring Maximum HTTP Header Size
You can now use the adminaccessconfig > maxhttpheaderfieldsize command in the CLI to configure
the maximum HTTP header size of an HTTP request sent to the email gateway.
The default value for the HTTP header field size is 4096 (4 KB) and the maximum value is 33554432 (32
MB).
Restarting and Viewing Status of Service Engines
You can use the diagnostic > servicessub command in the CLI to:
• Restart the service engines enabled on your email gateway without having to reboot your email gateway.
• View the status of service engines enabled on your email gateway.
For more information, refer to the CLI Reference Guide for Cisco Secure Email Gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1087
System Administration
Receiving and Delivering Messages with Internationalised Domain Names (IDNs)
Receiving and Delivering Messages with Internationalised
Domain Names (IDNs)
The email gateway can receive and deliver messages with email addresses that contain IDN domains.
Currently, your email gateway provides support of IDN domains for the following languages only:
Indian Regional Languages: Hindi, Tamil, Telugu, Kannada, Marati, Punjabi, Malayalam, Bengali, Gujarati,
Urdu, Assamese, Nepali, Bangla, Bodo, Dogri, Kashmiri, Konkani, Maithili, Manipuri, Oriya, Sanskrit, Santali,
Sindhi, and Tulu.
European and Asian Languages: French, Russian, Japanese, German, Ukrainian, Korean, Spanish, Italian,
Chinese, Dutch, Thai, Arabic, and Kazakh.
Related Topics:
• Prerequisites, on page 1088
• Features Configurable using IDN Domains in Email Gateway, on page 1088
Prerequisites
Make sure you have met the following prerequisites before you use the Internationalised Domain Names
(IDN) feature:
• All incoming messages must have IDNs encoded in UTF-8.
For Example: An MTA that sends messages to the email gateway must support IDNs and make sure the
domains in the messages are in the UTF-8 format.
• All outgoing messages must have IDNs encoded in UTF-8, and the destination server must accept and
support IDNs accordingly.
For Example: An MTA that accepts messages from the email gateway must support IDNs and domains
encoded in the UTF-8 format.
• In all applicable DNS records, IDNs must be configured using the Punycode format
For Example: When you configure an MX record for an IDN, the domain in the DNS record must be in
the Punycode format.
Features Configurable using IDN Domains in Email Gateway
For this release, you can only configure the following features using IDN domains in your email gateway:
• SMTP Routes Configuration Settings:
• Add or edit IDN domains.
• Export or import SMTP routes using IDN domains.
• DNS Configuration Settings: Add or edit the DNS server using IDN domains.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1088
System Administration
Features Configurable using IDN Domains in Email Gateway
• Listener Configuration Settings:
• Add or edit IDN domains for the default domain in inbound or outbound listeners.
• Add or edit IDN domains in the HAT or RAT tables.
• Export or import HAT or RAT tables using IDN domains.
• Mail Policies Configuration Settings
• Add or edit domains using IDN domains for senders (’Following Senders’ or ’Following Senders
are not’options) and recipients (’Following Recipients’ or ’Recipients are not’options) in Incoming
Mail Policies.
• Add or edit domains using IDN domains for senders (’Following Senders’ or ’Following Senders
are not’options) and recipients (’Following Recipients’ or ’Recipients are not’options) in Outgoing
Mail Policies.
• Find senders or recipients using IDN domains in Incoming or Outgoing Mail Policies.
• Define Sender Verification Exception table using IDN domains.
• Create an address list using IDN domains.
• Add or edit the destination domain using IDN domains for destination controls.
• Bounce Profiles Configuration Settings: Add or edit the alternate email address using IDN domains.
• Sender Domain Reputation Configuration Settings: Define sender domain reputation scores for IDN
domains.
• IP Reputation Configuration Settings: Define IP reputation scores for IDN domains.
• LDAP Configuration Settings: Create LDAP group queries, accept queries, routing queries, and
masquerade queries for incoming and outgoing messages using IDN domains.
• Reporting Configuration Settings: View IDN data - usernames, email addresses, and domains) in the
reports.
• Message Tracking Configuration Settings: View IDN data- usernames, email addresses, and domains)
in message tracking.
• Policy, Virus, and Outbreak Quarantine Configuration Settings:
• View messages with IDN domains that may be transmitting malware, as determined by the anti-virus
engine.
• View messages with IDN domains caught by Outbreak Filters as potentially being spam or malware.
• View messages with IDN domains caught by message filters, content filters, and DLP message
actions.
• Spam Quarantine Configuration Settings:
• View messages with IDN domains detected as spam or suspected spam.
• Add email addresses with IDN domains to the safelist and blocklist categories.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1089
System Administration
Features Configurable using IDN Domains in Email Gateway
Note Currently, recipients with IDN domains can access the End-User Quarantine only
if the end-user authentication method is set to 'None' under the 'End-User
Quarantine Access' section in the 'Spam Quarantine' settings page.
• SPF Configuration Settings: Perform SPF verification of messages using IDN domains.
• DKIM Configuration Settings: Perform DKIM signing and verification of messages using IDN domains
• DMARC Configuration Settings: Perform DMARC verification of messages using IDN domains.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1090
CHAPTER 40
Managing and Monitoring Using the CLI
This chapter contains the following sections:
• Overview of Managing and Monitoring Using the CLI, on page 1091
• Reading the Available Components of Monitoring, on page 1092
• Monitoring Using the CLI, on page 1097
• Managing the Email Queue, on page 1107
• Monitoring System Health and Status Using SNMP, on page 1116
Overview of Managing and Monitoring Using the CLI
Managing and monitoring the email gateway using the CLI includes these types of tasks:
• Monitoring message activity.
• The raw number of messages, recipients, and bounce recipients that the email gateway is processing
in the email pipeline
• The hourly rate of message delivery or message bounces based on the last one-minute, five-minute,
or fifteen-minute period
• Monitoring system resources. Examples:
• Memory usage
• Disk space
• Number of connections
• Monitoring possible system disfunction using the Simple Network Management Protocol (SNMP).
Examples:
• Fan failure
• Update failure
• Abnormally high email gateway temperature
• Managing email within the pipeline. Examples:
• Deleting recipients in the queue
• Redirecting messages to another host
• Clear the queue by deleting recipients or redirecting the messages
• Suspend or resume email receiving, delivery, or work queue processing
• Locate specific messages
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1091
Managing and Monitoring Using the CLI
Reading the Available Components of Monitoring
Reading the Available Components of Monitoring
• Reading the Event Counters, on page 1092
• Reading the System Gauges, on page 1094
• Reading the Rates of Delivered and Bounced Messages, on page 1096
Reading the Event Counters
Counters provide a running total of various events in the system. For each counter, you can view the total
number of events that have occurred since the counter was reset, since the last system reboot, and over the
system’s lifetime.
Counters increment each time an event occurs and are displayed in three versions:
Reset Since the last counter reset with the resetcounters command
Uptime Since the last system reboot
Lifetime Total through the lifetime of the email gateway
The following table lists the available counters and their description when monitoring the email gateway.
Note This is the entire list. The displayed counters vary depending on which display option or command you choose.
Use this list as a reference.
Table 106: Counters
Statistic Description
Receiving
Messages Received Messages received into the delivery queue.
Recipients Received Recipients on all received messages.
Generated Bounce Recipients Recipients for which bounces have been generated by the system
and inserted into the delivery queue.
Rejection
Rejected Recipients Recipients that have been denied receiving into the delivery
queue due to the Recipient Access Table (RAT), or unexpected
protocol negotiation including premature connection termination.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1092
Managing and Monitoring Using the CLI
Reading the Event Counters
Statistic Description
Dropped Messages Messages that have been denied receiving into the delivery queue
due to a filter drop action match or have been received by a
Sinkhole queuing listener. Messages directed to /dev/null entries
in the alias table also are considered dropped messages. Messages
dropped by anti-spam filtering (if it has been enabled on the
system) also increment this counter.
Queue
Soft Bounced Events Number of soft bounce events — a message that soft bounces
multiple times has multiple soft bounce events.
Completion
Completed Recipients Total of all hard bounced recipients, delivered recipients, and
deleted recipients. Any recipient that is removed from the
delivery queue.
Hard Bounced Recipients Total of all DNS hard bounces, 5XX hard bounces, filter hard
bounces, expired hard bounces and other hard bounces. A failed
attempt to deliver message to a recipient that results in immediate
termination of that delivery.
DNS Hard Bounces DNS error encountered while trying to deliver a message to a
recipient.
5XX Hard Bounces The destination mail server returned a “5XX” response code
while trying to deliver a message to a recipient.
Expired Hard Bounces Message recipients that have exceeded the maximum time
allowed in the delivery queue or the maximum number of
connection attempts.
Filter Hard Bounces Recipient delivery has been preempted by a matching filter
bounce action. Messages dropped by anti-spam filtering (if it
has been enabled on the system) also increment this counter.
Other Hard Bounces An unexpected error during message delivery or a message
recipient was explicitly bounced via the bouncerecipients
command.
Delivered Recipients Message successfully delivered to a recipient.
Deleted Recipients Total of message recipients explicitly deleted via the
deleterecipients command or was a Global Unsubscribe Hit.
Global Unsubscribe Hits Message recipient was deleted due to a matching global
unsubscribe setting.
Current IDs
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1093
Managing and Monitoring Using the CLI
Reading the System Gauges
Statistic Description
Message ID (MID) The last Message ID to have been assigned to a message inserted
into the delivery queue. A MID is associated with every message
received by the email gateway and can be tracked in mail logs.
The MID resets to zero at 231.
Injection Connection ID (ICID) The last Injection Connection ID to have been assigned to a
connection to a listener interface. The ICID rolls over (resets to
zero) at 231.
Delivery Connection ID (DCID) The last Delivery Connection ID to have been assigned to a
connection to a destination mail server. The DCID rolls over
(resets to zero) at 231.
Reading the System Gauges
Gauges show the current utilization of a system resource such as memory, disk space, or active connections.
The following table lists the available gauges and their description when monitoring the email gateway.
Note This is the entire list. The displayed gauges will vary depending upon which display option or command you
choose. Use this list as a reference.
Table 107: Gauges
Statistic Description
System Gauges
RAM Utilization Percentage of physical RAM (Random Access Memory) being used
by the system.
CPU Utilization Percentage of CPU usage.
Disk I/O Utilization Percentage of Disk I/O being used.
Note The Disk I/O Utilization gauge does not display a reading
against a scale of a known value. Rather, it displays the
I/O utilization the system has seen thus far and scales
against the maximum value since the last reboot. So, if the
gauge displays 100%, the system is experiencing the
highest level of I/O utilization seen since boot (which may
not necessarily represent 100% of the physical Disk I/O of
the entire system).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1094
Managing and Monitoring Using the CLI
Reading the System Gauges
Statistic Description
Resource Conservation A value between 0 and 60 or 999 . Numbers from 0 to 60 represent
the degree to which the system is decreasing its acceptance of
messages in order to prevent the rapid depletion of critical system
resources. Higher numbers represent a higher degree of decreased
acceptance. Zero represents no decrease in acceptance. If this gauge
displays 999 , the system has entered “Resource Conservation mode,”
and it will accept no messages. Alert messages are sent whenever the
system enters or exits Resource Conservation mode.
Disk Utilization: Logs Percentage of disk being used for logs, displayed as LogUsd in the
status logs and log_used in the XML status.
Connections Gauges
Current Inbound Connections Current inbound connections to the listener interfaces.
Current Outbound Connections Current outbound connections to destination mail servers.
Queue Gauges
Active Recipients Message recipients in the delivery queue. Total of Unattempted
Recipients and Attempted Recipients.
Unattempted Recipients A subcategory of Active Recipients. Message recipients in queue for
which delivery has not yet been attempted.
Attempted Recipients A subcategory of Active Recipients. Message recipients in queue for
which delivery has been attempted but failed due to a Soft Bounces
Event.
Messages in Work Queue The number of messages waiting to be processed by alias table
expansion, masquerading, anti-spam, anti-virus scanning, message
filters, and LDAP queries prior to being enqueued.
Messages in Quarantine The unique number of messages in any quarantine, plus messages
that have been released or deleted but not yet acted upon. For example,
if you release all quarantined messages from Outbreak, the total
messages for Outbreak would become zero immediately, but this field
still reflects the quarantined messages until they were all delivered.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1095
Managing and Monitoring Using the CLI
Reading the Rates of Delivered and Bounced Messages
Statistic Description
Destinations in Memory The number of destinations domains in memory. For each domain
with a message destined to be delivered, a destination object is created
in memory. After all the mail for that domain has been delivered, the
destination object is retained for another 3 hours. After 3 hours, if no
new messages are bound for that domain, the object is expired so that
the destination is no longer reported (for example, in the tophosts
command). If you are delivering mail only to one domain, this counter
will be “1.” If you have never received or sent any messages (or no
messages have been processed by the email gateway in many hours),
the counter will be “0.”
If you are using Virtual Gateways, destination domains for each
Virtual Gateway will have a separate destination object. (For example,
yahoo.com will count as 3 destination objects if you are delivering to
yahoo.com from 3 different Virtual Gateways).
Kilobytes Used Queue storage used in kilobytes.
Kilobytes in Quarantine Queue storage used for quarantined messages. The value is calculated
as the message size plus 30 bytes for each recipient, totaled for the
“Messages in Quarantine” as counted above. Note that this calculation
will usually overestimate the space used.
Kilobytes Free Queue storage remaining in kilobytes.
Reading the Rates of Delivered and Bounced Messages
All rates are shown as the average rate an event occurs per hour at the specific point in time the query is made.
Rates are calculated for three intervals, the average rate per hour over the past one (1) minute, the past five
(5) minutes, and the past fifteen (15) minutes.
For example, if the email gateway receives 100 recipients in a single minute, then the rate for the 1 minute
interval will be 6,000 per hour. The rate for the 5-minute interval will be 1,200 per hour, and the 15-minute
rate will be 400 per hour. The rates are calculated to indicate what the average rate for the hour would be if
the rate for the one minute period continued. Therefore, 100 messages each minute would yield a higher rate
than 100 messages over 15 minutes.
The following table lists the available rates and their description when monitoring the email gateway.
Note This is the entire list. The displayed rates will vary depending upon which display option or command you
choose. Use this list as a reference.
Table 108: Rates
Statistic Description
Messages Received Rate of messages inserted into the delivery queue per hour.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1096
Managing and Monitoring Using the CLI
Monitoring Using the CLI
Statistic Description
Recipients Received Rate of the number of recipients on all messages inserted into the
delivery queue per hour.
Soft Bounced Events Rate of the number of soft bounce events per hour. (A message that
soft bounces multiple times has multiple soft bounce events.)
Completed Recipients Rate of the total of all hard bounced recipients, delivered recipients
and deleted recipients. Any recipient that is removed from the delivery
queue is considered completed.
Hard Bounced Recipients Rate of the total of all DNS hard bounces, 5XX hard bounces, filter
hard bounces, expired hard bounces and other hard bounces per hour.
A failed attempt to deliver a message to a recipient that results in
immediate termination of that delivery is a hard bounce.
Delivered Recipients Rate of messages successfully delivered to a recipient per hour.
Monitoring Using the CLI
• Monitoring the Email Status, on page 1097
• Monitoring Detailed Email Status, on page 1098
• Monitoring the Status of a Mail Host, on page 1100
• Determining the Make-up of the Email Queue, on page 1102
• Displaying Real-time Activity, on page 1103
• Monitoring Inbound Email Connections, on page 1104
• Checking the DNS Status, on page 1105
• Resetting Email Monitoring Counters, on page 1106
• Identifying Active TCP/IP Services, on page 1107
Monitoring the Email Status
You may want to monitor the status of email operations on the email gateway. The status command returns
a subset of the monitored information about email operations. The statistics returned displayed in one of two
fashions: counters and gauges. Counters provide a running total of various events in the system. For each
counter, you can view the total number of events that have occurred since the counter was reset, since the last
system reboot, and over the system's lifetime. Gauges show the current utilization of a system resource such
as memory, disk space, or active connections.
For a description of each item, see Overview of Managing and Monitoring Using the CLI, on page 1091.
Table 109: Mail Status
Statistic Description
Status as of Displays the current system time and date.
Last counter reset Displays the last time the counters were reset.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1097
Managing and Monitoring Using the CLI
Example
Statistic Description
System status Online, offline, receiving suspended, or delivery suspended. Note that the status will be
“receiving suspended” only when all listeners are suspended. The status will be “offline”
when receiving and delivery are suspended for all listeners.
Oldest Message Displays the oldest message waiting to be delivered by the system.
Features Displays any special features installed on the system by the featurekey command.
Example
mail3.example.com> status
Status as of: Thu Oct 21 14:33:27 2004 PDT
Up since: Wed Oct 20 15:47:58 2004 PDT (22h 45m 29s)
Last counter reset: Never
System status: Online
Oldest Message: 4 weeks 46 mins 53 secs
Counters: Reset Uptime Lifetime
Receiving
Messages Received 62,049,822 290,920 62,049,822
Recipients Received 62,049,823 290,920 62,049,823
Rejection
Rejected Recipients 3,949,663 11,921 3,949,663
Dropped Messages 11,606,037 219 11,606,037
Queue
Soft Bounced Events 2,334,552 13,598 2,334,552
Completion
Completed Recipients 50,441,741 332,625 50,441,741
Current IDs
Message ID (MID) 99524480
Injection Conn. ID (ICID) 51180368
Delivery Conn. ID (DCID) 17550674
Gauges: Current
Connections
Current Inbound Conn. 0
Current Outbound Conn. 14
Queue
Active Recipients 7,166
Messages In Work Queue 0
Messages In Quarantine 16,248
Kilobytes Used 387,143
Kilobytes In Quarantine 338,206
Kilobytes Free 39,458,745
mail3.example.com>
Monitoring Detailed Email Status
The status detail command returns complete monitored information about email operations. The statistics
returned are displayed in one of three categories: counters, rates, and gauges. Counters provide a running total
of various events in the system. For each counter, you can view the total number of events that have occurred
since the counter was reset, since the last system reboot, and over the system’s lifetime. Gauges show the
current utilization of a system resource such as memory, disk space, or active connections. All rates are shown
as the average rate an event occurs per hour at the specific point in time the query is made. Rates are calculated
for three intervals, the average rate per hour over the past one (1) minute, the past five (5) minutes, and the
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1098
Managing and Monitoring Using the CLI
Example
past fifteen (15) minutes. For a description of each item, see Overview of Managing and Monitoring Using
the CLI, on page 1091.
Example
mail3.example.com> status detail
Status as of: Thu Jun 30 13:09:18 2005 PDT
Up since: Thu Jun 23 22:21:14 2005 PDT (6d 14h 48m 4s)
Last counter reset: Tue Jun 29 19:30:42 2004 PDT
System status: Online
Oldest Message: No Messages
Feature - IronPort Anti-Spam: 17 days
Feature - Sophos: Dormant/Perpetual
Feature - Outbreak Filters: Dormant/Perpetual
Feature - Central Mgmt: Dormant/Perpetual
Counters: Reset Uptime Lifetime
Receiving
Messages Received 2,571,967 24,760 3,113,176
Recipients Received 2,914,875 25,450 3,468,024
Gen. Bounce Recipients 2,165 0 7,451
Rejection
Rejected Recipients 1,019,453 792 1,740,603
Dropped Messages 1,209,001 66 1,209,028
Queue
Soft Bounced Events 11,236 0 11,405
Completion
Completed Recipients 2,591,740 49,095 3,145,002
Hard Bounced Recipients 2,469 0 7,875
DNS Hard Bounces 199 0 3,235
5XX Hard Bounces 2,151 0 4,520
Expired Hard Bounces 119 0 120
Filter Hard Bounces 0 0 0
Other Hard Bounces 0 0 0
Delivered Recipients 2,589,270 49,095 3,137,126
Deleted Recipients 1 0 1
Global Unsub. Hits 0 0 0
DomainKeys Signed Msgs 10 9 10
Current IDs
Message ID (MID) 7615199
Injection Conn. ID (ICID) 3263654
Delivery Conn. ID (DCID) 1988479
Rates (Events Per Hour): 1-Minute 5-Minutes 15-Minutes
Receiving
Messages Received 180 300 188
Recipients Received 180 300 188
Queue
Soft Bounced Events 0 0 0
Completion
Completed Recipients 360 600 368
Hard Bounced Recipients 0 0 0
Delivered Recipients 360 600 368
Gauges: Current
System
RAM Utilization 1%
CPU Utilization
MGA 0%
AntiSpam 0%
AntiVirus 0%
Disk I/O Utilization 0%
Resource Conservation 0
Connections
Current Inbound Conn. 0
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1099
Managing and Monitoring Using the CLI
Monitoring the Status of a Mail Host
Current Outbound Conn. 0
Queue
Active Recipients 0
Unattempted Recipients 0
Attempted Recipients 0
Messages In Work Queue 0
Messages In Quarantine 19
Destinations In Memory 3
Kilobytes Used 473
Kilobytes In Quarantine 473
Kilobytes Free 39,845,415
Note A case could exist in a newly installed email gateway where the oldest message counter shows a message but,
in fact, there are no recipients shown in counters. If the remote host is connecting and in the process of receiving
a message very slowly (that is, it takes minutes to receive a message), you might see that the recipients received
counter displays “ 0 ” but the oldest message counter displays “ 1 .” This is because the oldest message counter
displays messages in progress. The counter will be reset if the connection is eventually dropped.
Monitoring the Status of a Mail Host
If you suspect delivery problems to a specific recipient host or you want to gather information on a Virtual
Gateway address, the hoststatus command displays this information. The hoststatus command returns monitoring
information about email operations relating to a specific recipient host. The command requires that you enter
the domain of the host information to be returned. DNS information stored in the AsyncOS cache and the last
error returned from the recipient host is also given. Data returned is cumulative since the last resetcounters
command. The statistics returned are displayed in two categories: counters and gauges. For a description of
each item, see Overview of Managing and Monitoring Using the CLI, on page 1091.
In addition, these other data are returned specific to the hoststatus command.
Table 110: Additional Data in the hoststatus Command
Statistic Description
Pending Outbound Pending, or “embryonic” connections to the destination mail host, as opposed
Connections to open and working connections. Pending Outbound Connections are connections
which have not yet gotten to the protocol greeting stage.
Oldest Message The age of the oldest active recipient in the delivery queue for this domains.
This counter is useful for determining the age of a message in the queue that
cannot be delivered because of soft bounce events and/or a downed host.
Last Activity This field is updated each time a message delivery is attempted to that host.
Ordered IP Addresses This field contains the TTL (time to live) for IP addresses, their preference
according to MX records, and the actual addresses. An MX record designates
the mail server IP address for a domain. A domain may have multiple MX
records. Each MX record mail server is assigned a priority. The MX record with
the lowest priority number is given preference.
Last 5XX error This field contains the most recent “5XX” status code and description returned
by the host. This is only displayed if there is an 5XX error.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1100
Managing and Monitoring Using the CLI
Virtual Gateway
Statistic Description
MX Records An MX record designates the mail server IP address for a domain. A domain
may have multiple MX records. Each MX record mail server is assigned a
priority. The MX record with the lowest priority number is given preference.
SMTP Routes for this host If SMTP routes are defined for this domain, they are listed here.
Last TLS Error This field contains a description of the the most recent outgoing TLS connection
error and the type of TLS connection that the email gateway tried to establish.
This is only displayed if there is a TLS error.
Virtual Gateway
The following Virtual Gateway information is only displayed if you have set up Virtual Gateway addresses
(see Configuring the Gateway to Receive Email, on page 77.)
Table 111: Additional Virtual Gateway Data in the hoststatus Command
Statistic Description
Host up/down Same definition as global hoststatus field of the same name — tracked per Virtual Gateway
address.
Last Activity Same definition as global hoststatus field of the same name — tracked per Virtual Gateway
address.
Recipients This field also corresponds to the same definition as the global hoststatus command. Active
Recipients field — tracked per Virtual Gateway address.
Last 5XX error This field contains the most recent 5XX status code and description returned by the host.
This is only displayed if there is a 5XX error.
Example
mail3.example.com> hoststatus
Recipient host:
[]> aol.com
Host mail status for: 'aol.com'
Status as of: Tue Mar 02 15:17:32 2010
Host up/down: up
Counters:
Queue
Soft Bounced Events 0
Completion
Completed Recipients 1
Hard Bounced Recipients 1
DNS Hard Bounces 0
5XX Hard Bounces 1
Filter Hard Bounces 0
Expired Hard Bounces 0
Other Hard Bounces 0
Delivered Recipients 0
Deleted Recipients 0
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1101
Managing and Monitoring Using the CLI
Determining the Make-up of the Email Queue
Gauges:
Queue
Active Recipients 0
Unattempted Recipients 0
Attempted Recipients 0
Connections
Current Outbound Connections 0
Pending Outbound Connections 0
Oldest Message No Messages
Last Activity Tue Mar 02 15:17:32 2010
Ordered IP addresses: (expiring at Tue Mar 02 16:17:32 2010)
Preference IPs
15 64.12.137.121 64.12.138.89 64.12.138.120
15 64.12.137.89 64.12.138.152 152.163.224.122
15 64.12.137.184 64.12.137.89 64.12.136.57
15 64.12.138.57 64.12.136.153 205.188.156.122
15 64.12.138.57 64.12.137.152 64.12.136.89
15 64.12.138.89 205.188.156.154 64.12.138.152
15 64.12.136.121 152.163.224.26 64.12.137.184
15 64.12.138.120 64.12.137.152 64.12.137.121
MX Records:
Preference TTL Hostname
15 52m24s mailin-01.mx.aol.com
15 52m24s mailin-02.mx.aol.com
15 52m24s mailin-03.mx.aol.com
15 52m24s mailin-04.mx.aol.com
Last 5XX Error:
----------
550 REQUESTED ACTION NOT TAKEN: DNS FAILURE
(at Tue Mar 02 15:17:32 2010 GMT) IP: 10.10.10.10
----------
Last TLS Error: Required - Verify
----------
TLS required, STARTTLS unavailable
(at Tue Mar 02 15:17:32 2010 GMT) IP: 10.10.10.10
Virtual gateway information:
============================================================
example.com (PublicNet_017):
Host up/down: up
Last Activity Wed June 22 13:47:02 2005
Recipients 0
Note The Virtual Gateway address information only appears if you are using the altsrchost feature.
Determining the Make-up of the Email Queue
To get immediate information about the email queue and determine if a particular recipient host has delivery
problems — such as a queue buildup — use the tophosts command. The tophosts command returns a list of
the top 20 recipient hosts in the queue. The list can be sorted by a number of different statistics, including
active recipients, connections out, delivered recipients, soft bounced events, and hard bounced recipients. For
a description of each item, see Overview of Managing and Monitoring Using the CLI, on page 1091.
Example
mail3.example.com> tophosts
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1102
Managing and Monitoring Using the CLI
Displaying Real-time Activity
Sort results by:
1. Active Recipients
2. Connections Out
3. Delivered Recipients
4. Soft Bounced Events
5. Hard Bounced Recipients
[1]> 1
Status as of: Mon Nov 18 22:22:23 2003
Active Conn. Deliv. Soft Hard
# Recipient Host Recip Out Recip. Bounced Bounced
1 aol.com 365 10 255 21 8
2 hotmail.com 290 7 198 28 13
3 yahoo.com 134 6 123 11 19
4 excite.com 98 3 84 9 4
5 msn.com 84 2 76 33 29
mail3.example.com>
Displaying Real-time Activity
The email gateway offers real-time monitoring, which allows you to view the progress of email activity on
the system. The rate command returns real-time monitoring information about email operations. The information
is updated on a periodic interval as specified by you. Use Control-C to stop the rate command.
The data shown are listed in the following table:
Table 112: Data in the rate Command
Statistic Description
Connections In Number of inbound connections.
Connections Out Number of outbound connections.
Recipients Received Total number of recipients received into the system.
Recipients Completed Total number of recipients completed.
Delta The difference change in Received and Completed recipients since the
last data update.
Queue Used Size of the message queue in kilobytes.
Example
mail3.example.com> rate
Enter the number of seconds between displays.
[10]> 1
Hit Ctrl-C to return to the main prompt.
Time Connections Recipients Recipients Queue
In Out Received Delta Completed Delta K-Used
23:37:13 10 2 41708833 0 40842686 0 64
23:37:14 8 2 41708841 8 40842692 6 105
23:37:15 9 2 41708848 7 40842700 8 76
23:37:16 7 3 41708852 4 40842705 5 64
23:37:17 5 3 41708858 6 40842711 6 64
23:37:18 9 3 41708871 13 40842722 11 67
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1103
Managing and Monitoring Using the CLI
Example
23:37:19 7 3 41708881 10 40842734 12 64
23:37:21 11 3 41708893 12 40842744 10 79
^C
The hostrate command returns real-time monitoring information about a specific mail host. This information
is a subset of the status detail command. (See Monitoring Detailed Email Status, on page 1098.)
Table 113: Data in the hostrate Command
Statistic Description
Host Status Current status of the specific host: up, down, or unknown.
Current Connections Out Current number of outbound connections to the host.
Active Recipients in Queue Total number of active recipients to the specific host in queue.
Active Recipients in Queue Delta Difference in the total number of active recipients to the specific host in
queue since the last known host status.
Delivered Recipients Delta Difference in the total number of delivered recipients to the specific host
in queue since the last known host status.
Hard Bounced Recipients Delta Difference in the total number of hard bounced recipients to the specific
host in queue since the last known host status.
Soft Bounce Events Delta Difference in the total number of soft bounced recipients to the specific
host in queue since the last known host status.
Use Control-C to stop the hostrate command.
Example
mail3.example.com> hostrate
Recipient host:
[]> aol.com
Enter the number of seconds between displays.
[10]> 1
Time Host CrtCncOut ActvRcp ActvRcp DlvRcp HrdBncRcp SftBncEvt
Status Delta Delta Delta Delta
23:38:23 up 1 0 0 4 0 0
23:38:24 up 1 0 0 4 0 0
23:38:25 up 1 0 0 12 0 0
^C
Monitoring Inbound Email Connections
You may want to monitor hosts that are connecting to the email gateway to identify the large volume senders
or to troubleshoot inbound connections to the system. The topin command provides a snapshot of the remote
hosts connecting to the system. It displays a table with one row for each remote IP address connecting to a
specific listener. Two connections from the same IP address to different listeners results in 2 rows in the
following table describes the fields displayed when using the topin command.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1104
Managing and Monitoring Using the CLI
Example
Table 114: Data in the topin Command
Statistic Description
Remote Hostname Hostname of the remote host, derived from Reverse DNS lookup.
Remote IP Address IP address of the remote host.
listener Nickname of the listener on the email gateway that is receiving the connection.
Connections In The number of concurrent connections from the remote host with the specified IP
address open at the time when the command is run.
The system does a reverse DNS lookup to find the remote hostname, and then a forward DNS lookup to
validate the name. If the forward lookup does not result in the original IP address, or if the reverse DNS lookup
fails, the table displays the IP address in the hostname column. For more information about the process of
sender verification, see Verifying Senders, on page 125.
Example
mail3.example.com> topin
Status as of: Sat Aug 23 21:50:54 2003
# Remote hostname Remote IP addr. listener Conn. In
1 mail.remotedomain01.com 172.16.0.2 Incoming01 10
2 mail.remotedomain01.com 172.16.0.2 Incoming02 10
3 mail.remotedomain03.com 172.16.0.4 Incoming01 5
4 mail.remotedomain04.com 172.16.0.5 Incoming02 4
5 mail.remotedomain05.com 172.16.0.6 Incoming01 3
6 mail.remotedomain06.com 172.16.0.7 Incoming02 3
7 mail.remotedomain07.com 172.16.0.8 Incoming01 3
8 mail.remotedomain08.com 172.16.0.9 Incoming01 3
9 mail.remotedomain09.com 172.16.0.10 Incoming01 3
10 mail.remotedomain10.com 172.16.0.11 Incoming01 2
11 mail.remotedomain11.com 172.16.0.12 Incoming01 2
12 mail.remotedomain12.com 172.16.0.13 Incoming02 2
13 mail.remotedomain13.com 172.16.0.14 Incoming01 2
14 mail.remotedomain14.com 172.16.0.15 Incoming01 2
15 mail.remotedomain15.com 172.16.0.16 Incoming01 2
16 mail.remotedomain16.com 172.16.0.17 Incoming01 2
17 mail.remotedomain17.com 172.16.0.18 Incoming01 1
18 mail.remotedomain18.com 172.16.0.19 Incoming02 1
19 mail.remotedomain19.com 172.16.0.20 Incoming01 1
20 mail.remotedomain20.com 172.16.0.21 Incoming01 1
Checking the DNS Status
The dnsstatus command returns a counter displaying statistics of DNS lookup and cache information. For
each counter, you can view the total number of events since the counter was last reset, since the last system
reboot, and over the lifetime of the system.
The following table lists the available counters.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1105
Managing and Monitoring Using the CLI
Example
Table 115: Data in the dnsstatus Command
Statistic Description
DNS Requests A top-level, non-recursive request to the system DNS cache to resolve a
domain name.
Network Requests A request to the network (non-local) to retrieve DNS information.
Cache Hits A request to the DNS cache where the record was found and returned.
Cache Misses A request to the DNS cache where the record was not found.
Cache Exceptions A request to the DNS cache where the record was found but the domain was
unknown.
Cache Expired A request to the DNS cache where the record was found
in the cache, considered for use, and discarded because it was too old.
Many entries can exist in the cache even though their time to live (TTL) has
been exceeded. As long as these entries are not used, they will not be included
in the expires counter. When the cache is flushed, both valid and invalid (too
old) entries are deleted. A flush operation does not change the expires counter.
Example
mail3.example.com> dnsstatus
Status as of: Sat Aug 23 21:57:28 2003
Counters: Reset Uptime Lifetime
DNS Requests 211,735,710 8,269,306 252,177,342
Network Requests 182,026,818 6,858,332 206,963,542
Cache Hits 474,675,247 17,934,227 541,605,545
Cache Misses 624,023,089 24,072,819 704,767,877
Cache Exceptions 35,246,211 1,568,005 51,445,744
Cache Expired 418,369 7,800 429,015
mail3.example.com>
Resetting Email Monitoring Counters
The resetcounters command resets cumulative email monitoring counters. The reset affects global counters
as well as per host counters. The reset does not affect the counters on messages in the delivery queue related
to retry schedules.
Note You can also reset the counters in the GUI. See System Status Page, on page 862.
Example
mail3.example.com> resetcounters
Counters reset: Mon Jan 01 12:00:01 2003
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1106
Managing and Monitoring Using the CLI
Identifying Active TCP/IP Services
Identifying Active TCP/IP Services
To identify active TCP/IP services used by your email gateway, use the tcpservices command in the command
line interface.
Managing the Email Queue
Cisco AsyncOS allows you to perform operations on messages in the email queue. You can delete, bounce,
suspend, or redirect messages in the email queue. You can also locate, remove, and archive older messages
in your queue.
Deleting Recipients in Queue
If particular recipients are not being delivered or to clear the email queue, use the deleterecipients command.
The deleterecipients command allows you to manage the email delivery queue by deleting specific recipients
waiting for delivery. Recipients to be deleted are identified by either the recipient host that the recipient is
destined for, or the message sender identified by the specific address given in the Envelope From line of the
message envelope. Alternately, you can delete all messages in the delivery queue (all active recipients) at
once.
Note To perform the deleterecipients function, it is recommended that you place the email gateway in an offline
state or suspended delivery (see Suspending Email Receiving and Delivery , on page 1006).
Note Although the function is supported in all states, certain messages may be delivered while the function is taking
place.
Matches to recipient hosts and senders must be identical string matches. Wild cards are not accepted. The
deleterecipients command returns the total number of messages deleted. In addition, if a mail log subscription
(IronPort text format only) is configured, the message deletion is logged as a separate line.
Example
mail3.example.com> deleterecipients
Please select how you would like to delete messages:
1. By recipient host.
2. By Envelope From address.
3. All.
[1]>
The email gateway gives you various options to delete recipients depending upon the need. The following
example show deleting recipients by recipient host, deleting by Envelope From Address, and deleting all
recipients in the queue.
Delete by Recipient Domain
Please enter the hostname for the messages you wish to delete.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1107
Managing and Monitoring Using the CLI
Delete by Envelope From Address
[]> example.com
Are you sure you want to delete all messages being delivered to "example.com"? [N]> Y
Deleting messages, please wait.
100 messages deleted.
Delete by Envelope From Address
Please enter the Envelope From address for the messages you wish to delete.
[]> [email protected]
Are you sure you want to delete all messages with the Envelope From address of
"[email protected]"? [N]> Y
Deleting messages, please wait.
100 messages deleted.
Delete All
Are you sure you want to delete all messages in the delivery queue (all active recipients)?
[N]> Y
Deleting messages, please wait.
1000 messages deleted.
Bouncing Recipients in Queue
Similar to the deleterecipients command, the bouncerecipients command allows you to manage the email
delivery queue by hard bouncing specific recipients waiting for delivery. Message bouncing follows regular
bounce message configuration as specified in the bounceconfig command.
Note To perform the bouncerecipients function, it is recommended that you place the email gateway in an offline
state or suspended delivery (see Suspending Email Receiving and Delivery , on page 1006).
Note Although the function is supported in all states, certain messages may be delivered while the function is taking
place.
Matches to recipient hosts and senders must be identical string matches. Wild cards are not accepted. The
bouncerecipients command returns the total number of messages bounced.
Note The bouncerecipients function is resource-intensive and may take several minutes to complete. If in offline
or suspended delivery state, the actual sending of bounce messages (if hard bounce generation is on) will
begin only after Cisco AsyncOS is placed back into the online state by using the resume command.
Example
mail3.example.com> bouncerecipients
Please select how you would like to bounce messages:
1. By recipient host.
2. By Envelope From address.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1108
Managing and Monitoring Using the CLI
Bounce by Recipient Host
3. All.
[1]>
Recipients to be bounced are identified by either the destination recipient host or the message sender identified
by the specific address given in the Envelope From line of the message envelope. Alternately, all messages
in the delivery queue can be bounced at once.
Bounce by Recipient Host
Please enter the hostname for the messages you wish to bounce.
[]> example.com
Are you sure you want to bounce all messages being delivered to "example.com"? [N]> Y
Bouncing messages, please wait.
100 messages bounced.
Bounce by Envelope From Address
Please enter the Envelope From address for the messages you wish to bounce.
[]> [email protected]
Are you sure you want to bounce all messages with the Envelope From address of
"[email protected]"? [N]> Y
Bouncing messages, please wait.
100 messages bounced.
Bounce All
Are you sure you want to bounce all messages in the queue? [N]> Y
Bouncing messages, please wait.
1000 messages bounced.
Redirecting Messages in Queue
The redirectrecipients commands allow you to redirect all messages in the email delivery queue to another
relay host. Please note that redirecting recipients to a host or IP address that is not prepared to accept large
volumes of SMTP mail from this host will cause messages to bounce and possibly result in the loss of mail.
Caution Redirecting messages to a receiving domain that has /dev/null as its destination results in the loss of messages.
The CLI does not display a warning if you redirect mail to such a domain. Check the SMTP route for the
receiving domain before redirecting messages.
Example
The following example redirects all mail to the example2.com host.
mail3.example.com> redirectrecipients
Please enter the hostname or IP address of the machine you want to send all mail to.
[]> example2.com
WARNING: redirecting recipients to a host or IP address that is not prepared to accept large
volumes of SMTP mail from this host will cause messages to bounce and possibly result in
the loss of mail.
Are you sure you want to redirect all mail in the queue to "example2.com"? [N]> y
Redirecting messages, please wait.
246 recipients redirected.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1109
Managing and Monitoring Using the CLI
Showing Messages Based on Recipient in Queue
Showing Messages Based on Recipient in Queue
Use the showrecipients command to show messages from the email delivery queue by recipient host or
Envelope From address. You can also show all messages in the queue.
Example
mail3.example.com> showrecipients
Please select how you would like to show messages:
1. By recipient host.
2. By Envelope From address.
3. All.
[1]> 3
Showing messages, please wait.
MID/ Bytes/ Sender/ Subject
[RID] [Atmps] Recipient
1527 1230 [email protected] Testing
[0] [0] [email protected]
1522 1230 [email protected] Testing
[0] [0] [email protected]
1529 1230 [email protected] Testing
[0] [0] [email protected]
1530 1230 [email protected] Testing
[0] [0] [email protected]
1532 1230 [email protected] Testing
[0] [0] [email protected]
1531 1230 [email protected] Testing
[0] [0] [email protected]
1518 1230 [email protected] Testing
[0] [0] [email protected]
1535 1230 [email protected] Testing
[0] [0] [email protected]
1533 1230 [email protected] Testing
[0] [0] [email protected]
1536 1230 [email protected] Testing
[0] [0] [email protected]
The following example shows messages in the queue for all recipient hosts.
Suspending Email Delivery
To temporarily suspend email delivery for maintenance or troubleshooting, use the suspenddel command.
The suspenddel command puts Cisco AsyncOS into suspended delivery state. This state is characterized by
the following:
• Outbound email delivery is halted.
• Inbound email connections are accepted.
• Log transfers continue.
• The CLI remains accessible.
The suspenddel command lets open outbound connections close, and it stops any new connections from
opening. The suspenddel command commences immediately, and allows any established connections to
successfully close. Use the resumedel command to return to regular operations from the suspended delivery
state.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1110
Managing and Monitoring Using the CLI
Example
Note The “delivery suspend” state is preserved across system reboots. If you use the suspenddel command and then
reboot the email gateway, you must resume delivery after the reboot using the resumedel command.
Example
mail3.example.com> suspenddel
Enter the number of seconds to wait before abruptly closing connections.
[30]>
Waiting for outgoing deliveries to finish...
Mail delivery suspended.
Resuming Email Delivery
The resumedel command returns Cisco AsyncOS to normal operating state after using the suspenddel command.
Syntax
resumedel
mail3.example.com> resumedel
Mail delivery resumed.
Suspending Receiving Email
To temporarily suspend all listeners from receiving email, use the suspendlistener command. While receiving
is suspended, the system does not accept connections to the specific port of the listener.
This behavior has changed in this release of AsyncOS. In previous releases, the system would accept
connections, respond with the following responses and disconnect:
• SMTP: 421 hostname Service not available, closing transaction channel
• QMQP: ZService not available
Note The “receiving suspend” state is preserved across system reboots. If you use the suspendlistener command
and then reboot the email gateway, you must use the resumelistener command before the listener will resume
receiving messages.
Syntax
suspendlistener mail3.example.com> suspendlistener
Choose the listener(s) you wish to suspend.
Separate multiple entries with commas.
1. All
2. InboundMail
3. OutboundMail
[1]> 1
Enter the number of seconds to wait before abruptly closing connections.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1111
Managing and Monitoring Using the CLI
Resuming Receiving Email
[30]>
Waiting for listeners to exit...
Receiving suspended.
mail3.example.com>
Resuming Receiving Email
The resumelistener command returns Cisco AsyncOS to normal operating state after using the suspendlistener
command.
Syntax
resumelistener
mail3.example.com> resumelistener
Choose the listener(s) you wish to resume.
Separate multiple entries with commas.
1. All
2. InboundMail
3. OutboundMail
[1]> 1
Receiving resumed.
mail3.example.com>
Resuming Delivery and Receiving of Email
The resume command resumes both delivery and receiving.
Syntax
resume
mail3.example.com> resume
Receiving resumed.
Mail delivery resumed.
mail3.example.com>
Scheduling Email for Immediate Delivery
Recipients and hosts that are scheduled for later delivery can be immediately retried by using the delivernow
command. The delivernow command allows you to reschedule email in the queue for immediate delivery.
All domains that are marked down and any scheduled or soft bounced messages are queued for immediate
delivery.
The delivernow command can be invoked for all recipients or specific recipients in the queue (scheduled and
active). When selecting specific recipients, you must enter the domain name of the recipients to schedule for
immediate delivery. The system matches the entire string for character and length.
Syntax
delivernow
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1112
Managing and Monitoring Using the CLI
Pausing the Work Queue
mail3.example.com> delivernow
Please choose an option for scheduling immediate delivery.
1. By recipient host
2. All messages
[1]> 1
Please enter the domain to schedule for immediate delivery.
[]> recipient.example.com
Rescheduling all messages to recipient.example.com for immediate delivery.
mail3.example.com>
Pausing the Work Queue
Processing for LDAP recipient access, masquerading, LDAP re-routing, Message Filters, anti-spam, and the
anti-virus scanning engine are all performed in the “work queue.” Refer to Configuring Routing and Delivery
Features, on page 697 for the processing flow and Reading the System Gauges, on page 1094 for a description
of the “Messages in Work Queue” gauge. You can manually pause the work queue portion of message
processing using the workqueue command.
For example, assume that you wanted to change the configuration of an LDAP server configuration while
many messages are in the work queue. Perhaps you want to switch from bouncing to dropping messages based
on an LDAP recipient access query. Or perhaps you want to pause the queue while you manually check for
the latest anti-virus scanning engine definition files (via the antivirusupdate command).The workqueue
command allows you to pause and resume the work queue to stop processing while you perform other
configuration changes.
When you pause and resume the work queue, the event is logged. For example
Sun Aug 17 20:01:36 2003 Info: work queue paused, 1900 msgs S
Sun Aug 17 20:01:39 2003 Info: work queue resumed, 1900 msgs
In the following example, the work queue is paused:
mail3.example.com> workqueue
Status as of: Sun Aug 17 20:02:30 2003 GMT
Status: Operational
Messages: 1243
Choose the operation you want to perform:
- STATUS - Display work queue status
- PAUSE - Pause the work queue
- RATE - Display work queue statistics over time
[]> pause
Manually pause work queue? This will only affect unprocessed messages. [N]> y
Reason for pausing work queue:
[]> checking LDAP server
Status as of: Sun Aug 17 20:04:21 2003 GMT
Status: Paused by admin: checking LDAP server
Messages: 1243
Note Entering a reason is optional. If you do not enter a reason, the system logs the reason as “ Manually paused
by user .”
In this example, the work queue is resumed:
mail3.example.com> workqueue
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1113
Managing and Monitoring Using the CLI
Locating and Archiving Older Messages
Status as of: Sun Aug 17 20:42:10 2003 GMT
Status: Paused by admin: checking LDAP server
Messages: 1243
Choose the operation you want to perform:
- STATUS - Display work queue status
- RESUME - Resume the work queue
- RATE - Display work queue statistics over time
[]> resume
Status: Operational
Messages: 1243
Locating and Archiving Older Messages
Sometimes older messages remain in the queue because they could not be delivered. You may want to remove
and archive these messages. To do this, use the showmessage CLI command to to display the message for the
given message ID. Use the oldmessage CLI command to display the oldest non-quarantine message on the
system. You can then optionally use the removemessage to safely remove the message for the given message
ID. This command can only remove messages that are in the work queue, retry queue, or a destination queue.
If the message is in none of these queues, it cannot be removed.
You can also use the archivemessage[mid] CLI command to archive the message for a given message ID into
an mbox file in the configuration directory.
You cannot use the oldmessage command to get the message ID for a message in a quarantine. However, if
you know the message ID, you can show or archive the specified message. Since the message is not in the
work queue, retry queue, or a destination queue, you cannot remove the message with the removemessage
command.
Note You cannot perform any of these queue management commands on a message in the Cisco Spam Quarantine.
Syntax
archivemessage
example.com> archivemessage
Enter the MID to archive and remove.
[0]> 47
MID 47 has been saved in file oldmessage_47.mbox in the configuration directory
example.com>
Syntax
oldmessage
example.com> oldmessage
MID 9: 1 hour 5 mins 35 secs old
Received: from example.com ([172.16.0.102])
by example.com with SMTP; 14 Feb 2007 22:11:37 -0800
From: [email protected]
To: [email protected]
Subject: Testing
Message-Id: <[email protected]>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1114
Managing and Monitoring Using the CLI
Tracking Messages Within the System
Tracking Messages Within the System
The findevent CLI command simplifies the process of tracking messages within the system using the onbox
mail log files. The findevent CLI command allows you to search through the mail logs for a particular message
by searching for a message ID or a regular expression match against the subject header, envelope sender or
envelope recipient. You can display results for the current log file, all the log files, or display log files by date.
When you view log files by date, you can specify a date or a range of dates.
After you identify the message you want to view logs for, the findevent command displays the log information
for that message ID including splintering information (split log messages, bounces and system generated
messages). The following example shows the findevent CLI command tracking the receiving and delivery a
message with “confidential” in the subject header:
example.com>
findevent
Please choose which type of search you want to perform:
1. Search by envelope FROM
2. Search by Message ID
3. Search by Subject
4. Search by envelope TO
[1]> 3
Enter the regular expression to search for.
[]> confidential
Currently configured logs:
1. "mail_logs" Type: "IronPort Text Mail Logs" Retrieval: FTP Poll
Enter the number of the log you wish to use for message tracking.
[]> 1
Please choose which set of logs to search:
1. All available log files
2. Select log files by date list
3. Current log file
[3]> 3
The following matching message IDs were found. Please choose one to
show additional log information:
1. MID 4 (Tue Jul 31 17:37:35 2007) sales: confidential
[1]> 1
Tue Jul 31 17:37:32 2007 Info: New SMTP ICID 2 interface Data 1 (172.19.1.86) address
10.251.20.180 reverse dns host unknown verified no
Tue Jul 31 17:37:32 2007 Info: ICID 2 ACCEPT SG None match ALL SBRS None
Tue Jul 31 17:37:35 2007 Info: Start MID 4 ICID 2
Tue Jul 31 17:37:35 2007 Info: MID 4 ICID 2 From: <[email protected]>
Tue Jul 31 17:37:35 2007 Info: MID 4 ICID 2 RID 0 To: <[email protected]>
Tue Jul 31 17:37:35 2007 Info: MID 4 Subject 'sales: confidential'
Tue Jul 31 17:37:35 2007 Info: MID 4 ready 4086 bytes from <[email protected]>
Tue Jul 31 17:37:35 2007 Info: MID 4 matched all recipients for per-recipient policy DEFAULT
in the inbound table
Tue Jul 31 17:37:35 2007 Info: ICID 2 close
Tue Jul 31 17:37:37 2007 Info: MID 4 interim verdict using engine: CASE spam negative
Tue Jul 31 17:37:37 2007 Info: MID 4 using engine: CASE spam negative
Tue Jul 31 17:37:37 2007 Info: MID 4 interim AV verdict using Sophos CLEAN
Tue Jul 31 17:37:37 2007 Info: MID 4 antivirus negative
Tue Jul 31 17:37:37 2007 Info: MID 4 queued for delivery
Tue Jul 31 17:37:37 2007 Info: Delivery start DCID 0 MID 4 to RID [0]
Tue Jul 31 17:37:37 2007 Info: Message done DCID 0 MID 4 to RID [0]
Tue Jul 31 17:37:37 2007 Info: MID 4 RID [0] Response '/null'
Tue Jul 31 17:37:37 2007 Info: Message finished MID 4 done
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1115
Managing and Monitoring Using the CLI
Monitoring System Health and Status Using SNMP
Monitoring System Health and Status Using SNMP
The AsyncOS operating system supports system status monitoring via SNMP (Simple Network Management
Protocol). This release implements a read-only subset of MIB-II as defined in RFCs 1213 and 1907. (For
more information on SNMP, see RFCs 1065, 1066, and 1067.) Please note:
• SNMP is off by default.
• When SNMP is enabled, the default version used is SNMPv3.
• SNMP SET operations (configuration) are not implemented.
• AsyncOS supports SNMPv1, v2, and v3.
• Passphrases for authentication and encryption should be different. The encryption algorithm must be
AES only. The authentication algorithm must be SHA-1 only. The snmpconfig command “remembers”
your passphrases the next time you run the command.
• The SNMPv3 username is: v3get
> snmpwalk -v 3 -l AuthNoPriv -u v3get -a SHA -A ironport mail.example.com
• If you use only SNMPv1 or SNMPv2, you must set a community string. The community string does not
default to public .
• For SNMPv1 and SNMPv2, you must specify a network from which SNMP GET requests are accepted.
• If you use SNMPv3, you must select any one of the supported security levels shown in the following
table:
Security Level Authentication Privacy
noAuthNoPriv Yes No
The authentication is done using
the SNMPv3 username.
authNoPriv Yes No
The authentication is done using
the SNMPv3 authentication
passphrase.
authPriv Yes Yes
The authentication is done using The privacy is activated using the
the SNMPv3 authentication SNMPv3 privacy passphrase.
passphrase.
• If you enable both SNMPv2 and SNMPv3, you must select the required version for traps.
• To use traps, an SNMP manager (not included in AsyncOS) must be running and its IP address entered
as the trap target. (You can use a hostname, but if you do, traps will only work if DNS is working.)
Use the snmpconfig command to enable and configure SNMP monitoring for the email gateway. After you
choose and configure values for an interface, the email gateway responds to SNMPv3 GET requests. These
version 3 requests must include a matching passphrase. By default, version 1 and 2 requests are rejected. If
enabled, version 1 and 2 requests must have a matching community string.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1116
Managing and Monitoring Using the CLI
MIB Files
MIB Files
The following MIB files for email gateways are available from
http://www.cisco.com/c/en/us/support/security/email-security-appliance/tsd-products-support-series-home.html.
Use the latest available MIB files.
• ASYNCOS-MAIL-MIB.txt — an SNMPv2 compatible description of the Enterprise MIB for email
gateways.
• AsyncOS-SMI.txt (IRONPORT-SMI.txt) — a “Structure of Management Information” (SMI) file that
defines the role of the ASYNCOS-MAIL-MIB in Cisco content security products.
Hardware Objects
Hardware sensors conforming to the Intelligent Platform Management Interface Specification (IPMI) report
information such as temperature, fan speed, and power supply status.
It is a good idea to poll for the hardware status and identify possible hardware failures before they become
critical. Temperatures within 10 per cent of the critical value may be a cause for concern.
For information such as the number of power supplies and the range of operating temperatures for your email
gateway, see the hardware guide for your model. For the location of hardware guides, see Documentation ,
on page 16.
Hardware Traps
Status change traps are sent when the status changes. Fan Failure and high temperature traps are sent every
5 seconds. The other traps are failure condition alarm traps — they are sent once when the state changes
(healthy to failure).
For example, on C170 email gateways, traps are sent if the following thresholds are reached:
Table 116: Hardware Traps on C170 Email Gateways: Temperature and Hardware Conditions
Model High Temp High Temp High Temp High Temp Fan Failure Power Supply RAID Link
(CPU) (Ambient) (Backplane) (Riser)
C170 90C 47C NA NA 0 RPMs Status Change Status Status
Change Change
To see the available traps and threshold values on your email gateway, run the snmpconfig command from
the command-line interface.
Note that failure condition alarm traps represent a critical failure of the individual component, but may not
cause a total system failure. For example, a single fan or power supply can fail on an email gateway with
multiple fans or power supplies and the email gateway will continue to operate.
Related Topics
• Example: snmpconfig Command , on page 1118
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1117
Managing and Monitoring Using the CLI
SNMP Traps
SNMP Traps
SNMP provides the ability to send traps, or notifications, to advise an administration application (an SNMP
management console, typically) when one or more conditions have been met. Traps are network packets that
contain data relating to a component of the system sending the trap. Traps are generated when a condition has
been met on the SNMP agent (in this case, the email gateway). After the condition has been met, the SNMP
agent then forms an SNMP packet and sends it to the host running the SNMP management console software.
To enable and configure SNMP traps, use the snmpconfig command.
To specify multiple trap targets: when prompted for the trap target, you may enter up to 10 comma separated
IP addresses.
Example: snmpconfig Command
In the following example, the snmpconfig command is used on a C690 hardware email gateway to enable
SNMP on the “PublicNet” interface on port 161. The community string public is entered for GET requests
from versions 1 and 2.
mail1.example.com> snmpconfig
Current SNMP settings:
SNMP Disabled.
Choose the operation you want to perform:
- SETUP - Configure SNMP.
[]> setup
Do you want to enable SNMP? [Y]>
SNMP default version is V3
Choose an IP interface for SNMP requests.
1. Management (10.10.4.5/27: mail1.example.com) [1]>
Which port shall the SNMP daemon listen on?
[161]>
Select SNMPv3 security level:
1. noAuthNoPriv - Authentication is done using the SNMPv3 username, and no privacy is
activated.
2. authNoPriv - Authentication is done using the SNMPv3 authentication passphrase, and no
privacy is activated.
3. authPriv - Authentication is done using the SNMPv3 authentication passphrase, and privacy
is activated using the SNMPv3 privacy passphrase.
[3]>
Select SNMPv3 authentication type:
1. SHA
[1]>
Select SNMPv3 privacy protocol:
1. AES
[1]>
Enter the SNMPv3 authentication passphrase.
[]>
The SNMPv3 passphrase must be at least 8 characters.
Enter the SNMPv3 authentication passphrase.
[]>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1118
Managing and Monitoring Using the CLI
Example: snmpconfig Command
Enter the SNMPv3 authentication passphrase again to confirm.
[]>
Enter the SNMPv3 privacy passphrase.
[]>
Enter the SNMPv3 privacy passphrase again to confirm.
[]>
Warning: The same authentication and privacy passwords reduce the security of the system.
Do you want to set other passwords? [Y]> n
Service SNMP V1/V2c requests? [N]> Y
Enter the SNMP V1/V2c community string.
[ironport]>
Shall SNMP V2c requests be serviced from IPv4 addresses? [Y]>
From which IPv4 networks shall SNMP V1/V2c requests be allowed? Separate multiple networks
with commas.
[127.0.0.1/32]>
Select the version for SNMP traps:
1. 2c
2. 3
[2]>
Enter the Trap target as a host name, IP address or list of IP addresses separated by commas
(IP address preferred). Enter "None" to disable traps.
[127.0.0.1]> 10.10.0.28
Enterprise Trap Status
1. CPUUtilizationExceeded Disabled
2. FIPSModeDisableFailure Enabled
3. FIPSModeEnableFailure Enabled
4. FailoverHealthy Enabled
5. FailoverUnhealthy Enabled
6. connectivityFailure Disabled
7. keyExpiration Enabled
8. linkUpDown Enabled
9. memoryUtilizationExceeded Disabled
10. resourceConservationMode Enabled
11. updateFailure Enabled
Do you want to change any of these settings? [N]>
Enter the System Location string.
[Unknown: Not Yet Configured]>
Enter the System Contact string.
[snmp@localhost]>
Current SNMP settings:
Listening on interface "Management" 10.10.4.5/27 port 161.
SNMP v3: Enabled.
Security level: authPriv
Authentication Protocol: SHA
Encryption Protocol: AES
SNMP v1/v2: Enabled, accepting requests from subnet 127.0.0.1/32,fe::1/64.
SNMP v1/v2 Community String: ironport
Trap version: V3
Trap target: 10.10.0.28
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1119
Managing and Monitoring Using the CLI
Example: snmpconfig Command
Location: Unknown: Not Yet Configured
System Contact: snmp@localhost
Choose the operation you want to perform:
- SETUP - Configure SNMP.
[]>
mail1.example.com > commit
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1120
CHAPTER 41
Improving Phishing Detection Efficacy using
Service Logs
This chapter contains the following sections:
• Overview, on page 1121
• Enabling Service Logs on Email Gateway, on page 1121
• Disabling Service Logs on Email Gateway, on page 1122
• Frequently Asked Questions, on page 1122
Overview
The Service Logs are used to collect personal data based on the Cisco Email Security Appliance Data Sheet
guidelines.
The Service Logs are sent to the Cisco Talos Cloud service to improve Phishing detection.
Note From AsyncOS 13.5 onwards, Service Logs replaces senderbase as the telemetry data that is sent to Cisco
Talos Cloud service.
The email gateway collects limited personal data from customer emails and offers extensive useful threat
detection capabilities that can be coupled with dedicated analysis systems to collect, trend, and correlate
observed threat activity. Cisco uses the personal data to improve your email gateway capabilities to analyze
the threat landscape, provide threat classification solutions on malicious emails, and to protect your email
gateway from new threats such as spam, virus, and directory harvest attacks.
Enabling Service Logs on Email Gateway
Procedure
Step 1 Go to Security Services > Service Logs.
Step 2 Click Edit Global Settings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1121
Improving Phishing Detection Efficacy using Service Logs
Disabling Service Logs on Email Gateway
Step 3 Check the Enable sharing limited data with the Service Logs Information Service (Recommended) check
box.
Checking this box enables the feature globally for the email gateway. When enabled, the Context Adaptive
Scanning Engine (CASE) is used to collect and report the data (regardless of whether or not Cisco anti-spam
scanning is enabled). You can configure the same settings using the servicelogsconfig command in
the CLI
Step 4 Click Submit and commit your changes.
Disabling Service Logs on Email Gateway
Procedure
Step 1 Go to Security Services > Service Logs.
Step 2 Click Disable and commit your changes.
Frequently Asked Questions
Cisco recognizes that privacy is important to you, so we design and operate our services with the protection
of your privacy in mind. If you enroll to Cisco Talos Cloud service, Cisco will collect aggregated statistics
about your organization’s email traffic; however, we do not collect or use any personally identifiably
information. Any information Cisco collects that would identify your users or your organization will be treated
as confidential.
What data do I share?
The data is summarized information on message attributes and information on how different types of messages
were handled by email gateways. We do not collect the full body of the message. Again, information provided
to Cisco that would identify your users or your organization will be treated as confidential. (See What does
Cisco do to make sure that the data I share is secure?, on page 1123 below).
The following tables explain a sample log entry in a “human-friendly” format.
Table 117: Statistics Shared per Email Message Information
Item Sample Data
GUID for the inbound SMTP connection 0FyIkNX8ThST1
/IdfyNshg==
GUID for the email message 1Hss77LIS6u7y5
GDn0QFEQ==
Cisco Secure Email Gateway message ID 5191655
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1122
Improving Phishing Detection Efficacy using Service Logs
What does Cisco do to make sure that the data I share is secure?
Item Sample Data
Number of recipients and their validity 1
Scanner verdicts from non-Cisco Talos engines (for example, 4
Anti-Virus or Advanced Malware Protection)
Message disposition MSG_DISP_DROPPED
Message disposition reason MSG_DISP_FILTER
Is the message for outbound delivery? true
Message size 35100
Incoming mail relay true
Mail flow direction IP_DIR_OUT
AMP verdict information file_sha2_256:
"\217\263\037\004\374`N
\3264\265\016\314\227\005E\337\373q
\177A\245 \017\004\204\340\231\260!^
Sampling of dropped messages true
Table 118: Statistics Shared per Periodic Configuration Information
Item Sample Data
Outbreak Filters feature enabled true
Sender Domain Reputation (SDR) disabled flag true
Context Adaptive Scanning Engine (CASE) version 3.8.5-036
Talos engine 1.95.0.220
Generic list of enabled features Sophos_enabled
What does Cisco do to make sure that the data I share is secure?
If you agree to enroll to Cisco Talos Cloud service:
• Data sent from your email gateways will be sent to the Cisco Talos Cloud service using the secure
gRPC/HTTP2 protocol.
• All customer data will be handled with care at Cisco. This data will be stored in a secure location and
access to the data will be limited to employees and contractors at Cisco who require access in order to
improve the company's email security products and services or provide customer support.
• No information identifying email recipients or the customer's company will be shared outside of Cisco
Systems when reports or statistics are generated based on the data.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1123
Improving Phishing Detection Efficacy using Service Logs
Will sharing data impact the performance of my Cisco email gateways?
Will sharing data impact the performance of my Cisco email gateways?
Cisco believes that there will be a minimal performance impact for most customers. We record data that
already exists as part of the mail delivery process. Customer data is then aggregated on the email gateway
and sent to Cisco Talos Cloud service. We anticipate that the total size of data transferred via HTTPS will be
less than 1% of the bandwidth of a typical company's email traffic.
When enabled, the Context Adaptive Scanning Engine (CASE) is used to collect and report the data (regardless
of whether or not Cisco anti-spam scanning is enabled).
If you have additional questions, please contact Cisco Customer Support. See Cisco Support Community, on
page 17.
Are there other ways I can share data?
For customers wanting to do even more to help Cisco provide top quality security services, there is a command
that allows you to share additional data. This higher level of data sharing will also provide attachment filenames
in clear, unhashed text, as well as hostnames of URLs in messages. If you are interested in learning more
about this feature, please talk to your Systems Engineer or contact Cisco Customer Support.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1124
CHAPTER 42
Other Tasks in the GUI
This chapter contains the following sections:
• The Graphical User Interface (GUI), on page 1125
• System Information in the GUI , on page 1126
• Gathering XML status from the GUI, on page 1126
The Graphical User Interface (GUI)
The graphical user interface (GUI) is the web-based alternative to some command line interface (CLI)
commands for system monitoring and configuration. The GUI enables you to monitor the system using a
simple Web-based interface without having to learn the AsyncOS command syntax. After HTTP and/or
HTTPS services have been enabled for an interface, you can access the GUI and log in. See the “Accessing
the Email Gateway” chapter for more information.
Enabling the GUI on an Interface
By default, the system ships with HTTP enabled on the Management interface.
To enable the GUI, execute the interfaceconfig command at the command-line interface, edit the interface
that you want to connect to, and then enable the HTTP services or secure HTTP services, or both.
Note You can also use the Network > IP Interfaces page to enable or disable the GUI on an interface, once you
have the GUI enabled on any other interface. See IP Interfaces, on page 1297 for more information.
Note Enabling secure HTTP on an interface requires you to install a certificate. For more information, see “Enabling
a Certificate for HTTPS.”
For either service, you specify the port on which you want the service to be enabled. By default, HTTP is
enabled on port 80 and HTTPS on port 443. If you enable both services for an interface, you can automatically
redirect HTTP requests to the secure service.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1125
Other Tasks in the GUI
System Information in the GUI
In addition, all users (see Working with User Accounts, on page 977) who attempt to access the GUI on this
interface (either via HTTP or HTTPS ) must authenticate themselves via a standard username and passphrase
login page.
Note You must save the changes by using the commit command before you are able to access the GUI.
In the following example, the GUI is enabled for the Data 1 interface. The interfaceconfig command is used
to enable HTTP on port 80 and HTTPS on port 443. (The demonstration certificate is temporarily used for
HTTP until the certconfig command can be run. For more information, see “Installing Certificates on the
Email Gateway.”) HTTP requests to port 80 are configured to be automatically redirected to port 443 for the
Data1 interface.
System Information in the GUI
• On the System Overview page, you can:
• View historical graphs and tables showing some of the key system status and performance
information.
• View the version of the AsyncOS operating system installed on the email gateway.
• View a subset of key statistics.
• The System Status page provides a detailed representation of all real-time mail and DNS activity for
the system. You can also reset the counters for system statistics and view the last time the counters were
reset.
Gathering XML status from the GUI
View status through XML pages, or access XML status information programatically.
The XML Status feature provides a programmatic method to access email monitoring statistics. Note that
some newer browsers can also render XML data directly.
Information from the pages in the GUI in this table is also available as dynamic XML output by accessing
the corresponding URL:
GUI Page Name Corresponding XML status URL
Mail Status http:// hostname /xml/status
Host Mail Status for a Specified Host http:// hostname /xml/hoststatus?hostname= host
DNS Status http:// hostname /xml/dnsstatus
Top Incoming Domains http:// hostname /xml/topin
Top Outgoing Domains1 http:// hostname /xml/tophosts
1
The default sort order for this page is by number of active recipients. You can change the order by
appending “?sort= order ” to the URL, where order is conn_out , deliv_recip , soft_bounced , or
hard_bounced .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1126
CHAPTER 43
Advanced Network Configuration
This chapter contains the following sections:
• Media Settings on Ethernet Interfaces, on page 1127
• Network Interface Card Pairing/Teaming, on page 1128
• Virtual Local Area Networks (VLANs), on page 1131
• Direct Server Return, on page 1135
• Ethernet Interface’s Maximum Transmission Unit, on page 1139
• Accept or Reject ARP Replies with a Multicast Address, on page 1140
Media Settings on Ethernet Interfaces
Media settings for the ethernet interfaces can be accessed via the use of the etherconfig command. Each
ethernet interface is listed with its current setting. By selecting the interface, the possible media settings are
displayed. See Example of Editing Media Settings, on page 1127 for an example.
Using etherconfig to Edit Media Settings on Ethernet Interfaces
The etherconfig command can be used to set the duplex settings (full/half) as well as the speed (10/100/1000
Mbps) of ethernet interfaces. By default, interfaces automatically select the media settings; however, in some
cases you may wish to override this setting.
Note If you have completed the GUI’s System Setup Wizard (or the Command Line Interface systemsetup command)
as described in the “Setup and Installation” chapter and committed the changes, the default ethernet interface
settings should already be configured on your email gateway.
Some email gateways contain a fiber optic network interface option. If available, you will see two additional
ethernet interfaces (Data 3 and Data 4) in the list of available interfaces on these email gateways. These gigabit
fiber optic interfaces can be paired with the copper (Data 1, Data 2, and Management) interfaces in a
heterogeneous configuration. See Network Interface Card Pairing/Teaming, on page 1128.
Example of Editing Media Settings
mail3.example.com> etherconfig
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1127
Advanced Network Configuration
Network Interface Card Pairing/Teaming
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- PAIRING - View and configure NIC Pairing.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]> media
Ethernet interfaces:
1. Data 1 (Autoselect: <100baseTX full-duplex>) 00:06:5b:f3:ba:6d
2. Data 2 (Autoselect: <100baseTX full-duplex>) 00:06:5b:f3:ba:6e
3. Management (Autoselect: <100baseTX full-duplex>) 00:02:b3:c7:a2:da
Choose the operation you want to perform:
- EDIT - Edit an ethernet interface.
[]> edit
Enter the name or number of the ethernet interface you wish to edit.
[]> 2
Please choose the Ethernet media options for the Data 2 interface.
1. Autoselect
2. 10baseT/UTP half-duplex
3. 10baseT/UTP full-duplex
4. 100baseTX half-duplex
5. 100baseTX full-duplex
6. 1000baseTX half-duplex
7. 1000baseTX full-duplex
[1]> 5
Ethernet interfaces:
1. Data 1 (Autoselect: <100baseTX full-duplex>) 00:06:5b:f3:ba:6d
2. Data 2 (100baseTX full-duplex: <100baseTX full-duplex>) 00:06:5b:f3:ba:6e
3. Management (Autoselect: <100baseTX full-duplex>) 00:02:b3:c7:a2:da
Choose the operation you want to perform:
- EDIT - Edit an ethernet interface.
[]>
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- PAIRING - View and configure NIC Pairing.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]>
Network Interface Card Pairing/Teaming
NIC pairing allows you to combine any two physical data ports in order to provide a backup Ethernet interface
if the data path from the NIC to the upstream Ethernet port should fail. Basically, pairing configures the
Ethernet interfaces so that there is a primary interface and a backup interface. If the primary interface fails
(i.e. if the carrier between the NIC and the upstream node is disrupted), the backup interface becomes active
and an alert is sent. When the primary interface is up again, this interface will become active automatically.
Within the documentation for this product, NIC pairing is synonymous with NIC teaming.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1128
Advanced Network Configuration
NIC Pairing and VLANs
Note NIC pairing is not available on C170, C190 and C195 email gateways.
You can create more than one NIC pair, providing you have enough data ports. When creating pairs, you can
combine any two data ports. For example:
Data 1 and Data 2
Data 3 and Data 4
Data 2 and Data 3
etc.
Some email gateways contain a fiber optic network interface option. If available, you will see two additional
ethernet interfaces (Data 3 and Data 4) in the list of available interfaces on these email gateways. These gigabit
fiber optic interfaces can be paired with the copper (Data 1, Data 2, and Management) interfaces in a
heterogeneous configuration.
NIC Pairing and VLANs
VLANs (see Virtual Local Area Networks (VLANs), on page 1131) are only allowed on the primary interface.
NIC Pair Naming
When creating NIC pairs, you must specify a name to use to refer to the pair. NIC pairs created in versions
of AsyncOS prior to version 4.5 will automatically receive the default name of ‘Pair 1’ following an upgrade.
Any alerts generated regarding NIC pairing will reference the specific NIC pair by name.
NIC Pairing and Existing Listeners
If you enable NIC pairing on an interface that has listeners assigned to it, you are prompted to either delete,
reassign, or disable all listeners assigned to the backup interface.
Enabling NIC Pairing via the etherconfig Command
Note NIC pairing is not available on C170, C190 and C195 email gateways.
mail3.example.com> etherconfig
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- PAIRING - View and configure NIC Pairing.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1129
Advanced Network Configuration
Enabling NIC Pairing via the etherconfig Command
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]> pairing
Paired interfaces:
Choose the operation you want to perform:
- NEW - Create a new pairing.
[]> new
Please enter a name for this pair (Ex: "Pair 1"):
[]> Pair 1
Warning: The backup (Data 2) for the NIC Pair is currently configured with one or more
IP addresses. If you continue, the Data 2 interface will be deleted.
Do you want to continue? [N]> y
The interface you are deleting is currently used by listener "OutgoingMail".
What would you like to do?
1. Delete: Remove the listener and all its settings.
2. Change: Choose a new interface.
3. Ignore: Leave the listener configured for interface "Data 2" (the listener will be
disabled until you add a new interface named "Data 2" or edit the listener's settings).
[1]>
Listener OutgoingMail deleted for mail3.example.com.
Interface Data 2 deleted.
Paired interfaces:
1. Pair 1:
Primary (Data 1) Active, Link is up
Backup (Data 2) Standby, Link is up
Choose the operation you want to perform:
- DELETE - Delete a pairing.
- STATUS - Refresh status.
[]>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1130
Advanced Network Configuration
Virtual Local Area Networks (VLANs)
Virtual Local Area Networks (VLANs)
You can configure multiple virtual local area networks (VLANs) on any physical network port on the email
gateway.
You can use VLANs to:
• Increase the number of networks the email gateway can connect to beyond the number of physical
interfaces on the email gateway.
• Allow more networks to be defined on separate “ports” on existing listeners.
• Segment networks for security purposes, to ease administration, or increase bandwidth.
Example use case:
Two mail servers that are unable to communicate directly due to VLAN limitations can send mail through
the email gateway. The Data 2 interface on the email gateway is configured with VLAN1 and VLAN2. The
blue line shows mail coming from the sales network (VLAN1) to the appliance. The email gateway processes
the mail as normal and then, upon delivery, tags the packets with the destination VLAN2 information (red
line).
Using VLANs to Facilitate Communication Between Email Gateways
Figure 76: Using VLANs to Facilitate Communication Between Email Gateways
About Configuring VLANs
You can configure multiple VLANs on any physical network port on the email gateway, including “Data”
and “Management” ports and the fiber optic data ports available on some email gateway models. AsyncOS
supports up to 30 VLANs.
A physical port does not need an IP address configured in order to be in a VLAN. The physical port on which
a VLAN is created can have an IP that will receive non-VLAN traffic, so you can have both VLAN and
non-VLAN traffic on the same interface.
VLANs can be used with NIC pairing (available on paired NICs) and with Direct Server Return (DSR).
VLANs appear as dynamic “Data Ports” labeled in the format of: “VLAN DDDD” where the “DDDD” is the
ID and is an integer up to 4 digits long (VLAN 2, or VLAN 4094 for example). VLAN IDs must be unique
on your appli email gatewayance.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1131
Advanced Network Configuration
Managing VLANs
Related Topics
FTP, SSH, and SCP Access, on page 1297
Managing VLANs
You can create, edit and delete VLANs via the etherconfig command. Once created, a VLAN can be configured
via the Network > Interfaces page or the interfaceconfig command in the CLI. Remember to commit all
changes.
Creating a New VLAN via the etherconfig Command
In this example, two VLANs are created (named VLAN 31 and VLAN 34) on the Data 1 port:
mail3.example.com> etherconfig
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- PAIRING - View and configure NIC Pairing.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]> vlan
VLAN interfaces:
Choose the operation you want to perform:
- NEW - Create a new VLAN.
[]> new
VLAN ID for the interface (Ex: "34"):
[]> 34
Enter the name or number of the ethernet interface you wish bind to:
1. Data 1
2. Data 2
3. Management
[1]> 1
VLAN interfaces:
1. VLAN 34 (Data 1)
Choose the operation you want to perform:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1132
Advanced Network Configuration
Creating an IP Interface on a VLAN via the interfaceconfig Command
- NEW - Create a new VLAN.
- EDIT - Edit a VLAN.
- DELETE - Delete a VLAN.
[]> new
VLAN ID for the interface (Ex: "34"):
[]> 31
Enter the name or number of the ethernet interface you wish bind to:
1. Data 1
2. Data 2
3. Management
[1]> 1
VLAN interfaces:
1. VLAN 31 (Data 1)
2. VLAN 34 (Data 1)
Choose the operation you want to perform:
- NEW - Create a new VLAN.
- EDIT - Edit a VLAN.
- DELETE - Delete a VLAN.
[]>
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- PAIRING - View and configure NIC Pairing.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]>
Creating an IP Interface on a VLAN via the interfaceconfig Command
In this example, a new IP interface is created on the VLAN 31 ethernet interface.
Making changes to an interface may close your connection to the email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1133
Advanced Network Configuration
Creating an IP Interface on a VLAN via the interfaceconfig Command
mail3.example.com> interfaceconfig
Currently configured interfaces:
1. Data 1 (10.10.1.10/24: example.com)
2. Management (10.10.0.10/24: example.com)
Choose the operation you want to perform:
- NEW - Create a new interface.
- EDIT - Modify an interface.
- GROUPS - Define interface groups.
- DELETE - Remove an interface.
[]> new
Please enter a name for this IP interface (Ex: "InternalNet"):
[]> InternalVLAN31
Would you like to configure an IPv4 address for this interface (y/n)? [Y]>
IPv4 Address (Ex: 10.10.10.10):
[]> 10.10.31.10
Netmask (Ex: "255.255.255.0" or "0xffffff00"):
[255.255.255.0]>
Would you like to configure an IPv6 address for this interface (y/n)? [N]>
Ethernet interface:
1. Data 1
2. Data 2
3. Management
4. VLAN 31
5. VLAN 34
[1]> 4
Hostname:
[]> mail31.example.com
Do you want to enable SSH on this interface? [N]>
Do you want to enable FTP on this interface? [N]>
Do you want to enable HTTP on this interface? [N]>
Do you want to enable HTTPS on this interface? [N]>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1134
Advanced Network Configuration
Configuring VLANs Using the Web Interface
Currently configured interfaces:
1. Data 1 (10.10.1.10/24: example.com)
2. InternalVLAN31 (10.10.31.10/24: mail31.example.com)
3. Management (10.10.0.10/24: example.com)
Choose the operation you want to perform:
- NEW - Create a new interface.
- EDIT - Modify an interface.
- GROUPS - Define interface groups.
- DELETE - Remove an interface.
[]>
Configuring VLANs Using the Web Interface
After a VLAN is created using the etherconfig command, you can configure it using the Network > Listeners
page.
Direct Server Return
Direct Server Return (DSR) is a way of providing support for a light-weight load balancing mechanism to
load balance between multiple email gateways sharing the same Virtual IP (VIP).
DSR is implemented via an IP interface created on the “loopback” ethernet interface on the email gateway.
Note Configuring load balancing for email gateways is beyond the scope of this document
Enabling Direct Server Return
Enable DSR by enabling the “loopback” ethernet interface on each participating email gateway. Next, create
an IP interface on the loopback interface with a virtual IP (VIP) via the interfaceconfig command in
the CLI or via the Network > Interfaces page in the GUI. Finally, create a listener on the new IP interface via
the listenerconfig command in the CLI or via the Network > Listeners page in the GUI. Remember to
commit all changes.
Note Using the loopback interface prevents the email gateway from issuing ARP replies for that specific interface
When enabling DSR, the following rules apply:
All systems use the same Virtual IP (VIP) address
All systems must be on the same switch and subnet as the load balancer
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1135
Advanced Network Configuration
Enabling the Loopback Interface via the etherconfig Command
Figure 77: Using DSR to Load Balance Between Multiple Email Gatewayson a Switch
Using DSR to Load Balance Between Multiple Email Gateways on a Switch
Enabling the Loopback Interface via the etherconfig Command
Once enabled, the loopback interface is treated like any other interface (e.g. Data 1):
mail3.example.com> etherconfig
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- PAIRING - View and configure NIC Pairing.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]> loopback
Currently configured loopback interface:
Choose the operation you want to perform:
- ENABLE - Enable Loopback Interface.
[]> enable
Currently configured loopback interface:
1. Loopback
Choose the operation you want to perform:
- DISABLE - Disable Loopback Interface.
[]>
Choose the operation you want to perform:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1136
Advanced Network Configuration
Creating an IP Interface on Loopback via the interfaceconfig Command
- MEDIA - View and edit ethernet media settings.
- PAIRING - View and configure NIC Pairing.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]>
Creating an IP Interface on Loopback via the interfaceconfig Command
Create an IP interface on the loopback interface:
mail3.example.com> interfaceconfig
Currently configured interfaces:
1. Data 1 (10.10.1.10/24: example.com)
2. InternalV1 (10.10.31.10/24: mail31.example.com)
3. Management (10.10.0.10/24: example.com)
Choose the operation you want to perform:
- NEW - Create a new interface.
- EDIT - Modify an interface.
- GROUPS - Define interface groups.
- DELETE - Remove an interface.
[]> new
Please enter a name for this IP interface (Ex: "InternalNet"):
[]> LoopVIP
Would you like to configure an IPv4 address for this interface (y/n)? [Y]>
IPv4 Address (Ex: 10.10.10.10):
[]> 10.10.1.11
Netmask (Ex: "255.255.255.0" or "0xffffff00"):
[255.255.255.0]> 255.255.255.255
Would you like to configure an IPv6 address for this interface (y/n)? [N]>
Ethernet interface:
1. Data 1
2. Data 2
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1137
Advanced Network Configuration
Creating a Listener on the New IP Interface
3. Loopback
4. Management
5. VLAN 31
6. VLAN 34
[1]> 3
Hostname:
[]> example.com
Do you want to enable SSH on this interface? [N]>
Do you want to enable FTP on this interface? [N]>
Do you want to enable HTTP on this interface? [N]>
Do you want to enable HTTPS on this interface? [N]>
Currently configured interfaces:
1. Data 1 (10.10.1.10/24: example.com)
2. InternalV1 (10.10.31.10/24: mail31.example.com)
3. LoopVIP (10.10.1.11/24: example.com)
4. Management (10.10.0.10/24: example.com)
Choose the operation you want to perform:
- NEW - Create a new interface.
- EDIT - Modify an interface.
- GROUPS - Define interface groups.
- DELETE - Remove an interface.
[]>
Creating a Listener on the New IP Interface
Create a listener on the new IP interface via the GUI or the CLI. For example, the following figure shows the
newly created IP interface available in the Add Listener page in the GUI.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1138
Advanced Network Configuration
Ethernet Interface’s Maximum Transmission Unit
Figure 78: Creating a Listener on the New Loopback IP Interface
Ethernet Interface’s Maximum Transmission Unit
The maximum transmission unit (MTU) is the largest unit of data that an ethernet interface will accept. You
can decrease the MTU for an ethernet interface using the etherconfig command. The default MTU size is
1500 bytes, which is the largest MTU that the ethernet interface can accept.
To edit an interface’s MTU:
mail3.example.com> etherconfig
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- PAIRING - View and configure NIC Pairing.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]> mtu
Ethernet interfaces:
1. Data 1 mtu 1400
2. Data 2 default mtu 1500
3. Management default mtu 1500
Choose the operation you want to perform:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1139
Advanced Network Configuration
Accept or Reject ARP Replies with a Multicast Address
- EDIT - Edit an ethernet interface.
[]> edit
Enter the name or number of the ethernet interface you wish to edit.
[]> 2
Please enter a non-default (1500) MTU value for the Data 2 interface.
[]> 1200
Ethernet interfaces:
1. Data 1 mtu 1400
2. Data 2 mtu 1200
3. Management default mtu 1500
Choose the operation you want to perform:
- EDIT - Edit an ethernet interface.
[]>
Accept or Reject ARP Replies with a Multicast Address
You can now specify whether to accept or reject ARP replies with a multicast address. Use the MULTICAST
subcommand to configure this functionality.
The following example shows how to configure your email gateway to accept ARP replies with a multicast
address:
mail.example.com> etherconfig
Choose the operation you want to perform:
- MEDIA - View and edit ethernet media settings.
- VLAN - View and configure VLANs.
- LOOPBACK - View and configure Loopback.
- MTU - View and configure MTU.
- MULTICAST - Accept or reject ARP replies with a multicast address.
[]> multicast
ARP replies with a multicast address will be rejected.
Choose the operation you want to perform:
- ACCEPT - Accept ARP replies with a multicast address.
[]> accept
ARP replies with a multicast address will be accepted.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1140
CHAPTER 44
Logging
This chapter contains the following sections:
• Overview, on page 1141
• Log Types, on page 1151
• Log Subscriptions, on page 1206
Overview
• Understanding Log Files and Log Subscriptions, on page 1141
• Log Types, on page 1141
• Log Retrieval Methods, on page 1149
Understanding Log Files and Log Subscriptions
Logs are a compact, efficient method of gathering critical information about the email operations of AsyncOS.
These logs record information regarding activity on your email gateway. The information will vary depending
upon the log you view, for example, Bounce logs or Delivery logs.
Most logs are recorded in plain text (ASCII) format; however, delivery logs are formatted in binary for resource
efficiency. The ASCII text information is readable in any text editor.
Cisco offers the M-Series Cisco Secure Manager Email and Web Gateway for centralized reporting and
tracking tool for logs from multiple email gateways. See your Cisco representative for more information.
A log subscription associates a log type with a name, logging level, and other constraints such as size and
destination information; multiple subscriptions for the same log type are permitted.
Log Types
The log type indicates what information will be recorded within the generated log such as message data,
system statistics, binary or textual data. You select the log type when creating a log subscription. See Log
Subscriptions, on page 1206 for more information.
AsyncOS generates the following log types:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1141
Logging
Log Types
Table 119: Log Types
Log Description
Text Mail Logs Text mail logs record information regarding the operations of the email system.
For example, message receiving, message delivery attempts, open and closed
connections, bounces, TLS connections, and others.
qmail Format Mail Logs qmail format delivery logs record the same information regarding the operations
of the email system as delivery logs following, but stored in qmail format.
Delivery Logs Delivery logs record critical information about the email delivery operations
of the email gateway — for example, information regarding each recipient
delivery and bounce at the time of the delivery attempt. The log messages are
“stateless,” meaning that all associated information is recorded in each log
message and users need not reference previous log messages for information
about the current delivery attempt. Delivery logs are recorded in a binary
format for resource efficiency. Delivery Log files must be post-processed using
a provided utility to convert them to XML or CSV (comma-separated values)
format. The conversion tools are located at: https://supportforums.cisco.com/
document/33721/cisco-ironport-systems-contributed-tools
Bounce Logs Bounce logs record information about bounced recipients. The information
recorded for each bounced recipient includes: the message ID, the recipient
ID, the Envelope From address, the Envelope To address, the reason for the
recipient bounce, and the response code from the recipient host. In addition,
you can choose to log a fixed amount of each bounced recipient message. This
amount is defined in bytes and the default is zero.
Status Logs This log file records system statistics found in the CLI status commands,
including status detail and dnsstatus . The period of recording is set using the
setup subcommand in logconfig . Each counter or rate reported in status logs
is the value since the last time the counter was reset.
Domain Debug Logs Domain debug logs record the client and server communication during an
SMTP conversation between the email gateway and a specified recipient host.
This log type can be used to debug issues with specific recipient hosts. You
must specify the total number of SMTP sessions to record in the log file. As
sessions are recorded, this number decreases. You can stop domain debug
before all sessions have been recorded by deleting or editing the log
subscription.
Injection Debug Logs Injection debug logs record the SMTP conversation between the email gateway
and a specified host connecting to the system. Injection debug logs are useful
for troubleshooting communication problems between the Email Security
appliance and a host on the Internet.
System Logs System logs record the following: boot information, virtual email gateway
license expiration alerts, DNS status information, and comments users typed
using commit command. System logs are useful for troubleshooting the basic
state of the email gateway.
CLI Audit Logs The CLI audit logs record all CLI activity on the system.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1142
Logging
Log Types
Log Description
FTP Server Logs FTP logs record information about the FTP services enabled on the interface.
Connection details and user activity are recorded.
GUI Logs See HTTP Logs.
HTTP Logs HTTP logs record information about the HTTP and/or secure HTTP services
enabled on the interface. Because the graphical user interface (GUI) is accessed
via HTTP, the HTTP logs are ostensibly the GUI equivalent of the CLI Audit
logs. Session data (new session, session expired) and pages accessed in the
GUI are recorded.
These logs also include information about SMTP transactions, for example
information about scheduled reports emailed from the email gateway.
NTP Logs NTP logs record the conversation between the email gateway and any NTP
(Network Time Protocol) servers configured. For more information, see
“Editing the Network Time Protocol (NTP) Configuration (Time Keeping
Method)” in the “System Administration” chapter.
LDAP Debug Logs LDAP debug logs are meant for debugging LDAP installations. (See the “LDAP
Queries” chapter.) Useful information about the queries that the email gateway
is sending to the LDAP server are recorded here.
Anti-Spam Logs Anti-spam logs record the status of the anti-spam scanning feature of your
system, including the status on receiving updates of the latest anti-spam rules.
Also, any logs related to the Context Adaptive Scanning Engine are logged
here.
Anti-Spam Archive If you enabled an Anti-Spam scanning feature, messages that are scanned and
associated with the “archive message” action are archived here. The format is
an mbox-format log file. For more information about anti-spam engines, see
the “Anti-Spam” chapter.
Graymail Engine Logs Contains information about the graymail engine, status, configuration, and so
on. Most information is at Info or Debug level.
Graymail Archive Contains archived messages (the messages that are scanned and associated
with the “archive message” action). The format is an mbox-format log file.
Anti-Virus Logs AntiVirus logs record the status of the anti-virus scanning feature of your
system, including the status on receiving updates of the latest anti-virus identity
files.
Anti-Virus Archive If you enabled an anti-virus engine, messages that are scanned and associated
with the “archive message” action are archived here. The format is an
mbox-format log file. For more information, see the “Anti-Virus” chapter.
AMP Engine Logs The AMP Engine logs record the status of the Advanced Malware Protection
features of the system. For more information, see File Reputation Filtering
and File Analysis, on page 481
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1143
Logging
Log Types
Log Description
AMP Archive If you have configured mail policies to archive messages that Advanced
Malware Protection engine has found to have attachments that are unscannable
or contain malware, those messages are archived here. The format is an
mbox-format log file.
Scanning Logs The scanning log contains all LOG and COMMON messages for scanning
engines (see Alerts, on page 1043). This is typically application faults, alert sent,
alert failed, and log error messages. This log does not apply to system-wide
alerts.
Spam Quarantine Logs Spam Quarantine logs record actions associated with the Spam Quarantine
processes.
Spam Quarantine GUI Logs Spam Quarantine logs record actions associated with the Spam Quarantine
including configuration via the GUI, end user authentication, and end user
actions (releasing email, etc.).
SMTP Conversation Logs The SMTP conversation log records all parts of incoming and outgoing SMTP
conversations.
Safe/Block Lists Logs Safelist/blocklist logs record data about the safelist/blocklist settings and
database.
Reporting Logs Reporting logs record actions associated with the processes of the centralized
reporting service.
Reporting Query Logs Reporting query logs record actions associated with the reporting queries that
are run on the email gateway.
Updater Logs The updater log records events related to updates for system services, such as
McAfee Anti-Virus definition updates.
Tracking Logs Tracking logs record actions associated with the processes of the tracking
service. Tracking logs are a subset of the mail logs.
Authentication Logs The authentication log records successful user logins and unsuccessful login
attempts.
Configuration History Logs Configuration history logs record the following information: What changes
were made on the email gateway, and when were the changes made? A new
configuration history log is created each time a user commits a change.
Upgrade Logs Status information about upgrade download and installation.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1144
Logging
Log Types
Log Description
API Logs API logs record various events related to the AsyncOS API for the email
gateway, for example:
• API has started or stopped
• Connection to the API failed or closed (after providing response)
• Authentication succeeded or failed
• Request contains errors
• Error while communicating network configuration changes with AsyncOS
API
Consolidated Event Logs The Consolidated Event Logs summarizes each message event in a single log
line. Using this log type you can reduce the number of bytes of data (log
information) sent to a Security Information and Event Management (SIEM)
vendor or application for analysis. The logs are in the Common Event Format
(CEF) log message format that is widely used by most SIEM vendors.
CSN Logs The CSN logs contain details about the CSN data uploads. The CSN data (
email gateway and feature usage details can be seen at the trace level.
Advanced Phishing The Advanced Phishing Protection logs contain information related to Cisco
Protection Logs Advanced Phishing Protection Cloud Service. Most information is at the Info
or Critical level.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1145
Logging
Log Type Characteristics
Log Description
Audit Logs The Audit logs record AAA (Authentication, Authorization, and Accounting)
events.
Some of the audit log details are as follows:
• User - Logon
• User - Logon failed incorrect password
• User - Logon failed unknown username
• User - Logon failed account expired
• User – Logoff
• User - Lockout
• User - Activated
• User - Password change
• User - Password reset
• User - Security settings/profile change
• User - Created
• User - Deleted or modified
• User Configuration - Configuration changes made by the user.
• Group/Role - Deletion or modified
• Group /Role - Permissions change
• Quarantine - Actions performed on messages in the quarantine.
CSA Logs The CSA logs contain information related to the Cisco Secure Awareness
cloud service. Most information is at the Info or Debug level.
Log Type Characteristics
The following table summarizes the different characteristics of each log type.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1146
Logging
Log Type Characteristics
Table 120: Log Type Comparison
Contains
Tra State Reco Reco Reco Perio Mess Deli Indivi Indivi Injec Hea Deli Con
nsac less rded rded rded dic age very dual dual tion der very figur
tional as as as Status Recei Infor Hard Soft SMTP Log SMTP ation
text mbox binary Inform ving mation Bounces Bounces Conve ging Conve Inform
file ation Inform rsation rsation ation
ation
Mail • • • • • • • •
Logs
qmail • • • • • •
Format
Delivery
Logs
Delivery • • • • • •
Log
Bounce • • • • •
Logs
Status • • •
Logs
Domain • • • • • •
Debug
Logs
Injection • • • •
Debug
Logs
System • • •
Logs
CLI • • •
Audit
Logs
FTP • • •
Server
Logs
HTTP • • •
Logs
NTP • • •
Logs
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1147
Logging
Log Type Characteristics
Contains
Tra State Reco Reco Reco Perio Mess Deli Indivi Indivi Injec Hea Deli Con
nsac less rded rded rded dic age very dual dual tion der very figur
tional as as as Status Recei Infor Hard Soft SMTP Log SMTP ation
text mbox binary Inform ving mation Bounces Bounces Conve ging Conve Inform
file ation Inform rsation rsation ation
ation
LDAP • •
Logs
Anti-spam • • •
Logs
Anti-Spam •
Archive
Graymail • • •
Engine
Logs
Graymail •
Archive
Anti-virus • • •
Logs
Anti-Virus •
Archive
AMP • • •
Engine
Logs
AMP •
Archive
Scanning • • • •
Logs
Spam • • •
Quarantine
Spam • • •
Quarantine
GUI
Safe/Block • • •
Lists
Logs
Reporting • • •
Logs
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1148
Logging
Log Retrieval Methods
Contains
Tra State Reco Reco Reco Perio Mess Deli Indivi Indivi Injec Hea Deli Con
nsac less rded rded rded dic age very dual dual tion der very figur
tional as as as Status Recei Infor Hard Soft SMTP Log SMTP ation
text mbox binary Inform ving mation Bounces Bounces Conve ging Conve Inform
file ation Inform rsation rsation ation
ation
Reporting • • •
Query
Logs
Updater •
Logs
Tracking • • • • • • • •
Logs
Authentication • •
Logs
Config • • •
uration
History
Logs
API Logs • •
Consolidated • • • •
Event
Logs
CSN • • • •
Logs
Advanced • •
Phishing
Protection
Logs
Audit •
Logs
Log Retrieval Methods
Log files can be retrieved based upon one of the following file transfer protocols. You set the protocol while
creating or editing the log subscription in the GUI or via the logconfig command during the log subscription
process.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1149
Logging
Log Filenames and Directory Structure
Note When using a Log Push method on a particular log, that log will be locally unavailable for troubleshooting
or searching via the CLI.
Table 121: Log Transfer Protocols
Manually Download This method lets you access log files at any time by clicking a link to the log
directory on the Log Subscriptions page, then clicking the log file to access.
Depending on your browser, you can view the file in a browser window, or open
or save it as a text file. This method uses the HTTP(S) protocol and is the default
retrieval method.
Note Using this method, you cannot retrieve logs for any computer in a
cluster, regardless of level (machine, group, or cluster), even if you
specify this method in the CLI.
FTP Push This method periodically pushes log files to an FTP server on a remote computer.
The subscription requires a username, passphrase, and destination directory on
the remote computer. Log files are transferred based on a rollover schedule set
by you.
SCP Push This method periodically pushes log files to an SCP server on a remote computer.
This method requires an SSH SCP server on a remote computer using the SSH1
or SSH2 protocol. The subscription requires a username, SSH key, and destination
directory on the remote computer. Log files are transferred based on a rollover
schedule set by you.
Syslog Push This method sends log messages to a remote syslog server. This method conforms
to RFC 3164. You must submit a hostname for the syslog server and choose to
use either UDP or TCP for log transmission. The port used is 514. A facility can
be selected for the log; however, a default for the log type is pre-selected in the
dropdown menu. Only text-based logs can be transferred using syslog push.
[Only for Consolidated This method periodically pushes log files to the Amazon Simple Storage Service
Event Logs] AWS S3 (S3) Bucket available on the Amazon Web Services (AWS) public cloud. The
Push subscription requires an S3 bucket name, access key, and a secret key to access
the Amazon S3 bucket. You can set a rollover schedule to transfer the log files.
Note Make sure that you have a valid AWS S3 bucket to use this retrieval
method. For more information, refer to the AWS user documentation
at https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_
access-keys.html.
Log Filenames and Directory Structure
AsyncOS creates a directory for each log subscription based on the log subscription name. The actual name
of the log file in the directory is composed of the log filename specified by you, the timestamp when the log
file was started, and a single-character status code. The filename of logs are made using the following formula:
/LogSubscriptionName/[email protected]
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1150
Logging
Log Rollover and Transfer Schedule
Status codes may be .current or .s (signifying saved). You should only transfer or delete log files with the
saved status.
Log Rollover and Transfer Schedule
Log files are created by log subscriptions, and are rolled over (and transferred, if a push-based retrieval option
is selected) based on the first user-specified condition reached: maximum file size or scheduled rollover. Use
the logconfig command in the CLI or the Log Subscriptions page in the GUI to configure both the maximum
file size and time interval for scheduled rollovers. You can also use the Rollover Now button in the GUI or
the rollovernow command in the CLI to rollover selected log subscriptions. See Rolling Over Log Subscriptions,
on page 1211 for more information on scheduling rollovers.
Logs retrieved using manual download are saved until they reach the maximum number you specify (the
default is 10 files) or until the system needs more space for log files.
Logs Enabled by Default
Your email gateway is pre-configured with many log subscriptions enabled by default (other logs may be
configured depending on which license keys you have applied). By default, the retrieval method is “Manually
Download.”
All pre-configured log subscriptions have a Log Level of 3, except for error_logs which is set at 1 so that it
will contain only errors. See Log Levels, on page 1207 for more information. For information about creating
new log subscriptions, or modifying existing ones, see Log Subscriptions, on page 1206.
Log Types
• Using Text Mail Logs, on page 1152
• Using Delivery Logs, on page 1166
• Using Bounce Logs, on page 1168
• Using Status Logs, on page 1169
• Using Domain Debug Logs, on page 1172
• Using Injection Debug Logs, on page 1173
• Using System Logs, on page 1174
• Using CLI Audit Logs, on page 1175
• Using FTP Server Logs, on page 1175
• Using HTTP Logs, on page 1176
• Using NTP Logs, on page 1177
• Using Scanning Logs, on page 1177
• Using Anti-Spam Logs, on page 1178
• Using Graymail Logs, on page 1178
• Using Anti-Virus Logs, on page 1179
• Using AMP Engine Logs, on page 1179
• Using Spam Quarantine Logs, on page 1184
• Using Spam Quarantine GUI Logs, on page 1185
• Using LDAP Debug Logs, on page 1186
• Using Safelist/Blocklist Logs, on page 1187
• Using Reporting Logs, on page 1188
• Using Reporting Query Logs, on page 1189
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1151
Logging
Timestamps in Log Files
• Using Updater Logs, on page 1190
• Understanding Tracking Logs, on page 1191
• Using Authentication Logs, on page 1191
• Using Configuration History Logs, on page 1192
• Using External Threat Feeds Engine Logs, on page 1193
• Using Consolidated Event Logs, on page 1194
• Using CSN Logs, on page 1201
• Using Advanced Phishing Protection Logs, on page 1202
• Using Audit Logs, on page 1202
• Using CSA Logs, on page 1205
Timestamps in Log Files
The following log files include the begin and end date of the log itself, the version of AsyncOS, and the GMT
offset (provided in seconds, and only at the beginning of the log):
• Anti-Virus log
• LDAP log
• System log
• Mail log
Using Text Mail Logs
They contain details of email receiving, email delivery and bounces. These logs are a useful source of
information to understand delivery of specific messages and to analyze system performance.
These logs do not require any special configuration. However, you must configure the system properly to
view attachment names, and attachment names may not always be logged. For information, see Enabling
Message Tracking, on page 915 and Message Tracking Overview , on page 915.
Information displayed in text mail logs is shown in the following table:
Table 122: Text Mail Log Statistics
Statistic Description
ICID Injection Connection ID. This is a numerical identifier for an individual SMTP connection
to the system, over which 1 to thousands of individual messages may be sent.
DCID Delivery Connection ID. This is a numerical identifier for an individual SMTP connection
to another server, for delivery of 1 to thousands of messages, each with some or all of
their RIDs being delivered in a single message transmission.
RCID RPC Connection ID. This is a numerical identifier for an individual RPC connection to
the Spam quarantine. It is used to track messages as they are sent to and from the Spam
Quarantine.
MID Message ID: Use this to track messages as they flow through the logs.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1152
Logging
Interpreting a Text Mail Log
Statistic Description
RID Recipient ID: Each message recipient is assigned an ID.
New New connection initiated.
Start New message started.
Interpreting a Text Mail Log
Use the following sample as a guide to interpret log files.
Note Individual lines in log files are NOT numbered. They are numbered here only for sample purposes.
Table 123: Text Mail Log Detail
1
Mon Apr 17 19:56:22 2003 Info:
New SMTP ICID 5 interface Management (10.1.1.1)
address 10.1.1.209 reverse dns host remotehost.com verified yes
2
Mon Apr 17 19:57:20 2003 Info:
Start MID 6 ICID 5
3
Mon Apr 17 19:57:20 2003 Info:
MID 6 ICID 5 From: <[email protected]>
4
Mon Apr 17 19:58:06 2003 Info:
MID 6 ICID 5 RID 0 To: <[email protected]>
5
Mon Apr 17 19:59:52 2003 Info:
MID 6 ready 100 bytes from <[email protected]>
6
Mon Apr 17 19:59:59 2003 Info: ICID 5 close
7
Mon Mar 31 20:10:58 2003 Info:
New SMTP DCID 8 interface 192.168.42.42 address 10.5.3.25
8
Mon Mar 31 20:10:58 2003 Info:
Delivery start DCID 8 MID 6 to RID [0]
9
Mon Mar 31 20:10:58 2003 Info:
Message done DCID 8 MID 6 to RID [0]
10
Mon Mar 31 20:11:03 2003 Info: DCID 8 close
Use the following table as a guide to reading the preceding log file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1153
Logging
Examples of Text Mail Log Entries
Table 124: Detail of Text Mail Log Example
Line Description
Number
1 A new connection is initiated into the system and assigned an Injection ID (ICID) of “5.” The
connection was received on the Management IP interface and was initiated from the remote
host at 10.1.1.209.
2 The message was assigned a Message ID (MID) of “6” after the MAIL FROM command is
issued from the client.
3 The sender address is identified and accepted.
4 The recipient is identified and assigned a Recipient ID (RID) of “0.”
5 MID 5 is accepted, written to disk, and acknowledged.
6 Receiving is successful and the receiving connection closes.
7 Next the message delivery process starts. It is assigned a Delivery Connection ID (DCID) of
“8” from 192.168.42.42 and to 10.5.3.25.
8 The message delivery starts to RID “0.”
9 Delivery is successful for MID 6 to RID “0.”
10 The delivery connection closes.
Examples of Text Mail Log Entries
Following are some sample log entries based on various situations.
Message Injection and Delivery
A message is injected into the email gateway for a single recipient. The message is successfully delivered.
Wed Jun 16 21:42:34 2004 Info: New SMTP ICID 282204970 interface mail.example.com
(1.2.3.4) address 2.3.4.5 reverse dns host unknown verified no
Wed Jun 16 21:42:34 2004 Info: ICID 282204970 SBRS None
Wed Jun 16 21:42:35 2004 Info: Start MID 200257070 ICID 282204970
Wed Jun 16 21:42:35 2004 Info: MID 200257070 ICID 282204970 From: <[email protected]>
Wed Jun 16 21:42:36 2004 Info: MID 200257070 ICID 282204970 RID 0 To: <[email protected]>
Wed Jun 16 21:42:38 2004 Info: MID 200257070 Message-ID
'<[email protected]>'
Wed Jun 16 21:42:38 2004 Info: MID 200257070 Subject 'Hello'
Wed Jun 16 21:42:38 2004 Info: MID 200257070 ready 24663 bytes from <[email protected]>
Wed Jun 16 21:42:38 2004 Info: MID 200257070 antivirus negative
Wed Jun 16 21:42:38 2004 Info: MID 200257070 queued for delivery
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1154
Logging
Successful Message Delivery
Wed Jun 16 21:42:38 2004 Info: New SMTP DCID 2386069 interface 1.2.3.4 address 1.2.3.4
Wed Jun 16 21:42:38 2004 Info: Delivery start DCID 2386069 MID 200257070 to RID [0]
Wed Jun 16 21:42:38 2004 Info: ICID 282204970 close
Wed Jun 16 21:42:38 2004 Info: Message done DCID 2386069 MID 200257070 to RID [0]
[('X-SBRS', 'None')]
Wed Jun 16 21:42:38 2004 Info: MID 200257070 RID [0] Response 2.6.0
<[email protected]> Queued mail for delivery
Wed Jun 16 21:42:43 2004 Info: DCID 2386069 close
Successful Message Delivery
Mon Mar 31 20:10:58 2003 Info: New SMTP DCID 5 interface 172.19.0.11 address
63.251.108.110
Mon Mar 31 20:10:58 2003 Info: Delivery start DCID 5 MID 4 to RID [0]
Mon Mar 31 20:10:58 2003 Info: Message done DCID 5 MID 4 to RID [0]
Mon Mar 31 20:11:03 2003 Info: DCID 5 close
Unsuccessful Message Delivery (Hard Bounce)
A message with two recipients is injected into the email gateway. Upon delivery, the destination host returns
a 5 XX error, which indicates that the message cannot be delivered to either recipient. The email gateway
notifies the sender and removes the recipients from the queue.
Mon Mar 31 20:00:23 2003 Info: New SMTP DCID 3 interface 172.19.0.11 address
64.81.204.225
Mon Mar 31 20:00:23 2003 Info: Delivery start DCID 3 MID 4 to RID [0, 1]
Mon Mar 31 20:00:27 2003 Info: Bounced: DCID 3 MID 4 to RID 0 - 5.1.0 - Unknown address
error ('550', ['<[email protected]>... Relaying denied']) []
Mon Mar 31 20:00:27 2003 Info: Bounced: DCID 3 MID 4 to RID 1 - 5.1.0 - Unknown address
error ('550', ['<[email protected]>... Relaying denied']) []
Mon Mar 31 20:00:32 2003 Info: DCID 3 close
Soft Bounce Followed by Successful Delivery
A message is injected into the email gateway. On the first delivery attempt, the message soft bounces and is
queued for future delivery. On the second attempt, the message is successfully delivered.
Mon Mar 31 20:10:58 2003 Info: New SMTP DCID 5 interface 172.19.0.11 address
63.251.108.110
Mon Mar 31 20:00:23 2003 Info: Delivery start DCID 3 MID 4 to RID [0, 1]
Mon Mar 31 20:00:23 2003 Info: Delayed: DCID 5 MID 4 to RID 0 - 4.1.0 - Unknown address
error ('466', ['Mailbox temporarily full.'])[]
Mon Mar 31 20:00:23 2003 Info: Message 4 to RID [0] pending till Mon Mar 31 20:01:23
2003
Mon Mar 31 20:01:28 2003 Info: DCID 5 close
Mon Mar 31 20:01:28 2003 Info: New SMTP DCID 16 interface PublicNet address 172.17.0.113
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1155
Logging
Message Scanning Results for the scanconfig Command
Mon Mar 31 20:01:28 2003 Info: Delivery start DCID 16 MID 4 to RID [0]
Mon Mar 31 20:01:28 2003 Info: Message done DCID 16 MID 4 to RID [0]
Mon Mar 31 20:01:33 2003 Info: DCID 16 close
Message Scanning Results for the scanconfig Command
You can use the scanconfig command to determine the system behavior when a message can not be
deconstructed into its component parts (when removing attachments). The Options are Deliver , Bounce , or
Drop .
The following example shows the Text Mail log with scanconfig set to Deliver .
Tue Aug 3 16:36:29 2004 Info: MID 256 ICID 44784 From: <[email protected]>
Tue Aug 3 16:36:29 2004 Info: MID 256 ICID 44784 RID 0 To: <[email protected]>
Tue Aug 3 16:36:29 2004 Info: MID 256 Message-ID '<[email protected]>'
Tue Aug 3 16:36:29 2004 Info: MID 256 Subject 'Virus Scanner Test #22'
Tue Aug 3 16:36:29 2004 Info: MID 256 ready 1627 bytes from <[email protected]>
Tue Aug 3 16:36:29 2004 Warning: MID 256, Message Scanning Problem: Continuation line
seen before first header
Tue Aug 3 16:36:29 2004 Info: ICID 44784 close
Tue Aug 3 16:36:29 2004 Info: MID 256 antivirus positive 'EICAR-AV-Test'
Tue Aug 3 16:36:29 2004 Info: Message aborted MID 256 Dropped by antivirus
Tue Aug 3 16:36:29 2004 Info: Message finished MID 256 done
The following example shows the Text Mail log with scanconfig set to drop .
Tue Aug 3 16:38:53 2004 Info: Start MID 257 ICID 44785
Tue Aug 3 16:38:53 2004 Info: MID 257 ICID 44785 From: [email protected]
Tue Aug 3 16:38:53 2004 Info: MID 257 ICID 44785 RID 0 To: <[email protected]>
Tue Aug 3 16:38:53 2004 Info: MID 257 Message-ID '<[email protected]>'
Tue Aug 3 16:38:53 2004 Info: MID 25781 Subject 'Virus Scanner Test #22'
Tue Aug 3 16:38:53 2004 Info: MID 257 ready 1627 bytes from <[email protected]>
Tue Aug 3 16:38:53 2004 Warning: MID 257, Message Scanning Problem: Continuation line
seen before first header
Tue Aug 3 16:38:53 2004 Info: Message aborted MID 25781 Dropped by filter 'drop_zip_c'
Tue Aug 3 16:38:53 2004 Info: Message finished MID 257 done
Tue Aug 3 16:38:53 2004 Info: ICID 44785 close
Message with Attachment
In this example, a content filter with condition “Message Body Contains” has been configured to enable
identification of attachment names:
Sat Apr 23 05:05:42 2011 Info: New SMTP ICID 28 interface Management (192.0.2.10)
address 224.0.0.10 reverse dns host test.com verified yes
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1156
Logging
Successful Message Delivery with DANE Support
Sat Apr 23 05:05:42 2011 Info: ICID 28 ACCEPT SG UNKNOWNLIST match sbrs[-1.0:10.0]
SBRS 0.0
Sat Apr 23 05:05:42 2011 Info: Start MID 44 ICID 28
Sat Apr 23 05:05:42 2011 Info: MID 44 ICID 28 From: <[email protected]>
Sat Apr 23 05:05:42 2011 Info: MID 44 ICID 28 RID 0 To: <[email protected]>
Sat Apr 23 05:05:42 2011 Info: MID 44 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>'
Sat Apr 23 05:05:42 2011 Info: MID 44 Subject 'Message 001'
Sat Apr 23 05:05:42 2011 Info: MID 44 ready 240129 bytes from <[email protected]>
Sat Apr 23 05:05:42 2011 Info: MID 44 matched all recipients for per-recipient
policy DEFAULT in the inbound table
Sat Apr 23 05:05:42 2011 Info: ICID 28 close
Sat Apr 23 05:05:42 2011 Info: MID 44 interim verdict using engine: CASE
spam negative
Sat Apr 23 05:05:42 2011 Info: MID 44 using engine: CASE spam negative
Sat Apr 23 05:05:43 2011 Info: MID 44 attachment 'Banner.gif'
Sat Apr 23 05:05:43 2011 Info: MID 44 attachment '=D1=82=D0=B5=D1=81=D1=82.rst'
Sat Apr 23 05:05:43 2011 Info: MID 44 attachment 'Test=20Attachment.docx'
Sat Apr 23 05:05:43 2011 Info: MID 44 queued for delivery
Note that the second of the three attachments is Unicode. On terminals that cannot display Unicode, these
attachments are represented in quoted-printable format.
Successful Message Delivery with DANE Support
A message reaches the email gateway for a single recipient. The email gateway requests for a secure DNS
MX record, DNS A record, and a TLSA record from the DNS server. If you select DANE as "Mandatory",
the TLSA record is validated against the X.509 certificate value of the recipient's domain. If the TLSA record
validation is successful, the message is delivery to the recipient.
Tue Nov 13 12:13:33 2018 Debug: Trying DANE MANDATORY for example.org
Tue Nov 13 12:13:33 2018 Debug: SECURE MX record(mail.example.org) found for example.org
Tue Nov 13 12:13:33 2018 Debug: DNS query: Q('mail.example.org', 'CNAME')
Tue Nov 13 12:13:33 2018 Debug: DNS query: QN('mail.example.org', 'CNAME',
'recursive_nameserver0.parent')
Tue Nov 13 12:13:33 2018 Debug: DNS query: QIP ('mail.example.org','CNAME','8.8.8.8',60)
Tue Nov 13 12:13:33 2018 Debug: DNS query: Q ('mail.example.org', 'CNAME', '8.8.8.8')
Tue Nov 13 12:13:34 2018 Debug: DNSSEC Response data([], , 0, 1799)
Tue Nov 13 12:13:34 2018 Debug: Received NODATA for domain mail.example.org type CNAME
Tue Nov 13 12:13:34 2018 Debug: No CNAME record(NoError) found for domain(mail.example.org)
Tue Nov 13 12:13:34 2018 Debug: SECURE A record (4.31.198.44) found for
MX(mail.example.org) in example.org
Tue Nov 13 12:13:34 2018 Info: New SMTP DCID 92 interface 10.10.1.191 address 4.31.198.44
port 25
Tue Nov 13 12:13:34 2018 Info: ICID 13 lost
Tue Nov 13 12:13:34 2018 Info: ICID 13 close
Tue Nov 13 12:13:34 2018 Debug: DNS query: Q('_25._tcp.mail.example.org', 'TLSA')
Tue Nov 13 12:13:34 2018 Debug: DNS query: QN('_25._tcp.mail.example.org', 'TLSA',
'recursive_nameserver0.parent')
Tue Nov 13 12:13:34 2018 Debug: DNS query: QIP
('_25._tcp.mail.example.org','TLSA','8.8.8.8',60)
Tue Nov 13 12:13:34 2018 Debug: DNS query: Q ('_25._tcp.mail.example.org', 'TLSA', '8.8.8.8')
Tue Nov 13 12:13:35 2018 Debug: DNSSEC Response data(['0301010c72ac70b745ac19998811b13
1d662c9ac69dbdbe7cb23e5b514b56664c5d3d6'], secure, 0, 1799)
Tue Nov 13 12:13:35 2018 Debug: DNS encache (_25._tcp.mail.example.org, TLSA,
[(2550119024205761L, 0,
'SECURE', '0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6')])
Tue Nov 13 12:13:35 2018 Debug: SECURE TLSA Record found for MX(mail.example.org) in
example.org
Tue Nov 13 12:13:36 2018 Info: DCID 92 Certificate verification successful
Tue Nov 13 12:13:36 2018 Info: DCID 92 TLS success protocol TLSv1.2 cipher
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1157
Logging
Message Delivery Failed due to Certificate Verification Failure
Tue Nov 13 12:13:36 2018 Info: DCID 92 TLS success protocol TLSv1.2 cipher
ECDHE-RSA-AES256-GCM-SHA384 for example.org
Tue Nov 13 12:13:36 2018 Info: Delivery start DCID 92 MID 23 to RID [0]
Message Delivery Failed due to Certificate Verification Failure
A message reaches the email gateway for a single recipient. The email gateway requests for a secure DNS
MX record, DNS A record, and a TLSA record from the DNS server. If you select DANE as "Mandatory",
the TLSA record is validated against the X.509 certificate value of the recipient's domain. If the certificate
verification fails, the message is delivered at a later time. If secure TLSA record is not found, the message is
bounced.
Wed Nov 14 05:52:08 2018 Debug: DNS query: QN('server1.example.net', 'CNAME',
'recursive_nameserver0.parent')
Wed Nov 14 05:52:08 2018 Debug: DNS query: QIP
('server1.example.net','CNAME','10.10.2.184',60)
Wed Nov 14 05:52:08 2018 Debug: DNS query: Q ('server1.example.net', 'CNAME', '10.10.2.184')
Wed Nov 14 05:52:08 2018 Debug: DNSSEC Response data([], , 0, 284)
Wed Nov 14 05:52:08 2018 Debug: Received NODATA for domain server1.example.net type CNAME
Wed Nov 14 05:52:08 2018 Debug: No CNAME record(NoError) found for domain(server1.example.net)
Wed Nov 14 05:52:08 2018 Debug: Secure CNAME(server1.example.net) found for
MX(someone.cs2.example.net)
in example.net
Wed Nov 14 05:52:08 2018 Debug: SECURE A record (10.10.1.198) found for
MX(someone.cs2.example.net)
in example.net
Wed Nov 14 05:52:08 2018 Info: New SMTP DCID 102 interface 10.10.1.191 address 10.10.1.198
port 25
Wed Nov 14 05:52:08 2018 Debug: Fetching TLSA records with CNAME(server1.example.net) for
MX(someone.cs2.example.net) in example.net
Wed Nov 14 05:52:08 2018 Debug: DNS query: Q('_25._tcp.server1.example.net', 'TLSA')
Wed Nov 14 05:52:08 2018 Debug: SECURE TLSA Record found for MX(server1.example.net) in
example.net
Wed Nov 14 05:52:08 2018 Debug: DCID 102 All TLSA records failed for certificate not trusted
Wed Nov 14 05:52:08 2018 Debug: Fetching TLSA records with initial
name(someone.cs2.example.net)
in example.net
Wed Nov 14 05:52:08 2018 Debug: DNS query: Q('_25._tcp.someone.cs2.example.net', 'TLSA')
Wed Nov 14 05:52:08 2018 Debug: SECURE TLSA Record found for MX(someone.cs2.example.net)
in example.net
Wed Nov 14 05:52:08 2018 Info: DCID 102 Certificate verification successful
Wed Nov 14 05:52:08 2018 Info: DCID 102 TLS success protocol TLSv1.2 cipher
DHE-RSA-AES128-SHA256
for example.net
Wed Nov 14 05:52:08 2018 Info: Delivery start DCID 102 MID 26 to RID [0]
Wed Nov 14 05:52:08 2018 Info: Message done DCID 102 MID 26 to RID [0]
Wed Nov 14 05:52:08 2018 Info: MID 26 RID [0] Response 'ok: Message 31009 accepted'
Wed Nov 14 05:52:08 2018 Info: Message finished MID 26 done
Wed Nov 14 06:36:22 2018 Debug: Trying DANE MANDATORY for example.net
Wed Nov 14 06:36:22 2018 Debug: SECURE MX record(someone.cs2.example.net) found for
example.net
Wed Nov 14 06:36:22 2018 Debug: DNS query: Q('someone.cs2.example.net', 'CNAME')
Wed Nov 14 06:36:22 2018 Debug: DNS query: QN('someone.cs2.example.net', 'CNAME',
'recursive_nameserver0.parent')
Wed Nov 14 06:36:22 2018 Debug: DNS query: QIP
('someone.cs2.example.net','CNAME','10.10.2.184',60)
Wed Nov 14 06:36:22 2018 Debug: DNS query: Q ('someone.cs2.example.net', 'CNAME',
'10.10.2.184')
Wed Nov 14 06:36:22 2018 Debug: DNSSEC Response data(['mail.example2.net.'], secure, 0,
3525)
Wed Nov 14 06:36:22 2018 Debug: DNS encache (someone.cs2.example.net, CNAME,
[(2692348132363369L, 0,
'SECURE', 'mail.example2.net')])
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1158
Logging
Message Delivery Failed due to Invalid TLSA Record
Wed Nov 14 06:36:22 2018 Debug: DNS query: Q('mail.example2.net', 'CNAME')
Wed Nov 14 06:36:22 2018 Debug: DNS query: QN('mail.example2.net', 'CNAME',
'recursive_nameserver0.parent')
Wed Nov 14 06:36:22 2018 Debug: DNS query: QIP ('mail.example2.net','CNAME','10.10.2.184',60)
Wed Nov 14 06:36:22 2018 Debug: DNS query: Q ('mail.example2.net', 'CNAME', '10.10.2.184')
Wed Nov 14 06:36:22 2018 Debug: DNSSEC Response data([], , 0, 225)
Wed Nov 14 06:36:22 2018 Debug: Received NODATA for domain mail.example2.net type CNAME
Wed Nov 14 06:36:22 2018 Debug: No CNAME record(NoError) found for domain(mail.example2.net)
Wed Nov 14 06:36:22 2018 Debug: Secure CNAME(mail.example2.net) found for
MX(someone.cs2.example.net)
in example.net
Wed Nov 14 06:36:22 2018 Debug: INSECURE A record (10.10.1.197) found for
MX(someone.cs2.example.net)
in example.net
Wed Nov 14 06:36:22 2018 Debug: Fetching TLSA records with initial
name(someone.cs2.example.net) in example.net
Wed Nov 14 06:36:22 2018 Info: New SMTP DCID 104 interface 10.10.1.191 address 10.10.1.197
port 25
Wed Nov 14 06:36:36 2018 Debug: DNS query: Q('_25._tcp.someone.cs2.example.net', 'TLSA')
Wed Nov 14 06:36:36 2018 Debug: SECURE TLSA Record found for MX(someone.cs2.example.net)
in example.net
Wed Nov 14 06:36:36 2018 Debug: DCID 104 All TLSA records failed for certificate not trusted
Wed Nov 14 06:36:36 2018 Info: MID 27 DCID 104 DANE failed for the domain example.net:
DANE Certificate verification failed
Wed Nov 14 06:36:36 2018 Info: Failed for all MX hosts in example.net
Message Delivery Failed due to Invalid TLSA Record
A message reaches the email gateway for a single recipient. The email gateway requests for a secure DNS
MX record, DNS A record, and a TLSA record from the DNS server. If you select DANE as "Mandatory",
the TLSA record is validated against the X.509 certificate value of the recipient's domain. If an invalid TLSA
record is found, the message delivery is attempted at a later time or the message is bounced.
Tue Aug 7 05:15:18 2018 Debug: Trying DANE MANDATORY for example-dane.net
Tue Aug 7 05:15:18 2018 Debug: SECURE MX record (someone.example-dane.net) found for
test-tlsabogus.net
Tue Aug 7 05:15:18 2018 Debug: DNS query: Q ('someone.example-dane.net', 'CNAME')
Tue Aug 7 05:15:18 2018 Debug: DNS query: QN ('someone.example-dane.net', 'CNAME',
'recursive_nameserver0.parent')
Tue Aug 7 05:15:18 2018 Debug: DNS query: QIP
('someone.example-dane.net','CNAME','10.10.2.183', 60)
Tue Aug 7 05:15:18 2018 Debug: DNS query: Q ('someone.example-dane.net', 'CNAME',
'10.10.2.183')
Tue Aug 7 05:15:18 2018 Debug: DNSSEC Response data ([], , 0, 300)
Tue Aug 7 05:15:18 2018 Debug: SECURE A record (10.10.1.198) found for MX
(someone.example-dane.net)
in example-dane.net
Tue Aug 7 05:15:18 2018 Info: ICID 32 close
Tue Aug 7 05:15:18 2018 Info: New SMTP DCID 61 interface 10.10.1.194 address 10.10.1.198
port 25
Tue Aug 7 05:15:18 2018 Debug: DNS query: Q ('_25._tcp.someone.example-dane.net', 'TLSA')
Tue Aug 7 05:15:18 2018 Debug: DNS query: QN ('_25._tcp.someone.example-dane.net', 'TLSA',
'recursive_nameserver0.parent')
Tue Aug 7 05:15:18 2018 Debug: DNS query: QIP
('_25._tcp.someone.example-dane.net','TLSA','10.10.2.183', 60)
Tue Aug 7 05:15:18 2018 Debug: DNS query: Q ('_25._tcp.someone.example-dane.net', 'TLSA',
'10.10.2.183')
Tue Aug 7 05:15:18 2018 Debug: DNSSEC Response data
(['03010160b3f16867357cdfef37bb6acd687af54f
225e3bfa945e1d37bfd37bd4eb6020'], bogus, 0, 60)
Tue Aug 7 05:15:18 2018 Debug: DNS encache (_25._tcp.someone.example-dane.net, TLSA,
[(11065394975822091L,
0, 'BOGUS', '03010160b3f16867357cdfef37bb6acd687af54f225e3bfa945e1d37bfd37bd4eb6020')])
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1159
Logging
Rolling Back to Opportunistic TLS as TLSA Record Not Found
Tue Aug 7 05:15:18 2018 Debug: BOGUS TLSA Record is found for MX (someone.example-dane.net)
in example-dane.net
Tue Aug 7 05:15:18 2018 Debug: Trying next MX record in example-dane.net
Tue Aug 7 05:15:18 2018 Info: MID 44 DCID 61 DANE failed: TLSA record BOGUS
Tue Aug 7 05:15:18 2018 Debug: Failed for all MX hosts in example-dane.net
Rolling Back to Opportunistic TLS as TLSA Record Not Found
A message reaches the email gateway for a single recipient. The email gateway requests for a secure DNS
MX record, DNS A record, and a TLSA record from the DNS server. If you select DANE as "Opportunistic",
the TLSA record is validated against the X.509 certificate value of the recipient's domain. If TLSA record is
not found for the recipient's domain, opportunistic TLS is used for encrypting SMTP conversations.
Wed Sep 12 06:51:32 2018 Debug: Trying DANE OPPORTUNISTIC for example-dane.com
Wed Sep 12 06:51:32 2018 Debug: SECURE MX record (mx.example-dane.com) found for
digitalhellion.com
Wed Sep 12 06:51:32 2018 Debug: DNS query: Q ('mx.example-dane.com', 'CNAME')
Wed Sep 12 06:51:32 2018 Debug: DNS query: QN ('mx.example-dane.com', 'CNAME',
'recursive_nameserver0.parent')
Wed Sep 12 06:51:32 2018 Debug: DNS query: QIP ('mx.example-dane.com', 'CNAME','8.8.8.8',60)
Wed Sep 12 06:51:32 2018 Debug: DNS query: Q ('mx.example-dane.com', 'CNAME', '8.8.8.8')
Wed Sep 12 06:51:32 2018 Debug: DNSSEC Response data ([], , 0, 1799)
Wed Sep 12 06:51:32 2018 Debug: Received NODATA for domain mx.example-dane.com type CNAME
Wed Sep 12 06:51:32 2018 Debug: No CNAME record (NoError) found for domain
(mx.example-dane.com)
Wed Sep 12 06:51:32 2018 Debug: SECURE A record (162.213.199.115) found for MX
(mx.example-dane.com)
in example-dane.com
Wed Sep 12 06:51:32 2018 Info: ICID 1 lost
Wed Sep 12 06:51:32 2018 Info: ICID 1 close
Wed Sep 12 06:51:33 2018 Info: New SMTP DCID 2 interface 10.10.1.173 address 162.213.199.115
port 25
Wed Sep 12 06:51:33 2018 Debug: DNS query: Q ('_25._tcp.mx.example-dane.com', 'TLSA')
Wed Sep 12 06:51:33 2018 Debug: DNS query: QN ('_25._tcp.mx.example-dane.com', 'TLSA',
'recursive_nameserver0.parent')
Wed Sep 12 06:51:33 2018 Debug: DNS query: QIP
('_25._tcp.mx.example-dane.com','TLSA','8.8.8.8', 60)
Wed Sep 12 06:51:33 2018 Debug: DNS query: Q ('_25._tcp.mx.example-dane.com', 'TLSA',
'8.8.8.8')
Wed Sep 12 06:51:34 2018 Debug: DNSSEC Response data ([], , 3, 1798)
Wed Sep 12 06:51:34 2018 Debug: Received NXDomain for domain _25._tcp.mx.example-dane.com'
type TLSA
Wed Sep 12 06:51:34 2018 Debug: No TLSA record (NXDomain) found for MX (mx.example-dane.com)
Wed Sep 12 06:51:34 2018 Debug: Falling back to conventional TLS for MX (mx.example-dane.com)
in example-dane.com
Wed Sep 12 06:51:34 2018 Info: MID 1 DCID 2 DANE failed for the domain example-dane.com:
No TLSA Record
Wed Sep 12 06:51:34 2018 Info: DCID 2 TLS success protocol TLSv1.2 cipher
ECDHE-RSA-AES256-GCM-SHA384
Wed Sep 12 06:51:35 2018 Info: Delivery start DCID 2 MID 1 to RID [0]
Message received based on Sender’s Country of Origin
In this example, the log shows a message received based on the country of origin of a particular sender group.
Thu Apr 6 06:50:18 2017 Info: ICID 73 ACCEPT SG ALLOWED_LIST match country[us] SBRS -10.0
country United States
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1160
Logging
Maximum URLs in Message Attachments Exceeds URL Scan Limit
Maximum URLs in Message Attachments Exceeds URL Scan Limit
In this example, the log shows the number of URLs in the message attachments that exceeded the URL scan
limit
Wed Nov 8 13:35:48 2017 Info: MID $mid not completely scanned for URL Filtering. Error:
$error
Maximum URLs in Message Body Exceeds URL Scan Limit
In this example, the log shows the number of URLs in the message body that exceeded the URL scan limit.
Wed Nov 8 13:37:42 2017 Info: MID 976 not completely scanned for URL Filtering.
Error: The number of URLs in the message body exceeded the URL scan limit.
Malicious Shortened URL redirected to Cisco Proxy Server
In this example, the log shows a shortened URl that is marked as malicious due to a URL reputation score of
-3, and redirected to the Cisco Security Proxy server.
Tue Nov 7 10:42:41 2017 Info: MID 9 having URL: http://ow.ly/Sb6O30fJvVn has been expanded
to http://bit.ly/2frAl1x
Tue Nov 7 10:42:42 2017 Info: MID 9 having URL: http://bit.ly/2frAl1x has been expanded to
http://thebest01.wayisbetter.cn/?cMFN
Tue Nov 7 10:42:42 2017 Info: MID 9 URL http://thebest01.wayisbetter.cn/?cMFN has reputation
-3.854 matched Action: URL redirected to Cisco Security proxy
Tue Nov 7 10:42:42 2017 Info: MID 9 rewritten to MID 10 by
url-reputation-proxy-redirect-action filter 'aa'
Unable to Expand Shortened URL in Message
In this example, the log shows that the shortened URL in the message could not be expanded to the actual
URL.
Mon Oct 30 10:58:59 2017 Info: MID 36 having URL: http://ow.ly/P0Kw30fVst3 has been expanded
to http://bit.ly/2ymYWPR
Mon Oct 30 10:59:00 2017 Info: MID 36 having URL: http://bit.ly/2ymYWPR has been expanded
to http://ow.ly/cTS730fVssH
Mon Oct 30 10:59:01 2017 Info: MID 36 having URL: http://ow.ly/cTS730fVssH has been expanded
to http://bit.ly/2xK8PD9
Mon Oct 30 10:59:01 2017 Info: MID 36 having URL: http://bit.ly/2xK8PD9 has been expanded
to http://ow.ly/lWOi30fVssl
Mon Oct 30 10:59:02 2017 Info: MID 36 having URL: http://ow.ly/lWOi30fVssl has been expanded
to http://bit.ly/2ggHv9e
Mon Oct 30 10:59:03 2017 Info: MID 36 having URL: http://bit.ly/2ggHv9e has been expanded
to http://ow.ly/4fSO30fVsqx
Mon Oct 30 10:59:04 2017 Info: MID 36 having URL: http://ow.ly/4fSO30fVsqx has been expanded
to http://bit.ly/2hKEFcW
Mon Oct 30 10:59:05 2017 Info: MID 36 having URL: http://bit.ly/2hKEFcW has been expanded
to http://ow.ly/NyH830fVsq6
Mon Oct 30 10:59:06 2017 Info: MID 36 having URL: http://ow.ly/NyH830fVsq6 has been expanded
to http://bit.ly/2ysnsNi
Mon Oct 30 10:59:06 2017 Info: MID 36 having URL: http://bit.ly/2ysnsNi has been expanded
to http://ow.ly/JhUN30fVsnL
Mon Oct 30 10:59:07 2017 Info: MID 36 having URL: http://ow.ly/JhUN30fVsnL has been expanded
to http://bit.ly/2hKQmAe
Mon Oct 30 10:59:07 2017 Info: MID 36 URL http://bit.ly/2hKQmAe is marked malicious due to
: URL depth exceeded
Mon Oct 30 11:04:48 2017 Warning: MID 40 Failed to expand URL http://mail1.example.com/abcd
Reason: Error while trying to retrieve expanded URL
Mon Oct 30 11:04:48 2017 Info: MID 40 not completely scanned for URL Filtering. Error:
Message has a shortened URL that could not be expanded
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1161
Logging
Log Entry for Malicious URL in Message Attachment
Log Entry for Malicious URL in Message Attachment
In this example, the log shows a URLin the message attachment that is malicious with a reputation score of
-9.5.
Mon Nov 6 06:50:18 2017 Info: MID 935 Attachment file_1.txt URL http://jrsjvysq.net has
reputation -9.5 matched
Condition: URL Reputation Rule
Message marked as Unscannable due to Extraction Failure
In this example, the log shows a message that is not scanned by the Content Scanner due to an attachment
extraction failure.
Tue Oct 24 08:28:58 2017 Info: Start MID 811 ICID 10
Tue Oct 24 08:28:58 2017 Info: MID 811 ICID 10 From: <[email protected]>
Tue Oct 24 08:28:58 2017 Info: MID 811 ICID 10 RID 0 To: <[email protected]>
Tue Oct 24 08:28:58 2017 Info: MID 811 Message-ID '<[email protected]>'
Tue Oct 24 08:28:58 2017 Info: MID 811 Subject 'Test mail'
Tue Oct 24 08:28:58 2017 Info: MID 811 ready 5242827 bytes from <[email protected]>
Tue Oct 24 08:28:58 2017 Info: MID 811 matched all recipients for per-recipient policy
DEFAULT in the inbound table
Tue Oct 24 08:28:59 2017 Info: MID 811 attachment 'gzip.tar.gz'
Tue Oct 24 08:28:59 2017 Info: MID 811 was marked as unscannable due to extraction failures.
Reason: Error in extraction process - Decoding Errors.
Tue Oct 24 08:28:59 2017 Info: ICID 10 close
Tue Oct 24 08:28:59 2017 Info: MID 811 quarantined to "Policy" (Unscannable: due to Extraction
Failure)
Tue Oct 24 08:28:59 2017 Info: Message finished MID 811 done
Message marked as Unscannable due to RFC Violation
In this example, the log shows a message that is not scanned by the Content Scanner due to an RFC violation.
Tue Oct 24 08:23:26 2017 Info: Start MID 807 ICID 6
Tue Oct 24 08:23:26 2017 Info: MID 807 ICID 6 From: <[email protected]>
Tue Oct 24 08:23:26 2017 Info: MID 807 ICID 6 RID 0 To: <[email protected]>
Tue Oct 24 08:23:26 2017 Info: MID 807 Subject ‘Test Mail'
Tue Oct 24 08:23:26 2017 Info: MID 807 ready 427 bytes from <[email protected]>
Tue Oct 24 08:23:26 2017 Info: MID 807 matched all recipients for per-recipient policy
DEFAULT in the inbound table
Tue Oct 24 08:23:26 2017 Info: MID 807 was marked as unscannable due to an RFC violation.
Reason: A Unix-From header was found in the middle of a header block.
Tue Oct 24 08:23:26 2017 Info: MID 807 queued for delivery
Tue Oct 24 08:23:26 2017 Info: ICID 6 close
Log Entries for Generated or Re-Written Messages
Some functions, such as rewrite/redirect actions ( alt-rcpt-to filters, anti-spam rcpt rewrite, bcc() actions,
anti-virus redirections, etc.), create new messages. When looking through the logs, you might need to check
the results and add in further MIDs and possibly DCIDs. Entries such as these are possible:
Tue Jun 1 20:02:16 2004 Info: MID 14 generated based on MID 13 by bcc filter 'nonetest'
or:
Tue Jan 6 15:03:18 2004 Info: MID 2 rewritten to 3 by antispam
Fri May 14 20:44:43 2004 Info: MID 6 rewritten to 7 by alt-rcpt-to-filter filter
'testfilt'
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1162
Logging
Messages Sent to the Spam Quarantine
An interesting point to note about ‘rewritten’ entries is that they can appear after lines in the log indicating
use of the new MID.
Messages Sent to the Spam Quarantine
When you send a message to the quarantine, the mail logs track the movement to and from the quarantine
using the RCID (RPC connection ID) to identify the RPC connection. In the following mail log, a message
is tagged as spam, and sent to the Spam Quarantine:
Wed Feb 14 12:11:40 2007 Info: Start MID 2317877 ICID 15726925
Wed Feb 14 12:11:40 2007 Info: MID 2317877 ICID 15726925 From: <[email protected]>
Wed Feb 14 12:11:40 2007 Info: MID 2317877 ICID 15726925 RID 0 To:
<[email protected]>
Wed Feb 14 12:11:40 2007 Info: MID 2317877 Message-ID
'<W1TH05606E5811BEA0734309D4BAF0.323.14460.pimailer44.DumpShot.2@email.chase.com>'
Wed Feb 14 12:11:40 2007 Info: MID 2317877 Subject 'Envision your dream home - Now make
it a reality'
Wed Feb 14 12:11:40 2007 Info: MID 2317877 ready 15731 bytes from <[email protected]>
Wed Feb 14 12:11:40 2007 Info: MID 2317877 matched all recipients for per-recipient
policy DEFAULT in the inbound table
Wed Feb 14 12:11:41 2007 Info: MID 2317877 using engine: CASE spam suspect
Wed Feb 14 12:11:41 2007 Info: EUQ: Tagging MID 2317877 for quarantine
Wed Feb 14 12:11:41 2007 Info: MID 2317877 antivirus negative
Wed Feb 14 12:11:41 2007 Info: MID 2317877 queued for delivery
Wed Feb 14 12:11:44 2007 Info: RPC Delivery start RCID 756814 MID 2317877 to local
IronPort Spam Quarantine
Wed Feb 14 12:11:45 2007 Info: EUQ: Quarantined MID 2317877
Wed Feb 14 12:11:45 2007 Info: RPC Message done RCID 756814 MID 2317877
Wed Feb 14 12:11:45 2007 Info: Message finished MID 2317877 done
Example of External Threat Feeds Mail Logs
The Mail Logs contain information about threats detected in incoming messages and actions taken on such
messages. Most information is at the Info or Debug level.
Thu Jun 7 20:48:10 2018 Info: MID 91 Threat feeds source 'S1' detected malicious URL:
'http://digimobil.mobi/' in attachment(s): malurl.txt. Action: Attachment stripped
Examples of SDR Filtering Log Entries
The SDR filtering information is posted to the Mail Logs. Most information is at the Info or Debug level.
• Sender Domain Reputation Authentication Failure, on page 332
• Sender Domain Reputation Request Timeout, on page 333
• Sender Domain Reputation Invalid Host, on page 333
• Sender Domain Reputation General Errors, on page 333
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1163
Logging
Sender Domain Reputation Authentication Failure
Sender Domain Reputation Authentication Failure
In this example, the log shows a message that was not filtered based on SDR because of an authentication
failure when connecting to the SDR service.
Mon Jul 2 08:57:18 2018 Info: New SMTP ICID 3 interface Management (192.0.2.10) address
224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 08:57:18 2018 Info: ICID 3 ACCEPT SG UNKNOWNLIST match ipr[none] ipr not enabled
country not enabled
Mon Jul 2 08:57:18 2018 Info: Start MID 3 ICID 3
Mon Jul 2 08:57:18 2018 Info: MID 3 ICID 3 From: <[email protected]>
Mon Jul 2 08:57:18 2018 Info: MID 3 ICID 3 RID 0 To: <[email protected]>
Mon Jul 2 08:57:18 2018 Info: MID 3 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>' Mon
Jul 2 08:57:18 2018 Info: MID 3 Subject 'Message 001'
Mon Jul 2 08:57:19 2018 Info: MID 3 SDR: Message was not scanned for Sender Domain Reputation.
Reason: Authentication failure.
Solution
Use the sdradvancedconfig command in the CLI to configure the required parameters when connecting your
email gateway to the SDR service.
Sender Domain Reputation Request Timeout
In this example, the log shows a message that was not filtered based on SDR because of a request timeout
error when communicating with the SDR service.
Mon Jul 2 09:00:13 2018 Info: New SMTP ICID 4 interface Management (192.0.2.10) address
224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 09:00:13 2018 Info: ICID 4 ACCEPT SG UNKNOWNLIST match ipr[none] ipr not enabled
country not enabled
Mon Jul 2 09:00:13 2018 Info: Start MID 4 ICID 4
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 From: <[email protected]>
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 RID 0 To: <[email protected] >
Mon Jul 2 09:00:13 2018 Info: MID 4 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>'
Mon Jul 2 09:00:13 2018 Info: MID 4 Subject 'Message 001'
Mon Jul 2 09:00:13 2018 Info: MID 4 SDR: Message was not scanned for Sender Domain Reputation.
Reason: Request timed out.
Solution
When an SDR request times out, the message is marked as unscannable, and the configured actions are applied
to the message.
Sender Domain Reputation Invalid Host
In this example, the log shows a message that was not filtered based on SDR because an invalid SDR service
host was configured on your email gateway.
Mon Jul 2 09:04:08 2018 Info: ICID 7 ACCEPT SG UNKNOWNLIST match ipr[none] ipr not enabled
country not enabled
Mon Jul 2 09:04:08 2018 Info: Start MID 7 ICID 7
Mon Jul 2 09:04:08 2018 Info: MID 7 ICID 7 From: <[email protected] >
Mon Jul 2 09:04:08 2018 Info: MID 7 ICID 7 RID 0 To: <[email protected] >
Mon Jul 2 09:04:08 2018 Info: MID 7 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>' Mon
Jul 2 09:04:08 2018 Info: MID 7 Subject 'Message 001'
Mon Jul 2 09:04:08 2018 Info: MID 7 SDR: Message was not scanned for Sender Domain Reputation.
Reason: Invalid host configured.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1164
Logging
Sender Domain Reputation General Errors
Solution
Use the sdradvancedconfig command in the CLI to configure the required parameters when connecting your
email gateway to the SDR service.
Sender Domain Reputation General Errors
In this example, the log shows a message that was not filtered based on SDR because of an unknown error.
Mon Jul 2 09:00:13 2018 Info: New SMTP ICID 4 interface Management (192.0.2.10) address
224.0.0.10 reverse dns host unknown verified no
Mon Jul 2 09:00:13 2018 Info: ICID 4 ACCEPT SG UNKNOWNLIST match ipr[none] ipr not enabled
country not enabled
Mon Jul 2 09:00:13 2018 Info: Start MID 4 ICID 4
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 From: <[email protected] >
Mon Jul 2 09:00:13 2018 Info: MID 4 ICID 4 RID 0 To: <[email protected] >
Mon Jul 2 09:00:13 2018 Info: MID 4 Message-ID '<000001cba32e$f24ff2e0$d6efd8a0$@com>'
Mon Jul 2 09:00:13 2018 Info: MID 4 Subject 'Test mail'
Mon Jul 2 09:00:13 2018 Info: MID 4 SDR: Message was not scanned for Sender Domain Reputation.
Reason: Unknown error.
Solution
When an unknown error occurs, the message is marked as unscannable, and the configured actions are applied
to the message.
Cisco Advanced Phishing Protection Cloud Service Expired
In this example, the log shows that the Cisco Advanced Phishing Protection Cloud Service expired.
Wed May 6 11:47:45 2020 Critical: The Cisco Advanced
Phishing Protection Cloud Service has expired and is disabled. Contact
your Cisco Account Manager to renew the service and enable it.
Solution: You need to contact your Cisco Account Manager to renew the service and enable it.
Reminder about Cisco Advanced Phishing Protection Cloud Service Expiry Date
In this example, the log shows that the Cisco Advanced Phishing Protection Cloud Service will expire on a
particular date.
Fri May 8 04:50:26 2020 Info: Cisco Advanced
Phishing Protection Cloud Service expires on
2020-05-10 07:00:00. You need to contact your Cisco Account
Manager to renew the service
Solution: You need to contact your Cisco Account Manager to renew the service.
No API Access UID and API Access Secret Key
In this example, the log shows that the email gateway was unable to poll for the Cisco Advanced Phishing
Protection Cloud Service expiry date because of no API Access UID and API Access Secret key.
Wed May 6 17:52:52 2020 Critical: Failed to poll
for the Cisco Advanced Phishing Protection Cloud Service
expiry date. You need to add the API Access UID and API Access
secret key.
Solution: You need to add the API Access UID and API Access secret key.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1165
Logging
Invalid API Access UID or API Access Secret Key
Invalid API Access UID or API Access Secret Key
In this example, the log shows that the email gateway was unable to poll for the Cisco Advanced Phishing
Protection Cloud Service expiry date because of an nvalid API Access UID and API Access Secret key.
Wed May 6 17:52:52 2020 Critical: Failed to poll
for the Cisco Advanced Phishing Protection Cloud Service
expiry date because the API Access Key is invalid. You need
to re-configure the API Access UID and secret key
Solution: You need to re-configure the API Access UID and secret key.
Using Delivery Logs
Delivery logs record critical information about the email delivery operations of AsyncOS. The log messages
are “stateless,” meaning that all associated information is recorded in each log message and users need not
reference previous log messages for information about the current delivery attempt.
The delivery log records all information pertaining to email delivery operations for each recipient. All
information is laid out in a logical manner and is human-readable after conversion using a utility provided by
Cisco. The conversion tools are located at: https://supportforums.cisco.com/document/33721/
cisco-ironport-systems-contributed-tools
Delivery logs are recorded and transferred in a binary format for resource efficiency. Information recorded
in delivery logs is shown in the following table:
Table 125: Delivery Log Statistics
Statistic Description
Delivery status Success (message was successfully delivered) or bounce (message was hard bounced)
Del_time Delivery time
Inj_time Injection time. del_time - inj_time = time the recipient message stayed in the queue
Bytes Message size
Mid Message ID
Ip Recipient host IP. The IP address of the host that received or bounced the recipient
message
From Envelope From, also known as Envelope Sender or MAIL FROM
Source_ip Source host IP. The IP address of the host of the incoming message
Code SMTP response code from recipient host
Reply SMTP response message from recipient host
Rcpt Rid Recipient ID. Recipient ID starts with <0>, messages with multiple recipients will
have multiple recipient IDs
To Envelope To
Attempts Number of delivery attempts
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1166
Logging
Examples of Delivery Log Entries
If the delivery status was bounce, this additional information appears in the delivery log:
Table 126: Delivery Log Bounce Information
Statistic Description
Reason RFC 1893 Enhanced Mail Status Code interpretation of the SMTP response during
the delivery
Code SMTP response code from recipient host
Error SMTP response message from recipient host
If you have set up logheaders (see Logging Message Headers, on page 1210), the header information appears
after the delivery information:
Table 127: Delivery Log Header Information
Statistic Description
Customer_data XML tag marking the beginning of logged headers
Header Name Name of the header
Value Contents of the logged header
Examples of Delivery Log Entries
The examples in this section show a variety of Delivery Log entries.
Successful Message Delivery
Mon Mar 31 20:10:58 2003 Info: New SMTP DCID 5 interface 172.19.0.11 address
63.251.108.110
Mon Mar 31 20:10:58 2003 Info: Delivery start DCID 5 MID 4 to RID [0]
Mon Mar 31 20:10:58 2003 Info: Message done DCID 5 MID 4 to RID [0]
Mon Mar 31 20:11:03 2003 Info: DCID 5 close
Delivery Status Bounce
<bounce del_time="Sun Jan 05 08:28:33.073 2003" inj_time="Mon Jan 05 08:28:32.929 2003"
bytes="4074" mid="94157762" ip="0.0.0.0" from="[email protected]"
source_ip="192.168.102.1 "reason="5.1.0 - Unknown address error" code="550"
error="["Requested action not taken: mailbox unavailable"]">
<rcpt rid="0" to="[email protected]" attempts="1" />
</bounce>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1167
Logging
Delivery Log Entry with Logheaders
Delivery Log Entry with Logheaders
<success del_time="Tue Jan 28 15:56:13.123 2003" inj_time="Tue Jan 28 15:55:17.696 2003"
bytes="139" mid="202" ip="10.1.1.13" from="[email protected]"
source_ip="192.168.102.1" code="250" reply="sent">
<rcpt rid="0" to="[email protected]" attempts="1" />
<customer_data>
<header name="xname" value="sh"/>
</customer_data>
</success>
Using Bounce Logs
The bounce log records all information pertaining to each bounced recipient. Information recorded in bounce
logs is shown in the following table:.
Table 128: Bounce Log Statistics
Statistic Description
Timestamp The time of the bounce event
Log level The level of detail in this bounce log
Bounce type Bounced or delayed (for example, hard or soft-bounce)
MID/RID Message ID and recipient ID
From Envelope From
To Envelope To
Reason RFC 1893 Enhanced Mail Status Code interpretation of the SMTP response during
the delivery
Response SMTP response code and message from recipient host
In addition, if you have specified message size to log or setup logheaders (see Logging Message Headers,
on page 1210), the message and header information will appear after the bounce information:
Table 129: Bounce Log Header Information
Header The header name and content in the header
Message Content of the message logged
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1168
Logging
Examples of Bounce Log Entries
Examples of Bounce Log Entries
Soft-Bounced Recipient (Bounce Type = Delayed)
Thu Dec 26 18:37:00 2003 Info: Delayed: 44451135:0
From:<[email protected]> To:<[email protected]>
Reason: "4.1.0 - Unknown address error" Response: "('451',
['<[email protected]> Automated block triggered by suspicious
activity from your IP address (10.1.1.1). Have your system administrator
send e-mail to [email protected] if you believe this block is
in error'])"
Hard-Bounced Recipient (Bounce Type = Bounced)
Thu Dec 26 18:36:59 2003 Info: Bounced: 45346670:0 From:<[email protected]>
To:<[email protected]>
Reason: "5.1.0 - Unknown address error" Response: "('550', ['There is no such active
account.'])"
Bounce Log with Message Body and Logheaders
Wed Jan 29 00:06:30 2003 Info: Bounced: 203:0 From:<[email protected]>
To:<[email protected]>
Reason:"5.1.2 - Bad destination host" Response: "('000', [])" Headers: ['xname:
userID2333']' Message: Message-Id:
<[email protected]>\015\012xname: userID2333\015\012subject:
Greetings.\015\012\015\012Hi Tom:'
Note The text string \015\012 represents a line break (for example, CRLF).
Using Status Logs
Status logs record system statistics found in the CLI status commands, including status , status detail , and
dnsstatus . The period of recording is set using the setup subcommand in logconfig . Each counter or rate
reported in status logs is the value since the last time the counter was reset.
Reading Status Logs
The following table shows the status log labels and the matching system statistics.
Table 130: Status Log Statistics
Statistic Description
CPULd CPU Utilization
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1169
Logging
Reading Status Logs
Statistic Description
DskIO Disk I/O Utilization
RAMUtil RAM Utilization
QKUsd Queue Kilobytes Used
QKFre Queue Kilobytes Free
CrtMID Message ID (MID)
CrtICID Injection Connection ID (ICID)
CRTDCID Delivery Connection ID (DCID)
InjBytes Total Injected Message Size in Bytes
InjMsg Injected Messages
InjRcp Injected Recipients
GenBncRcp Generated Bounce Recipients
RejRcp Rejected Recipients
DrpMsg Dropped Messages
SftBncEvnt Soft Bounced Events
CmpRcp Completed Recipients
HrdBncRcp Hard Bounced Recipients
DnsHrdBnc DNS Hard Bounces
5XXHrdBnc 5XX Hard Bounces
FltrHrdBnc Filter Hard Bounces
ExpHrdBnc Expired Hard Bounces
OtrHrdBnc Other Hard Bounces
DlvRcp Delivered Recipients
DelRcp Deleted Recipients
GlbUnsbHt Global Unsubscribe Hits
ActvRcp Active Recipients
UnatmptRcp Unattempted Recipients
AtmptRcp Attempted Recipients
CrtCncIn Current Inbound Connections
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1170
Logging
Reading Status Logs
Statistic Description
CrtCncOut Current Outbound Connections
DnsReq DNS Requests
NetReq Network Requests
CchHit Cache Hits
CchMis Cache Misses
CchEct Cache Exceptions
CchExp Cache Expired
CPUTTm Total CPU time used by the application
CPUETm Elapsed time since the application started
MaxIO Maximum disk I/O operations per second for the mail process
RamUsd Allocated memory in bytes
SwIn Memory swapped in.
SwOut Memory swapped out.
SwPgIn Memory paged in.
SwPgOut Memory paged out.
MMLen Total number of messages in the system
DstInMem Number of destination objects in memory
ResCon Resource conservation tarpit value. Acceptance of incoming mail is delayed by this
number of seconds due to heavy system load
WorkQ This is the number of messages currently in the work queue
QuarMsgs Number of individual messages in policy, virus, or outbreak quarantine (messages
present in multiple quarantines are counted only once)
QuarQKUsd KBytes used by policy, virus, and outbreak quarantine messages
LogUsd Percent of log partition used
SophLd Percent CPU used by Sophos anti-virus scanning
McafLd Percent CPU used by McAfee anti-virus scanning
CASELd Percent CPU used by CASE scanning
TotalLd Total CPU consumption
LogAvail Amount of disk space available for log files
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1171
Logging
Status Log Example
Statistic Description
EuQ Estimated number of messages in the Spam quarantine
EuqRls Estimated number of messages in the Spam quarantine release queue
RptLD CPU load during the Reporting process
QtnLd CPU load during the Quarantine process
EncrQ Messages in the Encryption Queue
Status Log Example
Fri Feb 28 12:11:48 2020 Info: Status: CPULd 45 DskIO 22 RAMUtil 22 QKUsd 6676975
QKFre 1711633 CrtMID 6130195 CrtICID 722770 CrtDCID 54 InjMsg 4572789 InjRcp
4575323 GenBncRcp 255536 RejRcp 20388 DrpMsg 469642 SftBncEvnt 0 CmpRcp 3650806 HrdBncRcp
255536
DnsHrdBnc 23 5XXHrdBnc 28 FltrHrdBnc 255485 ExpHrdBnc 0
OtrHrdBnc 0 DlvRcp 3394965 DelRcp 305 GlbUnsbHt 0 ActvRcp 65 UnatmptRcp 65 AtmptRcp 0
CrtCncIn 9
CrtCncOut 0 DnsReq 7756744 NetReq 7769130 CchHit 8373490 CchMis
1989637 CchEct 1625236 CchExp 1569329 CPUTTm 37 CPUETm 62 MaxIO 465600 RAMUsd 1473355956
MMLen 54782
DstInMem 11 ResCon 0 WorkQ 54710 QuarMsgs 375
QuarQKUsd 145096 LogUsd 26 SophLd 15 BMLd 0 CASELd 0 TotalLd 100 LogAvail 116G EuQ 64 EuqRls
0 CmrkLd 0
McafLd 9 SwIn 122 SwOut 5295 SwPgIn 368 SwPg Out 63639
SwapUsage 4% RptLd 0 QtnLd 19 EncrQ 0 InjBytes 516664777890
Using Domain Debug Logs
Domain debug logs record the client and server communication during an SMTP conversation between the
email gatewayand a specified recipient host. This log type is primarily used to debug issues with specific
recipient hosts.
Table 131: Domain Debug Log Statistics
Statistic Description
Timestamp The time of the bounce event
Log level The level of detail in this bounce log
From Envelope From
To Envelope To
Reason RFC 1893 Enhanced Mail Status Code interpretation of the SMTP response during
the delivery
Response SMTP response code and message from recipient host
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1172
Logging
Domain Debug Log Example
Domain Debug Log Example
Sat Dec 21 02:37:22 2003 Info: 102503993 Sent: 'MAIL FROM:<[email protected]>'
Sat Dec 21 02:37:23 2003 Info: 102503993 Rcvd: '250 OK'
Sat Dec 21 02:37:23 2003 Info: 102503993 Sent: 'RCPT TO:<[email protected]>'
Sat Dec 21 02:37:23 2003 Info: 102503993 Rcvd: '250 OK'
Sat Dec 21 02:37:23 2003 Info: 102503993 Sent: 'DATA'
Sat Dec 21 02:37:24 2003 Info: 102503993 Rcvd: '354 START MAIL INPUT, END WITH "." ON A
LINE BY ITSELF'
Sat Dec 21 02:37:24 2003 Info: 102503993 Rcvd: '250 OK'
Using Injection Debug Logs
Injection debug logs record the SMTP conversation between the email gateway and a specified host connecting
to the system. Injection debug logs are useful for troubleshooting communication problems between the email
gateway and a client initiating a connection from the Internet. The log records all bytes transmitted between
the two systems and classifies them as “Sent to” the connecting host or “Received from” the connecting host.
You must designate the host conversations to record by specifying an IP address, an IP range, hostname, or
partial hostname. Any connecting IP address within an IP range will be recorded. Any host within a partial
domain will be recorded. The system performs reverse DNS lookups on connecting IP addresses to convert
to hostnames. IP addresses without a corresponding PTR record in DNS will not match hostnames.
You must also specify the number of sessions to record.
Each line within an Injection Debug log contains the following information in the following table.
Table 132: Injection Debug Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
ICID The Injection Connection ID is a unique identifier that can be tied to the same
connection in other log subscriptions
Sent/Received Lines marked with “Sent to” are the actual bytes sent to the connecting host. Lines
marked with “Received from” are the actual bytes received from the connecting
host
IP Address IP address of the connecting host
Injection Debug Log Example
Wed Apr 2 14:30:04 2003 Info: 6216 Sent to '172.16.0.22': '220 postman.example.com
ESMTP\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Rcvd from '172.16.0.22': 'HELO
mail.remotehost.com\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Sent to '172.16.0.22': '250
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1173
Logging
Using System Logs
postman.example.com\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Rcvd from '172.16.0.22': 'MAIL
FROM:<[email protected]>\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Sent to '172.16.0.22': '250 sender
<[email protected]> ok\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Rcvd from '172.16.0.22': 'RCPT
TO:<[email protected]>\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Sent to '172.16.0.22': '250 recipient
<[email protected]> ok\015\012'
Wed Apr 2 14:30:04 Info: 6216 Rcvd from '172.16.0.22': 'DATA\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Sent to '172.16.0.22': '354 go ahead\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Rcvd from '172.16.0.22': 'To:
[email protected]\015\012Date: Apr 02 2003 10:09:44\015\012Subject: Test
Subject\015\012From: Sender <[email protected]>\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Rcvd from '172.16.0.22': 'This is the content of the
message'
Wed Apr 2 14:30:04 Info: 6216 Sent to '172.16.0.22': '250 ok\015\012'
Wed Apr 2 14:30:04 Info: 6216 Rcvd from '172.16.0.22': 'QUIT\015\012'
Wed Apr 2 14:30:04 2003 Info: 6216 Sent to '172.16.0.22': '221
postman.example.com\015\012'
Using System Logs
Table 133: System Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
Message The logged event
System Log Example
In this example, the System log shows some commit entries, including the name of the user issuing the commit
and the comment entered.
Wed Sep 8 18:02:45 2004 Info: Version: 4.0.0-206 SN: XXXXXXXXXXXX-XXX
Wed Sep 8 18:02:45 2004 Info: Time offset from UTC: 0 seconds
Wed Sep 8 18:02:45 2004 Info: System is coming up
Wed Sep 8 18:02:49 2004 Info: bootstrapping DNS cache
Wed Sep 8 18:02:49 2004 Info: DNS cache bootstrapped
Wed Sep 8 18:13:30 2004 Info: PID 608: User admin commit changes: SSW:Password
Wed Sep 8 18:17:23 2004 Info: PID 608: User admin commit changes: Completed Web::SSW
Thu Sep 9 08:49:27 2004 Info: Time offset from UTC: -25200 seconds
Thu Sep 9 08:49:27 2004 Info: PID 1237: User admin commit changes: Added a second CLI
log for examples
Thu Sep 9 08:51:53 2004 Info: PID 1237: User admin commit changes: Removed example CLI
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1174
Logging
Using CLI Audit Logs
log.
Using CLI Audit Logs
Table 134: CLI Audit Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
PID Process ID for the particular CLI session in which the command was entered
Message The message consists of the CLI command entered, the CLI output (including menus,
lists, etc.), and the prompt that is displayed
CLI Audit Log Example
In this example, the CLI Audit log shows that, for PID 16434, the following CLI commands were entered:
who , textconfig .
Thu Sep 9 14:35:55 2004 Info: PID 16434: User admin entered 'who'; prompt was
'\nmail3.example.com> '
Thu Sep 9 14:37:12 2004 Info: PID 16434: User admin entered 'textconfig'; prompt was
'\nUsername Login Time Idle Time Remote Host What\n======== ========== =========
=========== ====\nadmin Wed 11AM 3m 45s 10.1.3.14 tail\nadmin 02:32PM
0s 10.1.3.14 cli\nmail3.example.com> '
Thu Sep 9 14:37:18 2004 Info: PID 16434: User admin entered ''; prompt was '\nThere are
no text resources currently defined.\n\n\nChoose the operation you want to perform:\n-
NEW - Create a new text resource.\n- IMPORT - Import a text resource from a file.\n[]> '
Using FTP Server Logs
Table 135: FTP Server Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
ID Connection ID. A separate ID for each FTP connection
Message The message section of the log entry can be logfile status information, or FTP
connection information (login, upload, download, logout, etc.)
FTP Server Log Example
In this example, the FTP Server log records a connection (ID:1). The IP address of the incoming connection
is shown, as well as the activity (uploading and downloading files) and the logout.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1175
Logging
Using HTTP Logs
Wed Sep 8 18:03:06 2004 Info: Begin Logfile
Wed Sep 8 18:03:06 2004 Info: Version: 4.0.0-206 SN: 00065BF3BA6D-9WFWC21
Wed Sep 8 18:03:06 2004 Info: Time offset from UTC: 0 seconds
Wed Sep 8 18:03:06 2004 Info: System is coming up
Fri Sep 10 08:07:32 2004 Info: Time offset from UTC: -25200 seconds
Fri Sep 10 08:07:32 2004 Info: ID:1 Connection from 10.1.3.14 on 172.19.0.86
Fri Sep 10 08:07:38 2004 Info: ID:1 User admin login SUCCESS
Fri Sep 10 08:08:46 2004 Info: ID:1 Upload wording.txt 20 bytes
Fri Sep 10 08:08:57 2004 Info: ID:1 Download words.txt 1191 bytes
Fri Sep 10 08:09:06 2004 Info: ID:1 User admin logout
Using HTTP Logs
Table 136: HTTP Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
ID Session ID
req IP address of machine connecting
user Username of user connecting
Message Information regarding the actions performed. May include GET or POST
commands or system status, etc.
HTTP Log Example
In this example, the HTTP log shows the admin user’s interaction with the GUI (running the System Setup
Wizard, etc.).
Wed Sep 8 18:17:23 2004 Info: http service on 192.168.0.1:80 redirecting to https port 443
Wed Sep 8 18:17:23 2004 Info: http service listening on 192.168.0.1:80
Wed Sep 8 18:17:23 2004 Info: https service listening on 192.168.0.1:443
Wed Sep 8 11:17:24 2004 Info: Time offset from UTC: -25200 seconds
Wed Sep 8 11:17:24 2004 Info: req:10.10.10.14 user:admin id:iaCkEh2h5rZknQarAecg POST
/system_administration/system_setup_wizard HTTP/1.1 303
Wed Sep 8 11:17:25 2004 Info: req:10.10.10.14 user:admin id:iaCkEh2h5rZknQarAecg GET
/system_administration/ssw_done HTTP/1.1 200
Wed Sep 8 11:18:45 2004 Info: req:10.10.10.14 user:admin id:iaCkEh2h5rZknQarAecg GET
/monitor/incoming_mail_overview HTTP/1.1 200
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1176
Logging
Using NTP Logs
Wed Sep 8 11:18:45 2004 Info: req:10.10.10.14 user:admin id:iaCkEh2h5rZknQarAecg GET
/monitor/mail_flow_graph?injector=&width=365&interval=0&type=recipientsin&height=190
HTTP/1.1 200
Wed Sep 8 11:18:46 2004 Info: req:10.10.10.14 user:admin id:iaCkEh2h5rZknQarAecg GET
/monitor/classification_graph?injector=&width=325&interval=0&type=recipientsin&height=19
0 HTTP/1.1 200
Wed Sep 8 11:18:49 2004 Info: req:10.10.10.14 user:admin id:iaCkEh2h5rZknQarAecg GET
/monitor/quarantines HTTP/1.1 200
Using NTP Logs
Table 137: NTP Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
Message The message consists of either a Simple Network Time Protocol (SNTP) query to
the server, or an adjust: message
NTP Log Example
In this example, the NTP log shows the email gateway polling the NTP host twice.
Thu Sep 9 07:36:39 2004 Info: sntp query host 10.1.1.23 delay 653 offset -652
Thu Sep 9 07:36:39 2004 Info: adjust: time_const: 8 offset: -652us next_poll: 4096
Thu Sep 9 08:44:59 2004 Info: sntp query host 10.1.1.23 delay 642 offset -1152
Thu Sep 9 08:44:59 2004 Info: adjust: time_const: 8 offset: -1152us next_poll: 4096
Using Scanning Logs
The scanning log contains all LOG and COMMON messages for the email gateway's scanning engines. See
the Alerts section of the “System Administration” chapter for a list of available the COMMON and LOG alert
messages.
Table 138: Scanning Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
Message The message consists of an application fault, sent alert, failed alert, or log error
message for one of the scanning engines.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1177
Logging
Scanning Log Example
Scanning Log Example
In this example, the log shows the history of an email gateway sending a warning alert concerning Sophos
anti-virus.
Wed Feb 23 22:05:48 2011 Info: Internal SMTP system attempting to send a message to
[email protected] with subject 'Warning <Anti-Virus> mail3.example.com: sophos
antivirus - The Anti-Virus database on this system is...' (attempt #0).
Wed Feb 23 22:05:48 2011 Info: Internal SMTP system successfully sent a message to
[email protected] with subject 'Warning <Anti-Virus> mail3.example.com: sophos
antivirus - The Anti-Virus database on this system is...'.
Wed Feb 23 22:05:48 2011 Info: A Anti-Virus/Warning alert was sent to [email protected]
with subject "Warning <Anti-Virus> mail3.example.com: sophos antivirus - The Anti-Virus
database on this system is...".
Using Anti-Spam Logs
Table 139: Anti-Spam Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
Message The message consists of the check for the anti-spam updates, as well as the results
(whether an update of the engine or the anti-spam rules was needed, etc.)
Anti-Spam Log Example
In this example, the anti-spam log shows the anti-spam engine checking for updates to spam definitions and
CASE updates:
Fri Apr 13 18:59:47 2007 Info: case antispam - engine (19103) : case-daemon: server
successfully spawned child process, pid 19111
Fri Apr 13 18:59:47 2007 Info: case antispam - engine (19111) : startup: Region profile:
Using profile global
Fri Apr 13 18:59:59 2007 Info: case antispam - engine (19111) : fuzzy: Fuzzy plugin v7
successfully loaded, ready to roll
Fri Apr 13 19:00:01 2007 Info: case antispam - engine (19110) : uribllocal: running URI
blocklist local
Fri Apr 13 19:00:04 2007 Info: case antispam - engine (19111) : config: Finished loading
configuration
Using Graymail Logs
Statistic Description
Timestamp Time that the bytes were transmitted
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1178
Logging
Graymail Log Example
Statistic Description
Message The message contains information about the graymail engine, status, configuration,
and so on.
Graymail Log Example
Tue Mar 24 08:56:45 2015 Info: graymail [BASE] Logging at DEBUG level
Tue Mar 24 08:56:45 2015 Info: graymail [HANDLER] Initializing request handler
Tue Mar 24 08:56:50 2015 Info: graymail [ENGINE] Loaded graymail scanner library
Tue Mar 24 08:56:50 2015 Info: graymail [ENGINE] Created graymail scanner instance
Tue Mar 24 08:56:50 2015 Info: graymail [HANDLER] Debug mode disabled on graymail process
Tue Mar 24 08:56:50 2015 Info: graymail [HANDLER] Starting thread WorkerThread_0
Using Anti-Virus Logs
Table 140: AntiVirus Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
Message The message consists of the check for the anti-virus update, as well as the results
(whether an update of the engine or the virus definitions was needed, etc.)
Anti-Virus Log Example
In this example, the Anti-Virus log shows the Sophos anti-virus engine checking for updates to virus definitions
(IDE) and the engine itself.
Thu Sep 9 14:18:04 2004 Info: Checking for Sophos Update
Thu Sep 9 14:18:04 2004 Info: Current SAV engine ver=3.84. No engine update needed
Thu Sep 9 14:18:04 2004 Info: Current IDE serial=2004090902. No update needed.
You can temporarily set this to DEBUG level to help diagnose why the anti-virus engine returns a particular
verdict for a given message. The DEBUG logging information is verbose; use with caution.
Using AMP Engine Logs
The AMP Engine logs contain details of:
• File reputation query sent to the file reputation server and response received from the file reputation
server.
• File analysis, if the file is uploaded to file analysis server. The status of the file analysis is recorded
periodically until a response is received from the file analysis server.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1179
Logging
Examples of AMP Engine Log Entries
Examples of AMP Engine Log Entries
Following are sample AMP Engine log entries based on certain scenarios:
• Initialization of File Reputation and File Analysis Servers, on page 1180
• File Reputation Server Not Configured, on page 1180
• Initialization of File Reputation Query, on page 1180
• Response Received for File Reputation Query from File Reputation Server, on page 1181
• File Uploaded for Analysis and File Analysis Process, on page 1182
• File Not Uploaded for Analysis, on page 1183
• File Upload Skipped for File Analysis due to File Upload Limit , on page 1183
• File Upload Skipped for File Analysis due to File Analysis Server Error, on page 1184
• File Retrospective Verdict Received, on page 1184
Initialization of File Reputation and File Analysis Servers
Wed Oct 5 15:17:31 2016 Info: File reputation service initialized successfully
Wed Oct 5 15:17:31 2016 Info: The following file type(s) can be sent for File Analysis:
Microsoft Windows / DOS Executable, Microsoft Office 97-2004 (OLE), Microsoft Office 2007+
(Open XML), Other potentially malicious file types, Adobe Portable Document Format (PDF).
To allow analysis of new file type(s), go to Security Services > File Reputation and
Analysis.
Wed Oct 5 15:17:31 2016 Info: File Analysis service initialized successfully
File Reputation Server Not Configured
Tue Oct 4 23:15:24 2016 Warning: MID 12 reputation query failed for attachment 'Zombies.pdf'
with error "Cloud query failed"
Initialization of File Reputation Query
Fri Oct 7 09:44:04 2016 Info: File reputation query initiating. File Name = 'mod-6.exe',
MID = 5, File Size = 1673216 bytes,
File Type = application/x-dosexec
Statistic Description
File Name The name of the file whose SHA-256 hash identifier is sent to the file reputation
server.
If the file name is not available, it is termed as unknown .
MID The Message ID used to track messages that flow through the email pipeline.
File Size The size of the file whose SHA-256 hash identifier is sent to the file reputation
server.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1180
Logging
Response Received for File Reputation Query from File Reputation Server
Statistic Description
File Type The type of the file whose SHA-256 hash identifier is sent to the file reputation
server.
Following are the supported file types:
• Microsoft Windows / DOS Executable
• Microsoft Office 97-2004 (OLE)
• Microsoft Office 2007+ (Open XML)
• Other potentially malicious file types
• Adobe Portable Document Format (PDF)
Response Received for File Reputation Query from File Reputation Server
Fri Oct 7 09:44:06 2016 Info: Response received for file reputation query from Cloud. File
Name = 'mod-6.exe', MID = 5, Disposition = MALICIOUS, Malware = W32.061DEF69B5-100.SBX.TG,
Reputation Score = 73, sha256 =
061def69b5c100e9979610fa5675bd19258b19a7ff538b5c2d230b467c312f19, upload_action = 2
Statistic Description
File Name The name of the file whose SHA-256 hash identifier is sent to the file reputation
server.
If the file name is not available, it is termed as unknown .
MID The message ID used to track messages that flow through the email pipeline.
Disposition The file reputation disposition values are:
• MALICIOUS
• CLEAN
• FILE UNKNOWN - When the reputation score is zero.
• VERDICT UNKNOWN - When the disposition is FILE UNKNOWN and score
is non-zero.
• LOW RISK - When no dynamic content is found in a file after file analysis,
the verdict is Low Risk. The file is not sent for file analysis, and the message
continues through the email pipeline.
Malware The name of the malware threat.
Reputation score The reputation score assigned to the file by the file reputation server.
If the file disposition is VERDICT UNKNOWN, the email gateway adjusts the file
reputation verdict based on the reputation score and the threshold value.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1181
Logging
File Uploaded for Analysis and File Analysis Process
Statistic Description
Upload Action The upload action value recommended by the file reputation server to take on the
given file:
• 0 - Need not send for upload
• 1 - Send file for upload.
Note The email gateway uploads the file when the upload action value is
‘1.’
• 2 - Do not send file for upload
• 3 - Send only metadata for upload
File Uploaded for Analysis and File Analysis Process
Wed Sep 28 11:31:58 2016 Info: File uploaded for analysis. SHA256:
e7ae35a8227b380ca761c0317e814e4aaa3d04f362c6b913300117241800f0ea
Wed Sep 28 11:36:58 2016 Info: File Analysis is running for SHA:
e7ae35a8227b380ca761c0317e814e4aaa3d04f362c6b913300117241800f0ea
Fri Oct 7 07:39:13 2016 Info: File Analysis complete. SHA256:
16454aff5082c2e9df43f3e3b9cdba3c6ae1766416e548c30a971786db570bfc, Submit Timestamp:
1475825466, Update Timestamp: 1475825953, Disposition: 3 Score: 100, run_id: 194926004
Details: Analysis is completed for the File
SHA256[16454aff5082c2e9df43f3e3b9cdba3c6ae1766416e548c30a971786db570bfc]
Spyname:[W32.16454AFF50-100.SBX.TG]
Statistic Description
SHA256 The SHA-256 hash identifier for the corresponding file.
Submit Timestamp The date and time at which the file is uploaded to the file analysis server by
the email gateway.
Update Timestamp The date and time at which the file analysis for the file is complete
Disposition The file reputation disposition values are.
• 1 - No malware detected
• 2 - Clean
• 3 - Malware
Score The analysis score assigned to the file by the file analysis server.
Run ID The numeric value (ID) assigned to the file by the file analysis server for a
particular file analysis.
Details Additional information if errors are reported during file analysis, otherwise it
indicates that the final analysis is complete for the file.
Spy Name The name of the threat, if a malware is found in the file during file analysis.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1182
Logging
File Not Uploaded for Analysis
File Not Uploaded for Analysis
Wed Sep 14 12:27:52 2016 Info: File not uploaded for analysis. MID = 0 File
SHA256[a5f28f1fed7c2fe88bcdf403710098977fa12c32d13bfbd78bbe27e95b245f82] file
mime[text/plain] Reason: No active/dynamic contents exists
Statistic Description
MID The message ID used to track messages that flow through the email pipeline.
File MIME The MIME type of the file.
Reason Following are one of the reason values for file not uploaded to the file analysis server
even when the upload_action is set to ‘1’:
• File already uploaded by another node - The file is already uploaded to the file
analysis server via another email gateway.
• File analysis in progress - File is already selected for upload which is in progress.
• File already uploaded to File Analysis server
• Not a supported File type
• File size is out of bounds - The upload file size exceeds the threshold limit set by
the file analysis server.
• Upload queue was full
• File Analysis server error
• No active/dynamic contents exists
• Generic/Unknown Error
File Upload Skipped for File Analysis due to File Upload Limit
Tue Jun 20 13:22:56 2017 Info: File analysis upload skipped. SHA256:
b5c7e26491983baa713c9a2910ee868efd891661c6a0553b28f17b8fdc8cc3ef,Timestamp[1454782976]
details[File SHA256[b5c7e26491983baa713c9a2910ee868efd891661c6a0553b28f17b8fdc8cc3ef] file
mime[application/pdf], upload priority[Low] not uploaded, re-tries[3], backoff[986]
discarding ...]
Tue Jun 20 13:22:56 2017 Critical: The attachment could not be uploaded to the
File Analysis server because the appliance exceeded the upload limit
Statistic Description
SHA256 The SHA-256 hash identifier for the corresponding file.
Timestamp The date and time at which the file failed to upload to the file analysis server.
Details Details of the File Analysis server error.
File MIME The MIME type of the file.
Upload priority Upload priority values are:
• High - For all selected file types, except PDF file type.
• Low - For only PDF file types
Re-tries The number of upload attempts performed on a given file.
Note A maximum of three upload attempts can be performed on a given file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1183
Logging
File Upload Skipped for File Analysis due to File Analysis Server Error
Statistic Description
Backoff (x) The number of (x) seconds before the email gateway needs to wait before it makes
an attempt to upload the file to the file analysis server. This occurs when the email
gateway reaches the daily upload limit.
Critical (Reason) The attachment could not be uploaded to the File Analysis server because the email
gateway exceeded the upload limit.
File Upload Skipped for File Analysis due to File Analysis Server Error
Sat Feb 6 13:22:56 2016 Info:SHA256:
69e17e213732da0d0cbc48ae7030a4a18e0c1289f510e8b139945787f67692a5,Timestamp[1454959409]
details[Server Response HTTP code:[502]]
Statistic Description
SHA256 The SHA-256 hash identifier for the corresponding file.
Timestamp The date and time at which an attempt is made to upload the file to the file analysis
server.
Details Information about the File Analysis server error.
File Retrospective Verdict Received
Fri Oct 7 07:39:13 2016 Info: Retrospective verdict received. SHA256:
16454aff5082c2e9df43f3e3b9cdba3c6ae1766416e548c30a971786db570bfc, Timestamp: 1475832815.7,
Verdict: MALICIOUS, Reputation Score: 0, Spyname: W32.16454AFF50-100.SBX.
Statistic Description
SHA256 The SHA-256 hash identifier for the corresponding file.
Timestamp The date and time at which a file retrospective verdict is received from the file
analysis server.
Verdict The file retrospective verdict value is malicious or clean .
Reputation Score The reputation score assigned to the file by the file reputation server.
Spyname The name of the threat, if a malware is found in the file during file analysis.
Using Spam Quarantine Logs
Table 141: Spam Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1184
Logging
Spam Quarantine Log Example
Statistic Description
Message The message consists of actions taken (messages quarantined, released from
quarantine, etc.).
Spam Quarantine Log Example
In this example, the log shows a message (MID 8298624) being released from the quarantine to
[email protected].
Mon Aug 14 21:41:47 2006 Info: ISQ: Releasing MID [8298624, 8298625] for all
Mon Aug 14 21:41:47 2006 Info: ISQ: Delivering released MID 8298624 (skipping work
queue)
Mon Aug 14 21:41:47 2006 Info: ISQ: Released MID 8298624 to [email protected]
Mon Aug 14 21:41:47 2006 Info: ISQ: Delivering released MID 8298625 (skipping work
queue)
Mon Aug 14 21:41:47 2006 Info: ISQ: Released MID8298625 to [email protected]
Using Spam Quarantine GUI Logs
Table 142: Spam GUI Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
Message The message consists of actions taken, including user authentication, etc.
Spam Quarantine GUI Log Example
In this example, the log shows a successful authentication, login and logout:
Fri Aug 11 22:05:28 2006 Info: ISQ: Serving HTTP on 192.168.0.1, port 82
Fri Aug 11 22:05:29 2006 Info: ISQ: Serving HTTPS on 192.168.0.1, port 83
Fri Aug 11 22:08:35 2006 Info: Authentication OK, user admin
Fri Aug 11 22:08:35 2006 Info: logout:- user:pqufOtL6vyI5StCqhCfO session:10.251.23.228
Fri Aug 11 22:08:35 2006 Info: login:admin user:pqufOtL6vyI5StCqhCfO
session:10.251.23.228
Fri Aug 11 22:08:44 2006 Info: Authentication OK, user admin
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1185
Logging
Using LDAP Debug Logs
Using LDAP Debug Logs
Table 143: LDAP Debug Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted
Message LDAP Debug message
LDAP Debug Log Example
Note Individual lines in log files are NOT numbered. They are numbered here only for sample purposes
1 Thu Sep 9 12:24:56 2004 Begin Logfile
2 Thu Sep 9 12:25:02 2004 LDAP:
Masquerade query sun.masquerade address [email protected] to [email protected]
3 Thu Sep 9 12:25:02 2004 LDAP:
Masquerade query sun.masquerade address [email protected] to [email protected]
4 Thu Sep 9 12:25:02 2004 LDAP:
Masquerade query sun.masquerade address [email protected] to [email protected]
5 Thu Sep 9 12:28:08 2004 LDAP: Clearing LDAP cache
6 Thu Sep 9 13:00:09 2004 LDAP:
Query '(&(ObjectClass={g})(mailLocalAddress={a}))' to server sun (sun.qa:389)
7 Thu Sep 9 13:00:09 2004 LDAP:
After substitute, query is '(&(ObjectClass=inetLocalMailRecipient)
([email protected]))'
8 Thu Sep 9 13:00:09 2004 LDAP: connecting to server
9 Thu Sep 9 13:00:09 2004 LDAP: connected
10 Thu Sep 9 13:00:09 2004 LDAP:
Query (&(ObjectClass=inetLocalMailRecipient)
([email protected])) returned 1
results
11 Thu Sep 9 13:00:09 2004 LDAP: returning: [<LDAP:>]
Use as a guide to reading the preceding log file.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1186
Logging
Using Safelist/Blocklist Logs
Table 144: Detail of LDAP Debug Log Example
Line Number Description
1 The log file is initialized.
2 The listener is configured to use LDAP for masquerading, specifically with the LDAP
query named “sun.masquerade.”
3
The address [email protected] is looked up in the LDAP server, a match is found,
4
and the resulting masquerade address is [email protected], which will be written to the
message headers and/or the envelope from, depending on the masquerade configuration.
5 The user has manually run ldapflush .
6 A query is about to be sent to sun.qa, port 389. The query template is:
(&(ObjectClass={g})(mailLocalAddress={a})).
The {g} will be replaced by the groupname specified in the calling filter, either a
rcpt-to-group or mail-from-group rule.
The {a} will be replaced by the address in question.
7 Now the substitution (described previously) takes place, and this is what the query looks
like before it is sent to the LDAP server.
8 The connection to the server is not yet established, so make a connection.
9 The data that is sent to the server.
10 The result is an empty positive, meaning one record was returned, but since the query
didn't ask for any fields, there is no data to report. These are used for both group and accept
queries when the query checks to see if there is a match in the database.
Using Safelist/Blocklist Logs
The following table shows the statistics recorded in safelist/blocklist logs.
Table 145: Safelist/Blocklist Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted.
Message The message consists of actions taken, including user authentication, and so forth.
Safelist/Blocklist Log Example
In this example, the safelist/blocklist log shows the email gateway creating database snapshots every two
hours. It also shows when senders were added to the database.
Fri Sep 28 14:22:33 2007 Info: Begin Logfile Fri Sep 28 14:22:33 2007 Info: Version:
6.0.0-425 SN: XXXXXXXXXXXX-XXX Fri Sep 28 14:22:33 2007 Info: Time offset from UTC:
10800 seconds Fri Sep 28 14:22:33 2007 Info: System is coming up.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1187
Logging
Using Reporting Logs
Fri Sep 28 14:22:33 2007 Info: SLBL: The database snapshot has been created.
Fri Sep 28 16:22:34 2007 Info: SLBL: The database snapshot has been created.
Fri Sep 28 18:22:34 2007 Info: SLBL: The database snapshot has been created.
Fri Sep 28 20:22:34 2007 Info: SLBL: The database snapshot has been created.
Fri Sep 28 22:22:35 2007 Info: SLBL: The database snapshot has been created.
.........................
Mon Oct 1 14:16:09 2007 Info: SLBL: The database snapshot has been created.
Mon Oct 1 14:37:39 2007 Info: SLBL: The database snapshot has been created.
Mon Oct 1 15:31:37 2007 Warning: SLBL: Adding senders to the database failed.
Mon Oct 1 15:32:31 2007 Warning: SLBL: Adding senders to the database failed.
Mon Oct 1 16:37:40 2007 Info: SLBL: The database snapshot has been created.
Using Reporting Logs
The following table shows the statistics recorded in reporting logs.
Table 146: Reporting Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted.
Message The message consists of actions taken, including user authentication, and so forth.
Reporting Log Example
In this example, the Reporting log shows the email gateway set at the information log level.
Wed Oct 3 13:39:53 2007 Info: Period minute using 0 (KB)
Wed Oct 3 13:39:53 2007 Info: Period month using 1328 (KB)
Wed Oct 3 13:40:02 2007 Info: Update 2 registered appliance at 2007-10-03-13-40
Wed Oct 3 13:40:53 2007 Info: Pages found in cache: 1304596 (99%). Not found: 1692
Wed Oct 3 13:40:53 2007 Info: Period hour using 36800 (KB)
Wed Oct 3 13:40:53 2007 Info: Period day using 2768 (KB)
Wed Oct 3 13:40:53 2007 Info: Period minute using 0 (KB)
Wed Oct 3 13:40:53 2007 Info: Period month using 1328 (KB)
Wed Oct 3 13:40:53 2007 Info: HELPER checkpointed in 0.00580507753533 seconds
Wed Oct 3 13:41:02 2007 Info: Update 2 registered appliance at 2007-10-03-13-41
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1188
Logging
Using Reporting Query Logs
Wed Oct 3 13:41:53 2007 Info: Pages found in cache: 1304704 (99%). Not found: 1692
Wed Oct 3 13:41:53 2007 Info: Period hour using 36800 (KB)
Wed Oct 3 13:41:53 2007 Info: Period day using 2768 (KB)
Wed Oct 3 13:41:53 2007 Info: Period minute using 0 (KB)
Wed Oct 3 13:41:53 2007 Info: Period month using 1328 (KB)
Wed Oct 3 13:42:03 2007 Info: Update 2 registered appliance at 2007-10-03-13-42
Using Reporting Query Logs
The following table shows the statistics recorded in reporting query logs.
Table 147: Reporting Query Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted.
Message The message consists of actions taken, including user authentication, and so forth.
Reporting Query Log Example
In this example, the reporting query log shows the email gateway running a daily outgoing email traffic query
for the period from August 29 to October 10, 2007.
Tue Oct 2 11:30:02 2007 Info: Query: Closing interval handle 811804479.
Tue Oct 2 11:30:02 2007 Info: Query: Closing interval handle 811804480.
Tue Oct 2 11:30:02 2007 Info: Query: Closing query handle 302610228.
Tue Oct 2 11:30:02 2007 Info: Query: Merge query with handle 302610229 for
['MAIL_OUTGOING_TRAFFIC_SUMMARY.
DETECTED_SPAM', 'MAIL_OUTGOING_TRAFFIC_SUMMARY.DETECTED_VIRUS',
'MAIL_OUTGOING_TRAFFIC_SUMMARY.THREAT_CONTENT_FILTER',
'MAIL_OUTGOING_TRAFFIC_SUMMARY.TOTAL_CLEAN_RECIPIENTS',
'MAIL_OUTGOING_TRAFFIC_SUMMARY.TOTAL_RECIPIENTS_PROCESSED'] for rollup period "day" with
interval range 2007-08-29 to 2007-10-01
with key constraints
None sorting on ['MAIL_OUTGOING_TRAFFIC_SUMMARY.DETECTED_SPAM'] returning results from
0 to 2 sort_ascending=False.
Tue Oct 2 11:30:02 2007 Info: Query: Closing query handle 302610229.
Tue Oct 2 11:30:02 2007 Info: Query: Merge query with handle 302610230 for
['MAIL_OUTGOING_TRAFFIC_SUMMARY.
TOTAL_HARD_BOUNCES', 'MAIL_OUTGOING_TRAFFIC_SUMMARY.TOTAL_RECIPIENTS_DELIVERED',
'MAIL_OUTGOING_TRAFFIC_SUMMARY.TOTAL_RECIPIENTS'] for rollup period "day" with interval
range 2007-08-29 to
2007-10-01 with key constraints None sorting on
['MAIL_OUTGOING_TRAFFIC_SUMMARY.TOTAL_HARD_BOUNCES'] returning
results from 0 to 2 sort_ascending=False.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1189
Logging
Using Updater Logs
Tue Oct 2 11:30:02 2007 Info: Query: Closing query handle 302610230.
Using Updater Logs
Table 148: Updater Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted.
Message The message consists of system service update information, as well as AsyncOS
checking for updates and the scheduled date and time of the next update.
Updater Log Example
In this example, the logs show the email gateway being updated with new McAfee Anti-Virus definitions.
Fri Sep 19 11:07:51 2008 Info: Starting scheduled update
Fri Sep 19 11:07:52 2008 Info: Acquired server manifest, starting update 11
Fri Sep 19 11:07:52 2008 Info: Server manifest specified an update for mcafee
Fri Sep 19 11:07:52 2008 Info: mcafee was signalled to start a new update
Fri Sep 19 11:07:52 2008 Info: mcafee processing files from the server manifest
Fri Sep 19 11:07:52 2008 Info: mcafee started downloading files
Fri Sep 19 11:07:52 2008 Info: mcafee downloading remote file
"http://stage-updates.ironport.com/mcafee/dat/5388"
Fri Sep 19 11:07:52 2008 Info: Scheduled next update to occur at Fri Sep 19 11:12:52
2008
Fri Sep 19 11:08:12 2008 Info: mcafee started decrypting files
Fri Sep 19 11:08:12 2008 Info: mcafee decrypting file
"mcafee/dat/5388" with method "des3_cbc"
Fri Sep 19 11:08:17 2008 Info: mcafee started decompressing files
Fri Sep 19 11:08:17 2008 Info: mcafee started applying files
Fri Sep 19 11:08:17 2008 Info: mcafee applying file "mcafee/dat/5388"
Fri Sep 19 11:08:18 2008 Info: mcafee verifying applied files
Fri Sep 19 11:08:18 2008 Info: mcafee updating the client manifest
Fri Sep 19 11:08:18 2008 Info: mcafee update completed
Fri Sep 19 11:08:18 2008 Info: mcafee waiting for new updates
Fri Sep 19 11:12:52 2008 Info: Starting scheduled update
Fri Sep 19 11:12:52 2008 Info: Scheduled next update to occur at Fri Sep 19 11:17:52
2008
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1190
Logging
Updater Log Example
Fri Sep 19 11:17:52 2008 Info: Starting scheduled update
Fri Sep 19 11:17:52 2008 Info: Scheduled next update to occur at Fri Sep 19 11:22:52
2008
Updater Log Example
In this example, the logs show the automatic updates being disabled and backup being applied to the Sophos
Anti-Virus definitions.
Fri Mar 10 15:05:55 2017 Debug: Skipping update request for “postx”
Fri Mar 10 15:05:55 2017 Debug: postx updates disabled
Fri Mar 10 15:05:55 2017 Debug: Skipping update request for “postx”
Fri Mar 10 15:05:55 2017 Trace: command session starting
Fri Mar 10 15:05:55 2017 Info: Automatic updates disabled for engine Sophos engine
Fri Mar 10 15:05:55 2017 Info: Sophos: Backup update applied successfully
Fri Mar 10 15:05:55 2017 Info: Internal SMTP system attempting to send a message to
[email protected]
with subject ‘Automatic updates are now disabled for sophos’ attempt #0).
Fri Mar 10 15:05:55 2017 Debug: amp feature key disabled
Fri Mar 10 15:05:55 2017 Debug: Skipping update request for “amp”
Fri Mar 10 15:05:55 2017 Debug: amp feature key disabled
Understanding Tracking Logs
Tracking logs record information about the email operations of AsyncOS. The log messages are a subset of
the messages recorded in the mail logs.
The tracking logs are used by the email gateway's message tracking component to build the message tracking
database. Because the log files are consumed in the process of building the database, the tracking logs are
transient. The information in tracking logs is not designed to be read or analyzed by humans.
You can also view tracking information from multiple email gateways using the Cisco Secure Manager Email
and Web Gateway.
Using Authentication Logs
The authentication log records successful user logins and unsuccessful login attempts.
Table 149: Authentication Log Statistics
Statistic Description
Timestamp Time that the bytes were transmitted.
Message The message consists of the username and the user privilege role details (for example,
‘admin,’ ‘operator,’ and so on) of a user who attempted to log in to the email gateway
and whether the user was authenticated successfully.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1191
Logging
Authentication Log Example
Authentication Log Example
In this example, the log shows the log in attempts by users “admin,” “joe,” and “dan.”
Wed Sep 17 15:16:25 2008 Info: Begin Logfile
Wed Sep 17 15:16:25 2008 Info: Version: 6.5.0-262 SN: XXXXXXX-XXXXX
Wed Sep 17 15:16:25 2008 Info: Time offset from UTC: 0 seconds
Wed Sep 17 15:18:21 2008 Info: User admin was authenticated successfully.
Wed Sep 17 16:26:17 2008 Info: User joe failed authentication.
Wed Sep 17 16:28:28 2008 Info: User joe was authenticated successfully.
Wed Sep 17 20:59:30 2008 Info: User admin was authenticated successfully.
Wed Sep 17 21:37:09 2008 Info: User dan failed authentication.
Example of Two-Factor Authentication Login Failure due to incorrect passcode
In this example, the log shows the two-factor authentication login failure due to incorrect passcode entered.
Thu Mar 16 05:47:47 2017 Info: Trying RADIUS server example.cisco.com
Thu Mar 16 05:48:18 2017 Info: Two-Factor RADIUS Authentication failed.
Thu Mar 16 05:48:48 2017 Info: An authentication attempt by the user **** from
21.101.210.150 failed
Example of Two-Factor Authentication Login Failure due to time-out
In this example, the log shows the two-factor authentication login failure due to a time-out.
Thu Mar 16 05:46:04 2017 Info: Trying RADIUS server example.cisco.com
Thu Mar 16 05:46:59 2017 Info: RADIUS server example.cisco.com communication error. No
valid responses from server (timeout).
Thu Mar 16 05:46:59 2017 Info: Two-Factor Authentication RADIUS servers timed out.
Authentication could fail due to this.
Example of Two-Factor Authentication Login Success
In this example, the log shows the two-factor authentication login was successful.
Thu Mar 16 05:49:05 2017 Info: Trying RADIUS server example.cisco.com
Thu Mar 16 05:49:05 2017 Info: Two-Factor RADIUS Authentication was successful.
Thu Mar 16 05:49:05 2017 Info: The user admin successfully logged on from 21.101.210.150
with privilege admin using an HTTPS connection.
Using Configuration History Logs
A configuration history log consists of a configuration file with an additional section listing the name of the
user, a description of where in the configuration the user made changes, and the comment the user entered
when committing the change. Each time a user commits a change, a new log is created containing the
configuration file after the change.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1192
Logging
Configuration History Log Example
Configuration History Log Example
In this example, the configuration history log shows that the user (admin) added a guest user to the table that
defines which local users are allowed to log in to the system.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE config SYSTEM "config.dtd">
<!--
XML generated by configuration change.
Change comment: added guest user
User: admin
Configuration are described as:
This table defines which local users are allowed to log into the system.
Product: Cisco IronPort M160 Messaging Gateway(tm) Appliance
Model Number: M160
Version: 6.7.0-231
Serial Number: 000000000ABC-D000000
Number of CPUs: 1
Memory (GB): 4
Current Time: Thu Mar 26 05:34:36 2009
Feature "Cisco IronPort Centralized Configuration Manager": Quantity = 10, Time
Remaining = "25 days"
Feature "Centralized Reporting": Quantity = 10, Time Remaining = "9 days"
Feature "Centralized Tracking": Quantity = 10, Time Remaining = "30 days"
Feature "Centralized Spam Quarantine": Quantity = 10, Time Remaining = "30 days"
Feature "Receiving": Quantity = 1, Time Remaining = "Perpetual"
-->
<config>
Using External Threat Feeds Engine Logs
The ETF Logs contain information about the ETF engine, status, configuration, and so on. Most information
is at the Info or Debug level.
Example of External Threat Feeds Engine Logs
Thu Jun 7 04:54:15 2018 Info: THREAT_FEEDS: Job failed with exception: Invalid URL or Port
Thu Jun 7 05:04:13 2018 Info: THREAT_FEEDS: A delta poll is scheduled for the source: S1
Thu Jun 7 05:04:13 2018 Info: THREAT_FEEDS: A delta poll has started for the source: S1,
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1193
Logging
ETF Source Configuration Failure - Invalid Collection Name
domain: s1.co, collection: sss
Thu Jun 7 05:04:13 2018 Info: THREAT_FEEDS: Observables are being fetched from the source:
S1 between 2018-06-07 04:34:13+00:00 and 2018-06-07 05:04:13.185909+00:00
Thu Jun 7 05:04:13 2018 Info: THREAT_FEEDS: 21 observables were fetched from the source:
S1
Thu Jun 7 05:19:14 2018 Info: THREAT_FEEDS: A delta poll is scheduled for the source: S1
Thu Jun 7 05:19:14 2018 Info: THREAT_FEEDS: A delta poll has started for the source: S1,
domain: s1.co, collection: sss
ETF Source Configuration Failure - Invalid Collection Name
In this example, the log shows that your email gateway was not able to fetch threat feeds from an external
threat feed source because of an invalid collection name.
Info: THREAT_FEEDS: [TaxiiClient] Failed to poll threat feeds from following source:
hailataxii.com, cause of failure: Invalid Collection name
Solution
Go to Mail Policies > External Threat Feeds Manager page in the web interface or use the threatfeedsconfig
> sourceconfig subcommand in the CLI and enter the correct collection name for the configured external
threat feed source.
ETF Source Configuration Failure - HTTP Error
In this example, the log shows that your email gateway was not able to fetch threat feeds from an external
threat feed source because of an HTTP error.
Info: THREAT_FEEDS: [TaxiiClient] Failed to poll threat feeds from following source:
hailataxii.com , cause of failure: HTTP Error
Solution
Go to Mail Policies > External Threat Feeds Manager page in the web interface or use the threatfeedsconfig
> sourceconfig subcommand in the CLI and enter the correct polling path or user authentication credentials
for the configured external threat feed source.
ETF Source Configuration Failure - Invalid URL
In this example, the log shows that your email gateway was not able to fetch threat feeds from an external
threat feed source because of an invalid URL.
Info: THREAT_FEEDS: [TaxiiClient] Failed to poll threat feeds from following source:
hailataxii.com , cause of failure: HTTP Error
Solution
Go to Mail Policies > External Threat Feeds Manager page in the web interface or use the threatfeedsconfig
> sourceconfig subcommand in the CLI and enter the correct hostname or port number for the configured
external threat feed source.
Using Consolidated Event Logs
When configuring a log subscription with the log type as Consolidated Event Logs, use the ‘Log Fields’ option
if you want to include specific message attributes in a single log line output.
The following log fields are selected by default when you configure a log subscription with the log type as
Consolidated Event Log:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1194
Logging
Using Consolidated Event Logs
• ICID
• DCID
• Serial Number
• MID
Note You cannot remove any of the default log fields from the Selected Log Fields list.
Example of Consolidated Event Logs
In this example, the log shows all the available fields selected when you configure a log subscription with the
log type as Consolidated Event Logs.
Thu Mar 18 08:04:50 2021: CEF:0|Cisco|C100V Email Security Virtual Appliance|14.0.0-657
|ESA_CONSOLIDATED_LOG_EVENT|Consolidated Log
Event|5|deviceExternalId=42127C7DDEE76852677B-F80CE8074CD3
ESAMID=1053 ESAICID=134 ESAAMPVerdict=UNKNOWN ESAASVerdict=NEGATIVE ESAAVVerdict=NEGATIVE
ESACFVerdict=MATCH endTime=Thu Mar 18 08:04:46 2021 ESADLPVerdict=NOT_EVALUATED
dvc=10.10.193.13 ESAAttachmentDetails={'test.txt': {'AMP': {'Verdict': 'FILE UNKNOWN',
'fileHash': '7f843d263304fb0516d6210e9de4fa7f01f2f623074aab6e3ee7051f7b785cfa'},
'BodyScanner':
{'fsize': 10059}}} [email protected] ESAGMVerdict=NEGATIVE startTime=Thu Mar 18
08:04:29 2021
deviceInboundInterface=Incomingmail deviceDirection=0 ESAMailFlowPolicy=ACCEPT
[email protected]
cs1Label=MailPolicy cs1=DEFAULT ESAMFVerdict=NOT_EVALUATED act=QUARANTINED
ESAFinalActionDetails=To POLICY
cs4Label=ExternalMsgID cs4='<[email protected]>' ESAMsgSize=11873
ESAOFVerdict=POSITIVE
[email protected] ESAHeloIP=10.11.1.2 cfp1Label=SBRSScore cfp1=None ESASDRDomainAge=27
years 2 months 15 days
cs3Label=SDRThreatCategory cs3=N/A cs6Label=SDRRepScore cs6=Weak ESASPFVerdict={'mailfrom':
{'result': 'None',
'sender': '[email protected]'}, 'helo': {'result': 'None', 'sender': 'postmaster'}, 'pra':
{'result': 'None', 'sender':
'[email protected]'}} sourceHostName=unknown ESASenderGroup=UNKNOWNLIST sourceAddress=10.11.1.2
msg='Testing'
Log Field CEF Field Name CEF Field Value
Prefix Fields
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1195
Logging
Using Consolidated Event Logs
Log Field CEF Field Name CEF Field Value
CEF format version Example: 0
Appliance vendor Example: Cisco
Appliance product Example: C100V Email Security
Virtual Appliance
Appliance version Example: 13.0.0-234
Event Class ID Example:
ESA_CONSOLIDATED_LOG_EVENT
Event Name Example: Consolidated Log Event
Severity Example: 5
GUI Fields
Serial Number deviceExternalId Example:
42156AC79142E979C5CD-02DE66639E9C
ICID Timestamp startTime Example: Mon Jul 29 11:22:22
2019
ICID ESAICID Example: 199
Listener Name deviceInboundInterface(for Example: Inbound
incoming mails)
Example: Outbound
deviceOutboundInterface(for
outgoing mails)
Sender IP sourceAddress Example: 10.10.2.75
Sender Domain sourceHostName Example: demo.cisco.com
Mail Direction deviceDirection Example: 0
0 -> incoming
1 -> outgoing
Mail Language cs5 Example:
cs5Label=ESAMsgLanguage
cs5=English
SBRS Score cfp1 Example: cfp1Label=SBRSScore,
cfp1=1.1
Data IP dvc Example: 10.10.2.75
Mail Sender Geo Location cs2 Example: cs2Label=GeoLocation
cs2=India
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1196
Logging
Using Consolidated Event Logs
Log Field CEF Field Name CEF Field Value
Message Too Big from Sender ESAMsgTooBigFromSender Example: true
Possible Values:
true/false
Rate Limited IP ESARateLimitedIP Example: 10.10.2.75
Mail Policy Name cs1 Example: cs1Label=MailPolicy
cs1=default
Mail Flow Policy Name ESAMailFlowPolicy Example: ACCEPT
Sender Group Name ESASenderGroup Example: UNKNOWNLIST
DHA IP ESADHASource Example: 10.10.2.75
Recipients duser Example: [email protected]
Remote IP/Helo Domain IP ESAHeloIP Example: 10.10.2.75
Remote Host/ Helo Domain ESAHeloDomain Example: test.com
TLS Outgoing Connection Status ESATLSOutConnStatus Example: Success
Possible Values:
Success/Failure
TLS Outgoing Protocol ESATLSOutProtocol Example: TLSv1.2
TLS Outgoing Cipher ESATLSOutCipher Example:
ECDHE-RSA-AES128-GCM-SHA256
TLS Incoming Connection Status ESATLSInConnStatus Example: Success
Possible Values:
Success/Failure
TLS Incoming Protocol ESATLSInProtocol Example: TLSv1.2
TLS Incoming Cipher ESATLSInCipher Example:
ECDHE-RSA-AES128-GCM-SHA256
DMARC Verdict ESADMARCVerdict Example: Success
Possible Values:
PermFailure/TempFailure/
Reject/Success
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1197
Logging
Using Consolidated Event Logs
Log Field CEF Field Name CEF Field Value
DKIM Verdict ESADKIMVerdict Example: Pass
Possible Values:
Pass/Neutral/TempError/
PermError/HardFail/None
SPF Verdict ESASPFVerdict Example:
ESASPFVerdict={'mailfrom':
{'sender': '[email protected]', 'result':
'SoftFail'}, 'helo': {'sender':
'postmaster', 'result': 'None'}}
Possible Values:
Pass/Neutral/SoftFail/Fail/
TempError/PermError
Friendly From ESAFriendlyFrom Example: [email protected]
Mail From suser Example: [email protected]
Reply-To ESAReplyTo Example: [email protected]
Subject msg Example: This is a sample subject
MID ESAMID Example: 101
Message ID cs4 Example: cs1Label=ExternalMsgID
cs1=20190729112221.42958.40626
@vm21esa0075.cs21
Message Size ESAMsgSize Example: ESAMsgSize=32199
SDR Reputation Score cs6 Example: cs6Label= SDRRepScore
cs6=Tainted
SDR Consolidated Domain Age ESASDRDomainAge Example: 1 year 21 days
SDR Consolidated Threat Category cs3 Example: cs3Label=
SDRThreatCategory
cs3=mal
Message Filters Verdict Message Filters Verdict Example: MATCH
Possible Values:
NOT EVALUATED/MATCH/NO
MATCH
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1198
Logging
Using Consolidated Event Logs
Log Field CEF Field Name CEF Field Value
AS Verdict ESAASVerdict Example: POSITIVE
Possible Values:
Not
EVALUATED/NEGATIVE/SUSPECT/
BULK_MAIL/SOCIAL_MAIL/MARKE
TING_MAIL/POSITIVE
AV Verdict ESAAVVerdict Example: POSITIVE
Possible Values:
NOT
EVALUATED/NEGATIVE/REPAIRED
/ENCRYPTED/UNSCANNABLE/POSI
TIVE
AMP Verdict ESAAMPVerdict Example: UNKNOWN
Possible Values:
NOT
EVALUATED/CLEAN/FA_PENDING/
UNKNOWN/SKIPPED/
UNSCANNABLE
/LOW_RISK/MALICIOUS
Graymail Verdict ESAGMVerdict Example: POSITIVE
Possible Values:
NOT
EVALUATED/POSITIVE/NEGATIVE
Content Filters Verdict ESACFVerdict Example: MATCH
Possible Values:
NOT EVALUATED/MATCH/NO
MATCH
Outbreak Filters Verdict ESAOFVerdict Example: NEGATIVE
Possible Values:
NOT
EVALUATED/POSITIVE/NEGATIVE
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1199
Logging
Using Consolidated Event Logs
Log Field CEF Field Name CEF Field Value
DLP Verdict ESADLPVerdict Example: VIOLATION
Possible Values:
NOT EVALUATED/NO
TRIGGER/VIOLATION/NO
VIOLATION
URL Details ESAURLDetails Example:
{url1:{expanded_url:<>,
category:<>,
wbrs_score:<>, in_attachment:<>,
Attachment_with_url:<>,},url2:{…}}
Note A URL is truncated if it
contains more than 255
characters
File Details ESAAttachmentDetails Example:
{name1:{source:
{<>hash:<>,
verdicts:<>}}}
Note A filename is truncated
if it contains more than
255 characters.
Mailbox Auto-Remediation Details ESAMARAction Example:
{action:<>;succesful_rcpts=<>;failed
_recipients=<>;filename=<>}
DCID ESADCID Example: 199
DCID Timestamp EndTime Example: Mon Jul 29 09:55:07
2019
DANE Status ESADaneStatus Example: success
Possible Values:
success/failure
DANE Host ESADaneHost Example: testdomain.com
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1200
Logging
Using CSN Logs
Log Field CEF Field Name CEF Field Value
Message Final Action act Example: act=DELIVERED
Possible Values:
DROPPED/BOUNCED/DELIVERED
- if the message is not quarantined.
QUARANTINED - if the message
is quarantined.
DQ - if the message is sent to
Delayed Quarantine. This is an
exception and not a quarantine type.
Message Final Action Details ESAFinalActionDetails Example:
act=DROPPED
ESAFinalActionDetails= By AMP
act=QUARANTINED
ESAFinalActionDetails=To SPAM
Note If there is no value for a selected log field (for example, 'DKIMVerdict' because DKIM is not enabled on your
email gateway), the log field is not included in the log message.
Using CSN Logs
The CSN logs contain details about the CSN data uploads. The CSN data ( email gateway and feature usage
details can be seen at the trace level.
Examples of CSN Data Log Entries:
• In this example, the log shows that the email gateway was not able to send the CSN data to Cisco because
the email gateway smart license was not registered with Cisco Smart Software Manager (CSSM).
Tue Apr 7 12:52:47 2020 Warning: Device is not
registered with CSSM. Skipping upload of CSN data
Solution: Make sure that you register your email gateway smart license with Cisco Smart Software
Manager (CSSM).
• In this example, the log shows that the email gateway was not able to send the CSN data to Cisco because
of a Cisco Security Services Exchange (SSE) connectivity error.
Thu Apr 9 13:32:46 2020 Warning: The appliance
failed to upload CSN data. reason for failure:
SSE error: HTTP Error 503: Service Unavailable
Solution: Make sure that you disable CSN and enable it again on your email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1201
Logging
Using Advanced Phishing Protection Logs
Using Advanced Phishing Protection Logs
The Advanced Phishing Protection logs contain information related to Cisco Advanced Phishing Protection
Cloud Service. Most information is at the Info or Critical level.
Examples of Advanced Phishing Protection Data Log Entries:
• In this example, the log shows that the email gateway was not able to forward the message headers to
Cisco Advanced Phishing Protection Cloud Service because the service expired.
Wed May 6 18:21:40 2020 Info: eaas : You cannot
forward the MID [877] Message Headers to Cisco Advanced
Phishing Protection Cloud Service as the service has
expired
• In this example, the log shows that the Cisco Advanced Phishing Protection Cloud Service has expired
and is disabled in your email gateway.
Wed May 6 18:21:40 2020 Info: eaas : Cisco
Advanced Phishing Protection Cloud Service has expired
and is disabled. Contact your Cisco Account manager to
renew the service and then enable it.
Solution: Contact your Cisco Account manager to renew the service and then enable it.
• In this example, the log shows that the Cisco Advanced Phishing Protection Cloud Service will expire
on a particular date.
Fri May 8 04:50:26 2020 Info: eaas : Cisco
Advanced Phishing Protection Cloud Service expires on
2020-05-10 07:00:00. You need to contact your Cisco Account
manager to renew the service.
Solution: Contact your Cisco Account manager to renew the service.
Using Audit Logs
The Audit logs record AAA (Authentication, Authorization, and Accounting) events. Most information is at
the debug or trace level.
Example of Audit Log Entries:
• In this example, the log shows when a user (for example, admin):
• Logged in to the web interface of the email gateway.
• Logged out of the web interface of the email gateway.
Tue Aug 25 12:33:17 2020 Info: Appliance: mail1.example.com,
Interaction Mode: GUI, User: admin, Source IP: 192.168.1.1, Destination IP: 192.168.2.2,
Event: Successful login
Tue Aug 25 12:33:17 2020 Info: Appliance: mail1.example.com,
Interaction Mode: GUI, User: admin, Source IP: 192.168.1.1, Event: Session established
successfully
Tue Aug 25 12:33:58 2020 Info: Appliance: mail1.example.com,
Interaction Mode: GUI, User: admin, Source IP: 192.168.1.1, Event: User logged out
Tue Aug 25 12:33:58 2020 Info: Appliance: mail1.example.com,
Interaction Mode: GUI, User: admin, Source IP: 192.168.1.1, Event: Session terminated
• In this example, the log shows that a user (for example, admin) entered the logconfig CLI command.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1202
Logging
Using Audit Logs
Thu Oct 8 13:33:38 2020 Info: Appliance: mail1.example.com, Interaction Mode: CLI,
User: admin,
Source IP: 192.168.1.1, Event: User input was 'logconfig'
Thu Oct 8 13:33:46 2020 Info: Appliance: mail1.example.com, Interaction Mode: CLI,
User: admin,
Source IP: 192.168.1.1, Event: User input was 'Enter'
• In this example, the log shows that a user (for example, admin) viewed the GUI pages on the legacy web
interface of the email gateway.
Thu Oct 8 13:35:07 2020 Info: Appliance: mail1.example.com, Interaction Mode: GUI,
User: admin,
Source IP: 192.168.1.1, Location: /network/dns, Event: User visited the web page.
Thu Oct 8 13:35:13 2020 Info: Appliance: mail1.example.com, Interaction Mode: GUI,
User: admin,
Source IP: 192.168.1.1, Location: /system_administration/sslconfig, Event: User visited
the web page.
Thu Oct 8 13:35:24 2020 Info: Appliance: mail1.example.com, Interaction Mode: GUI,
User: admin,
Source IP: 192.168.1.1, Location: /monitor/mail_reports/threatfeeds_report, Event: User
visited the web page.
• In this example, the log shows that a new user (for example, admin) is added to the email gateway using
the web interface, but the changes are not committed.
Thu Oct 8 13:36:30 2020 Info: Appliance: mail1.example.com, Interaction Mode: GUI,
User: admin,
Source IP: 192.168.1.1, Location: /system_administration/access/users, Event: Added
user "admin" and changes
will reflect after commit.
Thu Oct 8 13:37:22 2020 Info: Appliance: mail1.example.com, Interaction Mode: GUI,
User: admin,
Source IP: 192.168.1.1, Location: /system_administration/access/users, Event: Deleted
user "admin" and changes
will reflect after commit.
• In this example, the log shows that a user (for example, admin) discarded all the changes that were not
committed on the web interface of the email gateway.
Thu Oct 8 13:39:44 2020 Info: Appliance: mail1.example.com, Interaction Mode: GUI,
User: admin,
Source IP: 192.168.1.1, Location: /commit, Event: User discarded all uncommitted changes.
• In this example, the log shows that a user (for example, admin) discarded all the changes that were not
committed through the CLI.
Thu Oct 8 13:41:38 2020 Info: Appliance: mail1.example.com, Interaction Mode: CLI,
User: admin,
Source IP: 192.168.1.1, Event: User discarded all uncommitted changes.
• In this example, the log shows that a user (for example, admin) made configuration changes to the Web
UI session timeout.
Note You can view more details of the configuration changes made in your email
gateway by viewing the Configuration History Logs or by enabling the debug
mode for the audit logs.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1203
Logging
Using Audit Logs
Thu Oct 8 13:45:46 2020 Info: Appliance: mail1.example.com, User: admin,
Event: The following configuration changes were commited with comment - 'N/A'
Thu Oct 8 13:45:46 2020 Info: * [standalone] Number of seconds before the Web UI session
times out.
• In this example, the log shows that the AsyncOS APIs could not fetch the log subscriptions because the
authentication failed.
Thu Oct 8 13:52:28 2020 Debug: 08/Oct/2020 13:52:28 +0000 Error - Code: 401,
Details: Unauthorized (No permission -- see authorization schemes)
Thu Oct 8 13:52:28 2020 Info: Appliance: mail1.example.com, Interaction Mode: API,
User: admin, Role: Role Not Available, Source IP: 192.168.1.1, Destination IP:
192.168.2.2,
Location: GET /esa/api/v2.0/config/logs/subscriptions/ HTTP/1.0, Event: User is not
valid.
• In this example, the log shows that the AsyncOS APIs could fetch the log subscriptions because the
authentication was successful.
Thu Oct 8 13:52:37 2020 Info: Appliance: mail1.example.com, Interaction Mode: API,
User: admin, Role: Administrator, Source IP: 192.168.1.1, Destination IP: 192.168.2.2,
Location: GET /esa/api/v2.0/config/logs/subscriptions/ HTTP/1.0, Event: API Access
Success.
• In this example, the log shows that:
• A new user (for example, admin) is added to the email gateway using the CLI, but the changes were
not committed.
• The existing user account details are updated in the email gateway using the CLI, but the changes
were not committed.
Thu Oct 8 13:42:48 2020 Info: Appliance: mail1.example.com, Interaction Mode: CLI,
User: admin, Source IP: 192.168.1.1, Event: Added user "hops" and changes will reflect
after commit
Thu Oct 8 13:43:26 2020 Info: Appliance: mail1.example.com, Interaction Mode: CLI,
User: admin,
Source IP: 192.168.1.1, Event: Updated user "hops" and changes will reflect after commit
• In this example, the log shows that a user (for example, admin) performed a message tracking search on
the new web interface of the email gateway.
Mon Oct 12 04:04:47 2020 Info: Appliance: mail1.example.com, Interaction Mode: API,
User: admin,
Role: Administrator, Source IP: 192.168.1.1, Destination IP: 192.168.2.2,
Location: GET /esa/api/v2.0/message-tracking/messages?startDate=2020-10-12T00:00:00.000Z
&endDate=2020-10-12T04:13:00.000Z&ciscoHost=All_Hosts&searchOption=messages&offset=0&limit=100
HTTP/1.0,
Event: API Access Success.
Note The actions that you perform on the new web interface of the email gateway (for
example, tracking, reporting, or quarantine search) are recorded as logs based on
the corresponding APIs used for these actions.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1204
Logging
Using CSA Logs
Using CSA Logs
The Cisco Secure Awareness cloud service information is posted to the Mail Logs. Most information is at the
Info or Debug level.
Examples of Cisco Secure Awareness Log Entries:
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because of an invalid token.
Tue Oct 13 10:12:59 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Security Awareness cloud service failed because
of an invalid token.
Solution: Make sure you obtain a valid authentication token from the Cisco Secure Awareness cloud
service.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because of a connection error.
Wed Oct 14 10:59:36 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Security Awareness cloud service failed because
of a connection error.
Solution: Verify the firewall configuration settings used to connect your email gateway to the Cisco
Secure Awareness cloud service.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because of an internal server error.
Wed Oct 14 10:59:36 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Security Awareness cloud service failed because
of an internal server error.
Solution: Contact Cisco Support for technical assistance.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because the SSL certificate verification failed.
Wed Oct 14 11:02:46 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Security Awareness cloud service failed because
the SSL certificate verification failed.
Solution: Add the required CA certificate of the proxy server in the custom certificate authority list of
your email gateway.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because the proxy authentication failed.
Wed Oct 14 11:09:48 2020 Warning: CSA:
The download of the Repeat Clickers list from
the Cisco Security Awareness cloud service failed
because the proxy authentication failed.
Solution: Check whether the proxy server is configured with the correct authentication credentials in
your email gateway.
• In this example, the log shows that a request to the Cisco Secure Awareness cloud service failed because
the Report API was not enabled on the Cisco Secure Awareness cloud service.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1205
Logging
Log Subscriptions
Mon Aug 17 15:35:42 2020 Warning: CSA:
The download of the Repeat Clickers list failed.
A request to the CSA cloud service failed because
the Report API was not enabled on the CSA cloud service
Solution: Check the Enable Report API check box in Environment > Settings > Report API tab of the
Cisco Secure Awareness cloud service.
• In this example, the log shows that the Cisco Secure Awareness feature expires on a particular date.
2020-10-15 08:00:11,968 INFO csa The Cisco Security
Awareness feature expires on 2029-12-28T23:59:59Z. You need to
contact your Cisco Account Manager to renew the license.
Solution: Contact your Cisco Account Manager to renew the license.
• In this example, the log shows that the Cisco Secure Awareness feature license has expired, and the
feature is disabled on your email gateway.
2020-10-27 13:33:21,714 CRITICAL csa The Cisco Security
Awareness feature license has expired, and the feature is
disabled on your email gateway. Contact your Cisco Account Manager
to renew the license.
Solution: Contact your Cisco Account Manager to renew the license.
• In this example, the log shows that the downloaded Repeat Clickers list is empty.
Tue Oct 13 10:10:18 2020 Info: CSA: The downloaded
Repeat Clickers list is empty.
Solution: Create simulated phishing messages in the Cisco Secure Awareness cloud service and send
them to the recipients in your organization.
• In this example, the log shows that the download of the Repeat Clickers list from the Cisco Secure
Awareness cloud service failed because you have reached the maximum number of download attempts.
Fri Oct 16 05:22:08 2020 Warning: CSA: The download
of the Repeat Clickers list from the Cisco Security Awareness
cloud service failed because you have reached the maximum
number of attempts.
Solution: Contact Cisco Support to increase the number of attempts to download the Repeat Clickers
list from the Cisco Secure Awareness cloud service.
Log Subscriptions
• Configuring Log Subscriptions, on page 1206
• Creating a Log Subscription in the GUI, on page 1208
• Configuring Global Settings for Logging, on page 1209
• Rolling Over Log Subscriptions, on page 1211
• Configuring Host Keys, on page 1215
Configuring Log Subscriptions
Use the Log Subscriptions page on the System Administration menu (or the logconfig command in the
CLI) to configure a log subscription. Log subscriptions create log files that store information about AsyncOS
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1206
Logging
Log Levels
activity, including errors. A log subscription is either retrieved or delivered (pushed) to another computer.
Generally, log subscriptions have the following attributes:
Table 150: Log File Attributes
Attribute Description
Log type Defines the type of information recorded and the format of the logs subscriptions.
See Table: Log Types for more information.
Log Name Nickname for the log subscription to be used for your future reference.
Log Fields Select the required log fields to include in the consolidated event log line for a
given message.
Note The Serial Number and MID log fields are selected by default, and
you cannot deselect these fields.
Note This field is only applicable when you are configuring a log
subscription with the log type as Consolidated Event Logs.
File Name Used for the physical name of the file when written to disk. If multiple email
gateways are being used, the log filename should be unique to identify the system
that generated the log file.
Rollover by File Size The maximum size the file can reach before rolling over.
Rollover by Time Sets the time interval for file rollovers.
Rate Limit Sets the maximum number of logged events in the log file, within the specified
time range (in seconds).
The default time range value is 10 seconds.
Log level Sets the level of detail for each log subscription.
Retrieval method Defines how the log subscription will be obtained from the email gateway.
Log Levels
Log levels determine the amount of information delivered in a log. Logs can have one of five levels of detail.
A more detailed setting creates larger log files and puts more drain on system performance. More detailed
settings include all the messages contained in less detailed settings, plus additional messages. As the level of
detail increases, system performance decreases.
Note Log levels may be selected for all mail log types.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1207
Logging
Creating a Log Subscription in the GUI
Table 151: Log Levels
Log Level Description
Critical The least detailed setting. Only errors are logged. Using this setting will not allow
you to monitor performance and other important activities; however, the log files will
not reach their maximum size as quickly. This log level is equivalent to the syslog
level “Alert.”
Warning All errors and warnings created by the system. Using this setting will not allow you
to monitor performance and other important activities. This log level is equivalent to
the syslog level “Warning.”
Information The information setting captures the second-by-second operations of the system. For
example, connections opened or delivery attempts. The Information level is the
recommended setting for logs. This log level is equivalent to the syslog level “Info.”
Debug Use the Debug log level when you are trying to discover the cause of an error. Use
this setting temporarily, and then return to the default level. This log level is equivalent
to the syslog level “Debug.”
Trace The Trace log level is recommended only for developers. Using this level causes a
serious degradation of system performance and is not recommended. This log level
is equivalent to the syslog level “Debug.”
Creating a Log Subscription in the GUI
Procedure
Step 1 Choose System Administration > Log Subscriptions.
Step 2 Click Add Log Subscription.
Step 3 Select a log type and enter the log name (for the log directory) as well as the name for the log file itself.
Step 4 [Only for Consolidated Event Logs] Select the required log fields to include in the log line for a given message.
Step 5 Specify the maximum file size before AsyncOS rolls over the log file as well as a time interval between
rollovers. See Rolling Over Log Subscriptions, on page 1211 for more information on rolling over log files.
Step 6 Select the log level. The available options are Critical, Warning, Information, Debug, or Trace.
Step 7 Configure the log retrieval method.
Step 8 Submit and commit your changes.
Editing Log Subscriptions
Procedure
Step 1 Choose System Administration > Log Subscriptions.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1208
Logging
Configuring Global Settings for Logging
Step 2 Click the name of the log in the Log Settings column.
Step 3 Make changes to the log subscription.
Step 4 Submit and commit your changes.
Configuring Global Settings for Logging
The system periodically records system measurements within the Text Mail Logs and the Status Logs. Use
the Edit Settings button in the Global Settings section of the System Administration > Log Subscriptions
page (or the logconfig -> setup command in the CLI) to configure:
• System metrics frequency. This is the amount of time, in seconds, that the system waits between recording
measurements.
• Whether to record the Message-ID headers.
• Whether to record the remote response status code.
• Whether to record the subject header of the original message.
• A list of headers that should be logged for each message.
All logs optionally include the following three pieces of data:
1. Message-ID
When this option is configured, every message will have its Message ID header logged, if it is available.
Note that this Message-ID may have come from the received message or may have been generated by
AsyncOS itself. For example:
Tue Apr 6 14:38:34 2004 Info: MID 1 Message-ID Message-ID-Content
2. Remote Response
When this option is configured, every message will have its remote response status code logged, if it is
available. For example:
Tue Apr 6 14:38:34 2004 Info: MID 1 RID [0] Response 'queued as 9C8B425DA7'
The remote response string is the human-readable text received after the response to the DATA command
during the delivery SMTP conversation. In this example, the remote response after the connection host
issued the data command is “queued as 9C8B425DA7.”
[...]
250 ok hostname
250 Ok: queued as 9C8B425DA7
Whitespace, punctuation, (and in the case of the 250 response, the OK characters) are stripped from the
beginning of the string. Only whitespace is stripped from the end of the string. For example, email gateways,
by default, respond to the DATA command with this string: 250 Ok: Message MID accepted. So, the
string “Message MID accepted” would be logged if the remote host were another email gateway.
3. Original Subject Header
When this option is enabled, the original subject header of each message is included in the log.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1209
Logging
Logging Message Headers
Tue May 31 09:20:27 2005 Info: Start MID 2 ICID 2
Tue May 31 09:20:27 2005 Info: MID 2 ICID 2 From: <[email protected]>
Tue May 31 09:20:27 2005 Info: MID 2 ICID 2 RID 0 To: <[email protected]>
Tue May 31 09:20:27 2005 Info: MID 2 Message-ID '<[email protected]>'
Tue May 31 09:20:27 2005 Info: MID 2 Subject 'Monthly Reports Due'
Logging Message Headers
In some cases, it is necessary to record the presence and contents of a message’s headers as they pass through
the system. You specify the headers to record in the Log Subscriptions Global Settings page (or via the
logconfig -> logheaders subcommand in the CLI). The email gateway records the specified message headers
in the Text Mail Logs, the Delivery Logs, and the Bounce Logs. If the header is present, the system records
the name of the header and the value. If a header is not present, nothing is recorded in the logs.
Note The system evaluates all headers that are present on a message, at any time during the processing of the
message for recording, regardless of the headers specified for logging.
The RFC for the SMTP protocol is located at http://www.faqs.org/rfcs/rfc2821.html and defines user-defined
headers.
If you have configured headers to log via the logheaders command, the header information appears after the
delivery information:
Table 152: Log Headers
Header name Name of the header
Value Contents of the logged header
For example, specifying “date, x-subject” as headers to be logged will cause the following line to appear in
the mail log:
Tue May 31 10:14:12 2005 Info: Message done DCID 0 MID 3 to RID [0]
[('date', 'Tue, 31 May 2005 10:13:18 -0700'), ('x-subject', 'Logging this header')]
Configuring Global Settings for Logging Using the GUI
Procedure
Step 1 Choose System Administration > Log Subscriptions.
Step 2 Scroll down to the Global Settings section.
Step 3 Click Edit Settings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1210
Logging
Rolling Over Log Subscriptions
Step 4 Specify information including the system measurement frequency, whether to include Message-ID headers
in mail logs, whether to include the remote response, and whether to include the original subject header of
each message.
Step 5 Enter any other headers you wish to include in the logs.
Step 6 Submit and commit your changes.
Rolling Over Log Subscriptions
To prevent log files on the email gateway from becoming too large, AsyncOS performs a “rollover” and
archives a log file when it reaches a user-specified maximum file size or time interval and creates a new file
for incoming log data. Based on the retrieval method defined for the log subscription, the older log file is
stored on the email gateway for retrieval or delivered to an external computer. See Log Retrieval Methods,
on page 1149 for more information on how to retrieve log files from the email gateway.
When AsyncOS rolls over a log file, it performs the following actions:
• Renames the current log file with the timestamp of the rollover and a letter “s” extension signifying
saved.
• Creates a new log file and designates the file as current with the “current” extension.
• Transfers the newly saved log file to a remote host (if using the push-based retrieval method).
• Transfers any previously unsuccessful log files from the same subscription (if using the push-based
retrieval method).
• Deletes the oldest file in the log subscription if the total number of files to keep on hand has been exceeded
(if using the poll-based retrieval method).
You define a log subscription’s rollover settings when creating or editing the subscription using the
System Administration > Log Subscriptions page in the GUI or the logconfig command in the CLI.
The two settings available for triggering a log file rollover are:
• A maximum file size.
• A time interval.
Rollover By File Size
AsyncOS rolls over log files when they reach a maximum file size to prevent them from using too much disk
space. When defining a maximum file size for rollovers, use the suffix m for megabytes and k for kilobytes.
For example, enter 10m if you want AsyncOS to roll over the log file when it reaches 10 megabytes.
Rollover By Time
If you want to schedule rollovers to occur on a regular basis, you can select one of the following time intervals:
• None. AsyncOS only performs a rollover when the log file reaches the maximum file size.
• Custom Time Interval. AsyncOS performs a rollover after a specified amount of time has passed since
the previous rollover. To create a custom time interval for scheduled rollovers, enter the number of days,
hours, and minutes between rollovers using d , h , and m as suffixes.
• Daily Rollover. AsyncOS performs a rollover every day at a specified time. If you choose a daily rollover,
enter the time of day you want AsyncOS to perform the rollover using the 24-hour format (HH:MM).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1211
Logging
Rollover By Time
Only the GUI offers the Daily Rollover option. If you want to configure a daily rollover using the logconfig
command in the CLI, choose the Weekly Rollover option and use an asterisk (*) to specify that AsyncOS
should perform the rollover on every day of the week.
• Weekly Rollover. AsyncOS performs a rollover on one or more days of the week at a specified time.
For example, you can set up AsyncOS to rollover the log file every Wednesday and Friday at midnight.
To configure a weekly rollover, choose the days of the week to perform the rollover and the time of day
in the 24-hour format (HH:MM).
If you are using the CLI, you can use a dash ( - ) to specify a range of days, an asterisk ( * ) to specify
every day of the week, or a comma ( , ) to separate multiple days and times.
The following table shows how to use the CLI to roll over the files for a log subscription on Wednesday
and Friday at midnight ( 00:00 ).
Table 153: Weekly Log Rollover Settings in the CLI
Do you want to configure time-based log files rollover? [N]> y
Configure log rollover settings:
1. Custom time interval.
2. Weekly rollover.
[1]> 2
1. Monday
2. Tuesday
3. Wednesday
4. Thursday
5. Friday
6. Saturday
7. Sunday
Choose the day of week to roll over the log files. Separate multiple days with comma,
or use "*" to specify every day of a week.
Also you can use dash to specify a range like "1-5":
[]> 3, 5
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1212
Logging
Rolling Over Log Subscriptions on Demand
Enter the time of day to rollover log files in 24-hour format (HH:MM).
You can specify hour as "*" to match every hour, the same for minutes.
Separate multiple times of day with comma:
[]> 00:00
Rolling Over Log Subscriptions on Demand
To roll over log subscriptions immediately using the GUI:
Procedure
Step 1 On the System Administration > Log Subscriptions page, mark the checkbox to the right of the logs you wish
to roll over.
Step 2 Optionally, you can select all logs for rollover by marking the All checkbox.
Step 3 Once one or more logs have been selected for rollover, the Rollover Now button is enabled. Click the Rollover
Now button to roll over the selected logs.
Viewing Recent Log Entries in the GUI
Before You Begin
You must have the HTTP or HTTPS service enabled on the Management interface in order to view logs via
the GUI.
Procedure
Step 1 Select System Administration > Log Subscriptions.
Step 2 Select the log subscription in the Log Files column of the table.
Step 3 Sign in.
Step 4 Select a log file to view it in your browser or to save it to disk.
Viewing Recent Log Entries in the CLI (tail Command)
AsyncOS supports a tail command, which shows the latest entries of configured logs on the email gateway.
Issue the tail command and select the number of a currently configured log to view it. Use Ctrl-C to exit from
the tail command.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1213
Logging
Example
Example
In the following example, the tail command is used to view the system log. (This log tracks user comments
from the commit command, among other things.) The tail command also accepts the name of a log to view
as a parameter: tail mail_logs .
mail3.example.com> tail
Currently configured logs:
1. "antispam" Type: "Anti-Spam Logs" Retrieval: Manual Download
2. "antivirus" Type: "Anti-Virus Logs" Retrieval: Manual Download
3. "asarchive" Type: "Anti-Spam Archive" Retrieval: Manual Download
4. "authentication" Type: "Authentication Logs" Retrieval: Manual Download
5. "avarchive" Type: "Anti-Virus Archive" Retrieval: Manual Download
6. "bounces" Type: "Bounce Logs" Retrieval: Manual Download
7. "cli_logs" Type: "CLI Audit Logs" Retrieval: Manual Download
8. "encryption" Type: "Encryption Logs" Retrieval: Manual Download
9. "error_logs" Type: "IronPort Text Mail Logs" Retrieval: Manual Download
10. "euq_logs" Type: "IronPort Spam Quarantine Logs" Retrieval: Manual Download
11. "euqgui_logs" Type: "IronPort Spam Quarantine GUI Logs" Retrieval: Manual Download
12. "ftpd_logs" Type: "FTP Server Logs" Retrieval: Manual Download
13. "gui_logs" Type: "HTTP Logs" Retrieval: Manual Download
14. "mail_logs" Type: "IronPort Text Mail Logs" Retrieval: Manual Download
15. "reportd_logs" Type: "Reporting Logs" Retrieval: Manual Download
16. "reportqueryd_logs" Type: "Reporting Query Logs" Retrieval: Manual Download
17. "scanning" Type: "Scanning Logs" Retrieval: Manual Download
18. "slbld_logs" Type: "Safe/Block Lists Logs" Retrieval: Manual Download
19. "sntpd_logs" Type: "NTP logs" Retrieval: Manual Download
20. "status" Type: "Status Logs" Retrieval: Manual Download
21. "system_logs" Type: "System Logs" Retrieval: Manual Download
22. "trackerd_logs" Type: "Tracking Logs" Retrieval: Manual Download
23. "updater_logs" Type: "Updater Logs" Retrieval: Manual Download
Enter the number of the log you wish to tail.
[]> 19
Press Ctrl-C to stop.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1214
Logging
Configuring Host Keys
Mon Feb 21 12:25:10 2011 Info: PID 274: User system commit changes: Automated Update for
Quarantine Delivery Host
Mon Feb 21 23:18:10 2011 Info: PID 19626: User admin commit changes:
Mon Feb 21 23:18:10 2011 Info: PID 274: User system commit changes: Updated filter logs
config
Mon Feb 21 23:46:06 2011 Info: PID 25696: User admin commit changes: Receiving
suspended.
^Cmail3.example.com>
Configuring Host Keys
Use the logconfig -> hostkeyconfig subcommand to manage host keys for use with SSH when pushing
logs to other servers from the email gateway. SSH servers must have a pair of host keys, one private and one
public. The private host key resides on the SSH server and cannot be read by remote machines. The public
host key is distributed to any client machine that needs to interact with the SSH server.
Note To manage user keys, see Managing Secure Shell (SSH) Keys, on page 1001.
The hostkeyconfig subcommand performs the following functions:
Table 154: Managing Host Keys - List of Subcommands
Command Description
New Add a new key.
Edit Modify an existing key.
Delete Delete an existing key.
Scan Automatically download a host key.
Print Display a key.
Host Display system host keys. This is the value to place in the remote system's ‘known_hosts’
file.
Fingerprint Display system host key fingerprints.
User Display the public key of the system account that pushes the logs to the remote machine. This
is the same key that is displayed when setting up an SCP push subscription. This is the value
to place in the remote system's 'authorized_keys' file.
In the following example, AsyncOS scans for host keys and add them for the host:
mail3.example.com> logconfig
Currently configured logs:
[ list of logs ]
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1215
Logging
Configuring Host Keys
Choose the operation you want to perform:
- NEW - Create a new log.
- EDIT - Modify a log subscription.
- DELETE - Remove a log subscription.
- SETUP - General settings.
- LOGHEADERS - Configure headers to log.
- HOSTKEYCONFIG - Configure SSH host keys.
[]> hostkeyconfig
Currently installed host keys:
1. mail3.example.com ssh-dss [ key displayed ]
Choose the operation you want to perform:
- NEW - Add a new key.
- EDIT - Modify a key.
- DELETE - Remove a key.
- SCAN - Automatically download a host key.
- PRINT - Display a key.
- HOST - Display system host keys.
- FINGERPRINT - Display system host key fingerprints.
- USER - Display system user keys.
[]> scan
Please enter the host or IP address to lookup.
[]> mail3.example.com
Choose the ssh protocol type:
1. SSH1:rsa
2. SSH2:rsa
3. SSH2:dsa
4. All
[4]>
SSH2:dsa
mail3.example.com ssh-dss
[ key displayed ]
SSH2:rsa
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1216
Logging
Configuring Host Keys
mail3.example.com ssh-rsa
[ key displayed ]
SSH1:rsa
mail3.example.com 1024 35
[ key displayed ]
Add the preceding host key(s) for mail3.example.com? [Y]>
Currently installed host keys:
1. mail3.example.com ssh-dss [ key displayed ]
2. mail3.example.com ssh-rsa [ key displayed ]
3. mail3.example.com 1024 35 [ key displayed ]
Choose the operation you want to perform:
- NEW - Add a new key.
- EDIT - Modify a key.
- DELETE - Remove a key.
- SCAN - Automatically download a host key.
- PRINT - Display a key.
- HOST - Display system host keys.
- FINGERPRINT - Display system host key fingerprints.
- USER - Display system user keys.
[]>
Currently configured logs:
[ list of configured logs ]
Choose the operation you want to perform:
- NEW - Create a new log.
- EDIT - Modify a log subscription.
- DELETE - Remove a log subscription.
- SETUP - General settings.
- LOGHEADERS - Configure headers to log.
- HOSTKEYCONFIG - Configure SSH host keys.
[]>
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1217
Logging
Configuring Host Keys
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1218
CHAPTER 45
Centralized Management Using Clusters
This chapter contains the following sections:
• Overview of Centralized Management Using Clusters , on page 1219
• Cluster Requirements, on page 1220
• Cluster Organization, on page 1220
• Creating and Joining a Cluster, on page 1222
• Managing Clusters, on page 1229
• Administering a Cluster from the GUI, on page 1234
• Cluster Communication, on page 1236
• Loading a Configuration in Clustered Email Gateway, on page 1241
• Best Practices and Frequently Asked Questions, on page 1242
Overview of Centralized Management Using Clusters
The Cisco centralized management feature allows you to manage and configure multiple email gateways at
the same time, reducing administration time and ensuring a consistent configuration across your network.
You do not need to purchase additional hardware for managing multiple email gateways. The centralized
management feature provides increased reliability, flexibility, and scalability within your network, allowing
you to manage globally while complying with local policies.
A cluster is defined as a set of machines that share configuration information. Within the cluster, machines (
email gateways) are divided into groups ; every cluster will contain at least one group. A given machine is a
member of one and only one group. An administrator user can configure different elements of the system on
a cluster-wide, group-wide, or per-machine basis, enabling the segmentation of email gateways based on
network, geography, business unit, or other logical relationships.
Clusters are implemented as a peer-to-peer architecture; there is no primary/secondary relationship within a
cluster. You may log into any machine to control and administer the cluster. (Some configuration commands,
however, are limited. See Restricted Commands, on page 1233.)
The user database is shared across all machines in the cluster. That is, there will be only one set of users and
one administrator user (with the associated passphrases) for an entire cluster. All machines that join a cluster
will share a single administrator passphrase which is referred to as the admin passphrase of the cluster.
Note Having more than 20 email gateways in a cluster can cause errors in cluster communication.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1219
Centralized Management Using Clusters
Cluster Requirements
Cluster Requirements
• Machines in a cluster must have resolvable hostnames in DNS. Alternatively, you can use IP addresses
instead, but you may not mix the two.
See DNS and Hostname Resolution, on page 1237. Cluster communication is normally initiated using the
DNS hostnames of the machines.
• A cluster must consist entirely of machines running the same version of AsyncOS.
See Upgrading Machines in a Cluster, on page 1231 for how to upgrade members of a cluster.
• Machines can either join the cluster via SSH (typically on port 22) or via the Cluster Communication
Service (CCS).
See Cluster Communication, on page 1236.
• Once machines have joined the cluster, they can communicate via SSH or via Cluster Communication
Service. The port used in configurable. SSH is typically enabled on port 22, and by default CCS is on
port 2222, but you can configure either of these services on a different port.
In addition to the normal firewall ports that must be opened for the email gateway, clustered machines
communicating via CCS must be able to connect with each other via the CCS port. See Cluster
Communication, on page 1236.
• You must use the Command Line Interface (CLI) command clusterconfig to create, join, or
configure clusters of machines.
Once you have created a cluster, you can manage non-cluster configuration settings from either the GUI
or the CLI.
See Creating and Joining a Cluster, on page 1222 and Administering a Cluster from the GUI, on page 1234.
• If you have enabled two-factor authentication on your email gateway, you can join it to a cluster machine
using pre-shared keys. Use the clusterconfig > prepjoin command in the CLI to configure this setting.
Or
Disable two-factor authentication on your email gateway, before you create or join a cluster. For more
information, see Disabling Two-Factor Authentication, on page 996.
Cluster Organization
Within a cluster, configuration information is divided into 3 groupings or levels . The top level describes
cluster settings; the middle level describes group settings; and the lowest level describes machine-specific
settings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1220
Centralized Management Using Clusters
Initial Configuration Settings
Figure 79: Cluster Level Hierarchy
Within each level there will be one or more specific members for which settings may be configured; these
are referred to as modes. A mode refers to a named member at a specified level. For example, the group “usa”
represents one of two group modes in the diagram. While levels are a general term, modes are specific; modes
are always referred to by name. The cluster depicted in the above figure has six modes.
Although settings are configured at a given level, they are always configured for a specific mode. It is not
necessary to configure settings for all modes within a level. The cluster mode is a special case. Because there
can only be one cluster, all settings configured for the cluster mode can be said to be configured at the cluster
level.
You should normally configure most settings at the cluster level. However, settings that have been specifically
configured at lower levels will override settings configured at higher levels. Thus, you can override cluster-mode
settings with group-mode or machine-mode settings.
For example, you might start by configuring the Good Neighbor Table in cluster mode; all machines in the
cluster would use that configuration. Then, you might also configure this table in machine mode for machine
newyork . In this case, all other machines in the cluster will still use the good neighbor table defined at the
cluster level, but the machine newyork will override the cluster settings with its individual machine mode
settings.
The ability to override cluster settings for specific groups or machines gives you a lot of flexibility. However,
if you find yourself configuring many settings individually in machine mode, you will lose much of the ease
of administration that clusters were intended to provide.
Initial Configuration Settings
For most features, when you begin to configure settings for a new mode, those settings will initially be empty
by default. There is a distinction between empty settings and having no settings in a mode. As an example,
consider a very simple cluster composed of one group and one machine. Imagine that you have an LDAP
query configured at the cluster level. There are no settings configured at the group or machine levels:
Cluster (ldap queries: a, b, c)
Group
Machine
Now, imagine that you create new LDAP query settings for the group. The result will be something like this:
Cluster (ldap queries: a, b, c)
Group (ldap queries: None)
Machine
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1221
Centralized Management Using Clusters
Creating and Joining a Cluster
The group-level settings now override the cluster-level setting; however, the new group settings are initially
empty. The group mode does not actually have any LDAP queries of its own configured. Note that a machine
within this group will inherit this “empty” set of LDAP queries from the group.
Next, you can add an LDAP query to the group, for example:
Cluster (ldap queries: a, b, c)
Group (ldap queries: d)
Machine
Now the cluster level has one set of queries configured while the group has another set of queries. The machine
will inherit its queries from the group.
Creating and Joining a Cluster
You cannot create or join a cluster from the Graphical User Interface (GUI). You must use the Command
Line Interface (CLI) to create, join, or configure clusters of machines. Once you have created a cluster, you
can change configuration settings from either the GUI or the CLI.
Caution If you have enabled two-factor authentication on your email gateway, you can join it to a cluster machine
using pre-shared keys. Use the clusterconfig > prepjoin command in the CLI to configure this setting.
Or
Disable two-factor authentication on your email gateway, before you create or join a cluster. For more
information, see Disabling Two-Factor Authentication, on page 996.
The clusterconfig Command
A machine can create or join a cluster only via the clusterconfig command.
• When a new cluster is created , all of that cluster’s initial settings will be inherited from the machine
that creates the cluster. If a machine was previously configured in “standalone” mode, its standalone
settings are used when creating the cluster.
• When a machine joins a cluster, all of that machine’s clusterable settings will be inherited from the cluster
level. In other words, everything except certain machine-specific settings (IP addresses, etc) will be lost
and will be replaced with the settings from the cluster and/or the group selected for that machine to join.
If a machine was previously configured in “standalone” mode, its standalone settings are used when
creating the cluster, and no settings at the machine level are maintained.
If the current machine is not already part of a cluster, issuing the clusterconfig command presents the option
to join an existing cluster or create a new one.
At this point you can add machines to the new cluster. Those machines can communicate via SSH or CCS.
newyork.example.com> clusterconfig
Do you want to join or create a cluster?
1. No, configure as standalone.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1222
Centralized Management Using Clusters
Joining an Existing Cluster
2. Create a new cluster.
3. Join an existing cluster over SSH.
4. Join an existing cluster over CCS.
[1]> 2
Enter the name of the new cluster.
[]> americas
New cluster committed: Wed Jun 22 10:02:04 2005 PDT
Creating a cluster takes effect immediately, there is no need to commit.
Cluster americas
Choose the operation you want to perform:
- ADDGROUP - Add a cluster group.
- SETGROUP - Set the group that machines are a member of.
- RENAMEGROUP - Rename a cluster group.
- DELETEGROUP - Remove a cluster group.
- REMOVEMACHINE - Remove a machine from the cluster.
- SETNAME - Set the cluster name.
- LIST - List the machines in the cluster.
- LISTDETAIL - List the machines in the cluster with detail.
- DISCONNECT - Temporarily detach machines from the cluster.
- RECONNECT - Restore connections with machines that were previously detached.
- PREPJOIN - Prepare the addition of a new machine over CCS.
[]>
Joining an Existing Cluster
From the host you want to add to the cluster, issue the clusterconfig command to join the existing cluster.
You can choose to join the cluster over SSH or over CCS (cluster communication service).
In order to join a host to an existing cluster, you must:
• be able to validate the SSH host key of a machine in the cluster
• know the IP address of a machine in the cluster and be able to connect to this machine in the cluster (for
example, via SSH or CCS)
• know the administrator passphrase for the admin user on a machine belonging to the cluster
Joining an Existing Cluster over SSH
The following table demonstrates adding the machine losangeles.example.com to the cluster using the SSH
option.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1223
Centralized Management Using Clusters
Joining an Existing Cluster over SSH
losangeles.example.com> clusterconfig
Do you want to join or create a cluster?
1. No, configure as standalone.
2. Create a new cluster.
3. Join an existing cluster over SSH.
4. Join an existing cluster over CCS.
[1]> 3
While joining a cluster, you will need to validate the SSH host key of the remote
machine to which you are joining. To get the public host key
fingerprint of the remote host, connect to the cluster and run: logconfig ->
hostkeyconfig -> fingerprint.
WARNING: All non-network settings will be lost. System will inherit the values set at
the group or cluster mode for the non-network settings. Ensure that the cluster
settings are compatible with your network settings (e.g. dnsconfig settings)
Do you want to enable the Cluster Communication Service on
losangeles.example.com? [N]> n
Enter the IP address of a machine in the cluster.
[]> IP address is entered
Enter the remote port to connect to. The must be the normal admin ssh
port, not the CCS port.
[22]> 22
Enter the admin passphrase for the cluster.
The administrator passphrase for the clustered machine is entered
Please verify the SSH host key for IP address:
Public host key fingerprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Is this a valid key for this host? [Y]> y
Joining cluster group Main_Group.
Joining a cluster takes effect immediately, there is no need to commit.
Cluster americas
Choose the operation you want to perform:
- ADDGROUP - Add a cluster group.
- SETGROUP - Set the group that machines are a member of.
- RENAMEGROUP - Rename a cluster group.
- DELETEGROUP - Remove a cluster group.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1224
Centralized Management Using Clusters
Joining an Existing Cluster over CCS
- REMOVEMACHINE - Remove a machine from the cluster.
- SETNAME - Set the cluster name.
- LIST - List the machines in the cluster.
- LISTDETAIL - List the machines in the cluster with detail.
- DISCONNECT - Temporarily detach machines from the cluster.
- RECONNECT - Restore connections with machines that were previously detached.
- PREPJOIN - Prepare the addition of a new machine over CCS.
[]>
(Cluster americas)>
Joining an Existing Cluster over CCS
Use CCS instead of SSH if you cannot use SSH. The only advantage of CCS is that only cluster communication
happens over that port (no user logins, SCP, etc). To add another machine to an existing cluster via CCS, use
the prepjoin subcommand of clusterconfig to prepare the machine to be added to the cluster. In this example,
the prepjoin command is issued on the machine newyork to prepare the machine losangeles to be added to
the cluster.
The prepjoin command involves obtaining the user key of the host you want to add to the cluster by typing
clusterconfig prepjoin print in the CLI of that host, and then copying the key into the command line of
the host that is currently in the cluster.
Once a machine is already part of a cluster, the clusterconfig command allows you to configure various
settings for the cluster.
Choose the operation you want to perform:
- ADDGROUP - Add a cluster group.
- SETGROUP - Set the group that machines are a member of.
- RENAMEGROUP - Rename a cluster group.
- DELETEGROUP - Remove a cluster group.
- REMOVEMACHINE - Remove a machine from the cluster.
- SETNAME - Set the cluster name.
- LIST - List the machines in the cluster.
- LISTDETAIL - List the machines in the cluster with detail.
- DISCONNECT - Temporarily detach machines from the cluster.
- RECONNECT - Restore connections with machines that were previously detached.
- PREPJOIN - Prepare the addition of a new machine over CCS.
[]> prepjoin
Prepare Cluster Join Over CCS
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1225
Centralized Management Using Clusters
Joining an Existing Cluster over CCS
No host entries waiting to be added to the cluster.
Choose the operation you want to perform:
- NEW - Add a new host that will join the cluster.
[]> new
Enter the hostname of the system you want to add.
[]> losangeles.example.com
Enter the serial number of the host mail3.example.com.
[]> unique serial number is added
Enter the user key of the host losangeles.example.com. This can be obtained by typing
"clusterconfig prepjoin print" in the CLI on mail3.example.com. Press enter on a blank
line to finish.
unique user key from output of prepjoin print is pasted
Host losangeles.example.com added.
Prepare Cluster Join Over CCS
1. losangeles.example.com (serial-number)
Choose the operation you want to perform:
- NEW - Add a new host that will join the cluster.
- DELETE - Remove a host from the pending join list.
[]>
(Cluster Americas)> clusterconfig
Cluster americas
Choose the operation you want to perform:
- ADDGROUP - Add a cluster group.
- SETGROUP - Set the group that machines are a member of.
- RENAMEGROUP - Rename a cluster group.
- DELETEGROUP - Remove a cluster group.
- REMOVEMACHINE - Remove a machine from the cluster.
- SETNAME - Set the cluster name.
- LIST - List the machines in the cluster.
- LISTDETAIL - List the machines in the cluster with detail.
- DISCONNECT - Temporarily detach machines from the cluster.
- RECONNECT - Restore connections with machines that were previously detached.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1226
Centralized Management Using Clusters
Joining an Existing Cluster over SSH with Pre-Shared Keys
- PREPJOIN - Prepare the addition of a new machine over CCS.
[]>
Joining an Existing Cluster over SSH with Pre-Shared Keys
The following table demonstrates how to join the machine (testmachine.example.com) to the cluster
(test_cluster) over SSH using pre-shared keys.
testmachine.example.com> clusterconfig
Do you want to join or create a cluster?
1. No, configure as standalone.
2. Create a new cluster.
3. Join an existing cluster over SSH.
4. Join an existing cluster over CCS.
[1]> 3
While joining a cluster, you will need to validate the SSH host key of the remote
machine to which you are joining. To get the public host key
fingerprint of the remote host, connect to the cluster and run: logconfig ->
hostkeyconfig -> fingerprint.
WARNING: All non-network settings will be lost. System will inherit the values set at
the group or cluster mode for the non-network settings. Ensure that the cluster
settings are compatible with your network settings (e.g. dnsconfig settings)
Do you want to enable the Cluster Communication Service on
testmachine.example.com? [N]>
Enter the IP address of a machine in the cluster.
[]> IP address entered
Enter the remote port to connect to. The must be the normal admin ssh
port, not the CCS port.
[22]>
Would you like to join this appliance to a cluster using pre-shared keys?
Use this option if you have enabled two-factor authentication on the appliance.) [Y]> yes
To join this appliance to a cluster using pre-shared keys, log in to the cluster machine,
run the clusterconfig > prepjoin > command, enter the
following details, and commit your changes.
Host: pod1226-esa07.ibesa
Serial Number: 42291A18D741EDB4C601-BC14E5579F34
User Key:
ssh-dss
AAAAB3NzaC1kc3MAAACBAJ6Xm+ja4aau9n4DOcJs/gGwEDEUWgERYchhgWApKt6IW+s58I7knGM81rQgQbNdNCO58D
EqaVGmP0Vyb0TTpgvh6f0mr80OuTgWh9bqg4uiOJvbKvlTvDt0o7//mTklm159zr2KT/qFH+9L5i+8iIMX62R5y+a
6E8JV0BrJCNAAAAFQCmK+WOu9HSribsC0f/5dVoADdxEwAAAIA5p7NR74rlSrs0JWWYItNAtE1SamAN+gqCOdUWGPPHT
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1227
Centralized Management Using Clusters
Adding Groups
qdrtBIlPQ9tfFoThZElqY4Tx8lku9laasoRLruQ2Z36R3bQGzIn4jzQqujvvbxTvLK9eLoSr8yFbEE3ZvuUo0+vhDn
LIDX2N65AQSQsTaOrKX+yQZ8yAVt48CsctpsDrgAAAIAVROGlWoSl8g3FFm2eRTa+/oZ+cMjv+pSZiZoiUCoaIlouc
u1ZDpN413QBnf6p/3D8wVD8m5uo8O4N/HXasAMektZvGoP4Sf+shItPuISRv3lrMTEYsD0sqVcMc7vIXUeD2jpOk7MB
ooVkTZB/rdTbNMfXrhDkNJ2IAPQQiUKVnw==
Before you proceed to the next step, make sure you add the ‘Host’, Serial Number’ and ‘User
Key’
details to the cluster machine.
Would you like to continue? [Y]> yes
Joining cluster group Main_Group.
Joining a cluster takes effect immediately, there is no need to commit.
Cluster test_cluster
Choose the operation you want to perform:
- ADDGROUP - Add a cluster group.
- SETGROUP - Set the group that machines are a member of.
- RENAMEGROUP - Rename a cluster group.
- DELETEGROUP - Remove a cluster group.
- REMOVEMACHINE - Remove a machine from the cluster.
- SETNAME - Set the cluster name.
- LIST - List the machines in the cluster.
- LISTDETAIL - List the machines in the cluster with detail.
- DISCONNECT - Temporarily detach machines from the cluster.
- RECONNECT - Restore connections with machines that were previously detached.
- PREPJOIN - Prepare the addition of a new machine over CCS.
[]>
(Cluster test_cluster)>
Adding Groups
All clusters must contain at least one group. When you create a new cluster, a default group called
Main_Group is created automatically. However, you may decide to create additional groups within your
cluster. This example shows how to create additional groups within an existing cluster and assign machines
to the new group(s).
Procedure
Step 1 Issue the clusterconfig command.
Step 2 Choose the addgroup subcommand and enter the name of the new group.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1228
Centralized Management Using Clusters
Managing Clusters
Step 3 Use the setgroup subcommand to choose machines for the new group.
Managing Clusters
Administering a Cluster from the CLI
For machines that are part of a cluster, the CLI can be switched into different modes. Recall that a mode refers
to a specific, named, member of a level.
The CLI mode determines precisely where a configuration setting will be modified. The default is “machine”
mode for the machine the user logged into, the “login host.”
Use the clustermode command to switch between different modes.
Table 155: Administering Clusters
Command Example Description
Prompt to switch cluster mode
clustermode
Switch to group mode for the group “northamerica”
clustermode group northamerica
Switch to machine mode for the machine “losangeles”
clustermode machine losangeles.example.com
The prompt in the CLI changes to indicate your current mode.
(Cluster Americas)>
or
(Machine losangeles.example.com)>
In machine mode, the prompt will include the fully qualified domain name of the machine.
Copying and Moving Settings
All non-restricted (see Restricted Commands, on page 1233) commands have new operations: CLUSTERSHOW
and CLUSTERSET . CLUSTERSHOW is used to show in which modes a command is configured (see New
Operation Added , on page 1232). The CLUSTERSET operation allows you to move or copy the current settings
(configurable with the current command) from one mode to another or between levels (e.g. from a machine
to a group).
A copy retains the settings for the current mode. A move resets (clears) the configuration of the current mode;
i.e., following a move, no settings will be configured for the current mode.
For example, if you have configured Good Neighbor Table settings (the destconfig command) for group
northamerica , and you decide that you want the entire cluster to have these settings, you can use the
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1229
Centralized Management Using Clusters
Experimenting with New Configurations
clusterset operation from within the destconfig command to copy (or move) the current settings to
the cluster mode. (See Experimenting with New Configurations, on page 1230.)
Caution Exercise caution when moving or copying configuration settings to avoid inconsistent dependencies. For
example, if you move or copy listeners with disclaimer stamping configured to another machine, and that new
machine does not have the same disclaimers configured, disclaimer stamping will not be enabled on the new
machine.
Experimenting with New Configurations
One of the most advantageous ways to use clusters is to experiment with new configuration settings. First
you make changes at the machine mode, in an isolated environment. Then, when you are satisfied with your
configuration, you move those configuration changes up to the cluster mode to make them available on all
machines.
The following example shows the steps to change a listener setting on one machine and then publish the setting
to the rest of the cluster when ready. Because listeners are normally configured at the cluster level, the example
starts by pulling the configuration down to machine mode on one machine before making and testing the
changes. You should test experimental changes of this type on one machine before making the change to the
other machines in the cluster.
Procedure
Step 1 Use the clustermode cluster command to change to the cluster mode.
Remember: the clustermode command is the CLI command you use to change modes to the cluster, group,
and machine levels.
Step 2 Type listenerconfig to see the listener settings configured for the cluster.
Step 3 Choose the machine you want to experiment with, then use the clusterset command to copy settings from the
cluster “down” to machine mode.
Step 4 Use the clustermode command to navigate to machine mode for the experimental machine, e.g.:
clustermode machine newyork.example.com
Step 5 In machine mode, on the experimental machine, issue the listenerconfig command to make changes specifically
for the experimental machine.
Step 6 Commit the changes.
Step 7 Continue to experiment with the configuration changes on the experimental machine, remembering to commit
the changes.
Step 8 When you are ready to apply your new settings to all the other machines, use the clusterset command to move
the settings up to the cluster mode.
Step 9 Commit the changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1230
Centralized Management Using Clusters
Leaving a Cluster Permanently (Removal)
Leaving a Cluster Permanently (Removal)
You use the REMOVEMACHINE operation of clusterconfig to remove a machine permanently from a cluster.
When a machine is permanently removed from a cluster, its configuration is “flattened” such that it will work
the same as it did when it was part of the cluster. For example, if there is only a cluster-mode Global
Unsubscribe table, the Global Unsubscribe table data will be copied to the machine’s local configuration when
the machine is removed from the cluster.
Upgrading Machines in a Cluster
A cluster does not allow the connected machines to have different versions of AsyncOS.
Before you install an AsyncOS upgrade, you need to disconnect each machine in the cluster via the clusterconfig
command. After you upgrade all the machines, the cluster can be reconnected via the clusterconfig command.
You can have two separate clusters running while you upgrade machines to the same version. You can also
upgrade clustered machines on the GUI Upgrades page.
You can download the upgrade in the background so that you do not need to disconnect the cluster machines
until you are ready to install the upgrade.
Note If you use the upgrade command before disconnecting the individual machine from the cluster, AsyncOS
disconnects all the machines in the cluster. Cisco Systems recommends that you disconnect each machine
from the cluster before upgrading it. Then, other machines can continue working as a cluster until each is
disconnected and upgraded.
Procedure
Step 1 On a machine in the cluster, use the disconnect operation of clusterconfig . For example, to disconnect the
machine losangeles.example.com , type clusterconfig disconnect losangeles .example.com. No commit is
necessary.
Step 2 Optionally, use the suspendlistener command to halt acceptance of new connections and messages during the
upgrade process.
Step 3 Issue the upgrade command to upgrade AsyncOS to a newer version.
Note Disregard any warnings or confirmation prompts about disconnecting all of the machines in the
cluster. Because you have disconnected the machine, AsyncOS does not disconnect the other
machines in the cluster at this point.
Step 4 Select the version of AsyncOS for the machine. The machine will reboot after the upgrade is complete.
Step 5 Use the resume command on the upgraded machine to begin accepting new messages.
Step 6 Repeat steps 1 - 5 for each machine in the cluster.
Note After you disconnect a machine from the cluster, you cannot use it to change the configurations of
other machines. Although you can still modify the cluster configuration, do not change it while
machines are disconnected because settings can become unsynchronized.
Step 7 After you have upgraded all the machines, use the reconnect operation of clusterconfig for each upgraded
machine to reconnect it. For example, to reconnect the machine losangeles.example.com , type clusterconfig
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1231
Centralized Management Using Clusters
CLI Command Support
reconnect losangeles .example.com. Note that you can only connect a machine to a cluster that is running the
same version of AsyncOS.
CLI Command Support
All Commands Are Cluster-aware
All CLI commands in AsyncOS are now cluster-aware. The behavior of some commands will change slightly
when issued in a cluster mode. For example, the behavior of the following commands changes when issued
on a machine that is part of a cluster:
The commit and clearchanges Commands
commit
The commit command commits all changes for all three levels of the cluster, regardless of which mode you
are currently in.
commitdetail
The commitdetail command provides details about configuration changes as they are propagated to all machines
within a cluster.
clearchanges
The clearchanges ( clear ) command clears all changes for all three levels of the cluster, regardless of which
mode you are currently in.
New Operation Added
CLUSTERSHOW
Within each command, there is now a CLUSTERSHOW operation that allows you to see in which modes a command
is configured.
When you enter a CLI command to perform an action that will be overridden by existing settings at a lower
level, you will be presented with a notification. For example, if you are in cluster mode and enter a command,
you may see a notification like this:
Note: Changes to these settings will not affect the following groups and machines
because they are overriding the cluster-wide settings:
East_Coast, West_Coast
facilities_A, facilities_B, receiving_A
A similar message would be printed if you are editing settings for a group mode.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1232
Centralized Management Using Clusters
Restricted Commands
Restricted Commands
Most CLI commands and their corresponding GUI pages can be run in any mode (cluster, group, or machine).
However, some commands and pages are restricted to one mode only.
The system interface (either the GUI and the CLI) will always will make it clear that a command is restricted
and how it is restricted. It is easy to switch to the appropriate mode for configuring the command.
• In the GUI, use the “Change Mode” menu or the “Settings for this features are currently defined at:”
links to switch modes.
• In the CLI, use the clustermode command to switch modes.
Table 156: Commands Restricted to Cluster Mode
clusterconfig sshconfig
clustercheck userconfig
passwd
If a you try to run one of these commands in group or machine mode, you will be given a warning message
and the opportunity to switch to the appropriate mode.
Note The passwd command is a special case because it needs to be usable by guest users. If a guest user issues the
passwd command on a machine in a cluster, it will not print the warning message but will instead just silently
operate on the cluster level data without changing the user’s mode. All other users will get the above written
behavior (consistent with the other restricted configuration commands).
The following commands are restricted to machine mode :
antispamstatus etherconfig resume suspenddel
antispamupdate featurekey resumedel suspendlistener
antivirusstatus hostrate resumelistener techsupport
antivirusupdate hoststatus rollovernow tophosts
bouncerecipients interfaceconfig routeconfig topin
deleterecipients ldapflush sbstatus trace
delivernow ldaptest setgateway version
diagnostic nslookup sethostname vofflush
dnsflush quarantineconfig settime vofstatus
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1233
Centralized Management Using Clusters
Administering a Cluster from the GUI
dnslistflush rate shutdown workqueue
dnslisttest reboot status
dnsstatus resetcounters suspend
If a you try to run one of the commands above in cluster or group mode, you will be given a warning message
and the opportunity to switch to an appropriate mode.
The following commands are further restricted to the login host (i.e., the specific machine you are logged
into). These commands require access to the local file system.
Table 157: Commands Restricted to Login Host Mode
last resetconfig tail upgrade
ping supportrequest telnet who
Administering a Cluster from the GUI
Although you cannot create or join clusters or administer cluster specific settings from the GUI (the equivalent
of the clusterconfig command), you can browse machines in the cluster, create, delete, copy, and move
settings among the cluster, groups, and machines (that is, perform the equivalent of the clustermode and
clusterset commands) from within the GUI.
The Incoming Mail Overview page is an example of a command that is restricted to the login host, because
the Mail Flow Monitoring data you are viewing is stored on the local machine. To view the Incoming Mail
Overview reports for another machine, you must log into the GUI for that machine.
Note the URL in the browser’s address field when clustering has been enabled on an email gateway. The URL
will contain the word machine , group , or cluster as appropriate. For example, when you first log
in, the URL of the Incoming Mail Overview page will appear as:
https:// hostnamemachine/serial_number /monitor/incoming_mail_overview
Note The Incoming Mail Overview and Incoming Mail Details pages on the Monitor menu are restricted to the
login machine.
The Mail Policies, Security Services, Network, and System Administration tabs contain pages that are not
restricted to the local machine. If you click the Mail Policies tab, the centralized management information in
the GUI changes.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1234
Centralized Management Using Clusters
Administering a Cluster from the GUI
Figure 80: Centralized Management Feature in the GUI: No Settings Defined
In the above figure, the machine is inheriting all of its configuration settings for the current feature from the
cluster mode. The settings being inherited in a light grey (preview).You can retain these settings or change
them, overriding the cluster level settings for this machine.
Note The inherited settings (preview display) will always show the settings inherited from the cluster. Use caution
when enabling or disabling dependent services among group and cluster levels. For more information, see
Copying and Moving Settings, on page 1229.
If you click the Override Settings link, you are taken to a new page for that feature. This page allows you to
create new configuration settings for machine mode. You may begin with the default settings, or, if you’ve
already configured settings in another mode, you can copy those settings to this machine.
Figure 81: Centralized Management Feature in the GUI: Create New Settings
Alternatively, as shown in Figure Centralized Management Feature in the GUI: No Settings Defined, you
can also navigate to modes where this configuration setting is already defined. The modes are listed in the
lower half of the centralized management box, under “Settings for this feature are currently defined at:”. Only
those modes where the settings are actually defined will be listed here. When you view a page for settings
that are defined in (and inherited from) another mode, the page will display those settings for you.
If you click on one of the listed modes (for example, the Cluster: Americas link as shown in Figure Centralized
Management Feature in the GUI: No Settings Defined), you will be taken to a new page that allows you to
view and manage the settings for that mode.
Figure 82: Centralized Management Feature in GUI: Settings Defined
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1235
Centralized Management Using Clusters
Cluster Communication
When settings are defined for a given mode, the centralized management box is displayed on every page in
a minimized state. Click the “Centralized Management Options” link to expand the box to show a list of
options available for the current mode with respect to the current page. Clicking the “Manage Settings” button
allows you to copy or move the current settings to a different mode or to delete those settings completely.
For example, in the following figure, the Centralized Management Options link has been clicked to present
the available options.
Figure 83: Centralized Management Feature in GUI: Manage Settings
On the right side of the box is the “Change Mode” menu. This menu displays your current mode and provides
the ability to navigate to any other mode (cluster, group, or machine) at any time.
Figure 84: The Change Mode Menu
When you navigate to a page that represents a different mode, the “Mode —” text on the left side of the
centralized management box will flash yellow, briefly, to alert you that your mode has changed.
Some pages within certain tabs are restricted to machine mode. However, unlike the Incoming Mail Overview
page (which is restricted to the current login host), these pages can be used for any machine in the cluster.
Figure 85: Centralized Management Feature: Machine Restricted
Choose which machine to administer from the Change Mode menu. You will see a brief flashing of the text
to remind you that you have changed modes.
Cluster Communication
Machines within a cluster communicate with each other using a mesh network. By default, all machines
connect to all other machines. If one link goes down, other machines will not be prevented from receiving
updates.
By default, all intra-cluster communication is secured with SSH. Each machine keeps an in-memory copy of
the route table and makes in-memory changes as necessary if links go down or up. Each machine also performs
a periodic “ping” (every 1 minute) of every other machine in the cluster. This ensures up-to-date link status
and maintains the connections in case a router or NAT has a timeout.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1236
Centralized Management Using Clusters
DNS and Hostname Resolution
Note If your email gateways are in a cluster mode, and you plan to access data (not related to configuration, for
example, viewing messages present in the quarantine or refreshing reports at a fast rate) of another email
gateway remotely; there will be cluster reconnection attempts that can generate alerts and errors. The email
gateways automatically will reconnect and manual intervention is not required..
DNS and Hostname Resolution
DNS is required to connect a machine to the cluster. Cluster communication is normally initiated using the
DNS hostnames of the machines (not the hostname of an interface on the machine). A machine with an
unresolvable hostname would be unable to actually communicate with any other machines in the cluster, even
though it is technically part of the cluster.
Your DNS must be configured to have the hostname point to the correct IP interface on the email gateway
that has SSH or CCS enabled. This is very important. If DNS points to another IP address that does not have
SSH or CCS enabled it will not find the host. Note that centralized management uses the “main hostname,”
as set with the sethostname command, not the per-interface hostname.
If you use an IP address to connect to another machine in the cluster, the machine you connect to must be
able to make a reverse look up of the connecting IP address. If the reverse look up times out because the IP
address isn’t in the DNS, the machine cannot connect to the cluster.
Clustering, Fully Qualified Domain Names, and Upgrading
DNS changes can cause a loss of connectivity after upgrading AsyncOS. Please note that if you need to change
the fully qualified domain name of a machine in the cluster (not the hostname of an interface on a machine
in the cluster), you must change the hostname settings via sethostname and update the DNS record for that
machine prior to upgrading AsyncOS.
Cluster Communication Security
Cluster Communication Security (CCS) is a secure shell service similar to a regular SSH service. Cisco
implemented CCS in response to concerns regarding using regular SSH for cluster communication. SSH
communication between two machines opens regular logins (admin, etc.) on the same port. Many administrators
prefer not to open regular logins on their clustered machines.
Tip: never enable Cluster Communication Services, even though it is the default, unless you have firewalls
blocking port 22 between some of your clustered machines. Clustering uses a full mesh of SSH tunnels (on
port 22) between all machines. If you have already answered Yes to enabling CCS on any machine, remove
all machines from the cluster and start again. Removing the last machine in the cluster removes the cluster.
CCS provides an enhancement where the administrator can open up cluster communication, but not CLI
logins. By default, the service is disabled. You will be prompted to enable CCS from the interfaceconfig
command when you are prompted to enable other services. For example:
Do you want to enable SSH on this interface? [Y]>
Which port do you want to use for SSH?
[22]>
Do you want to enable Cluster Communication Service on this interface?
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1237
Centralized Management Using Clusters
Cluster Consistency
[N]> y
Which port do you want to use for Cluster Communication Service?
[2222]>
The default port number for CCS is 2222. You may change this to another open, unused, port number if you
prefer. After the join is complete and the joining machine has all the configuration data from the cluster, the
following question is presented:
Do you want to enable Cluster Communication Service on this interface? [N]> y
Which port do you want to use for Cluster Communication Service?
[2222]>
Cluster Consistency
The machines that are “cluster aware” will continually verify network connections to other machines within
the cluster. This verification is done by periodic “pings” sent to other machines in the cluster.
If all attempts to communicate with a particular machine fail, then the machine that has been trying to
communicate will log a message saying that the remote host has disconnected. The system will send an alert
to the administrator that the remote host went down.
Even if a machine is down, the verification pings will continue to be sent. When a machine rejoins the cluster
network, a synchronization command will be issued so that any previously offline machines can download
any updates. The synchronization command will also determine if there have been any changes on one side
but not the other. If so, then the previously down machine will silently download the updates.
Disconnect/Reconnect
A machine may be disconnected from a cluster. Occasionally, you may intend to deliberately disconnect the
machine, for example, because you are upgrading the machine. A disconnect could also occur by accident,
for example, due to a power failure or other software or hardware error. A disconnect can also occur if one
email gateway attempts to open more than the maximum number of SSH connections allowed in a session.
A machine that is disconnected from a cluster can still be accessed directly and configured; however, any
changes made will not be propagated to other machines within the cluster until the disconnected machine
becomes reconnected.
When a machine reconnects to the cluster, it tries to reconnect to all machines at once.
In theory, two machines in a cluster that are disconnected could commit a similar change to their local databases
at the same time. When the machines are reconnected to the cluster, an attempt will be made to synchronize
these changes. If there is a conflict, the most recent change is recorded (supersedes any other changes).
During a commit, the email gateway checks every variable that is being changed. The commit data includes
version information, sequence identification numbers, and other information that can be compared. If the data
you are about to change is found to be in conflict with previous changes, you will be given the option to
discard your changes. For example, you might see something like this:
(Machine mail3.example.com)> clustercheck
This command is restricted to "cluster" mode. Would you like to switch to "cluster"
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1238
Centralized Management Using Clusters
Interdependent Settings
mode? [Y]> y
Checking Listeners (including HAT, RAT, bounce profiles)...
Inconsistency found!
Listeners (including HAT, RAT, bounce profiles) at Cluster enterprise:
mail3.example.com was updated Mon Sep 12 10:59:17 2005 PDT by 'admin' on
mail3.example.com
test.example.com was updated Mon Sep 12 10:59:17 2005 PDT by 'admin' on
mail3.example.com
How do you want to resolve this inconsistency?
1. Force entire cluster to use test.example.com version.
2. Force entire cluster to use mail3.example.com version.
3. Ignore.
[1]>
If you choose not to discard your changes, they are still intact (but uncommitted). You can review your changes
against the current settings and decide how to proceed.
You can also use the clustercheck command at any time to verify that the cluster is operating correctly.
losangeles> clustercheck
Do you want to check the config consistency across all machines in the cluster? [Y]> y
Checking losangeles...
Checking newyork...
No inconsistencies found.
Interdependent Settings
It is recommended that you avoid configuring the following settings on the email gateway.
In a centrally managed environment, some interdependent settings are configured in different modes. The
flexibility of the configuration model allows you to configure settings at multiple modes, and the laws of
inheritance govern which settings will be used on a per-machine basis. However, some settings have
dependencies on other settings, and the availability of the dependent settings’ configuration is not limited to
settings at the same mode. Thus, it is possible to configure a setting for one level that references a setting that
is configured for a specific machine at a different level.
The most common example of an interdependent setting involves a select field on a page that pulls data from
a different cluster section. For example, the following features can be configured in different modes:
• using LDAP queries
• using dictionaries or text resources
• using bounce or SMTP authentication profiles.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1239
Centralized Management Using Clusters
Interdependent Settings
Within centralized management, there are restricted and non-restricted commands. (See Restricted Commands,
on page 1233.) Non-restricted commands are generally configuration commands that can be shared across the
cluster.
The listenerconfig command is an example of a command that can be configured for all machines in
a cluster. Non-restricted commands represent commands that can be mirrored on all machines in a cluster,
and do not require machine-specific data to be modified.
Restricted commands, on the other hand, are commands that only apply to a specific mode. For example,
users cannot be configured for specific machines — there must be only one user set across the whole cluster.
(Otherwise, it would be impossible to login to remote machines with the same login.) Likewise, since the
Mail Flow Monitor data, System Overview counters, and log files are only maintained on a per-machine basis,
these commands and pages must be restricted to a machine.
You will notice that while Scheduled Reports may be configured identically across the whole cluster, the
viewing of reports is machine-specific. Therefore, within a single Scheduled Reports page in the GUI,
configuration must be performed at the cluster mode, but viewing of reports must be done at the machine
mode.
The System Time pages encompass the settz , ntpconfig , and settime commands, and thus
represents a mixture of restricted and non-restricted commands. In this case, settime must be restricted to
machine-only modes (since time settings are specific for machine), while settz and ntpconfig may be
configured at cluster or group modes.
Figure 86: Example of Interdependent Settings
In this representation, the listener “IncomingMail” is referencing a footer named “disclaimer” that has been
configured at the machine level only. The drop-down list of available footer resources shows that the footer
is not available on the machine “buttercup.run” which is also available in the cluster. There are two solutions
to this dilemma:
• promote the footer “disclaimer” from the machine level to the cluster level
• demote the listener to the machine level to remove the interdependency
In order to fully maximize the features of a centrally managed system, the former solution is preferred. Be
aware of interdependencies among settings as you tailor the configuration of your clustered machines.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1240
Centralized Management Using Clusters
Loading a Configuration in Clustered Email Gateway
Loading a Configuration in Clustered Email Gateway
AsyncOS allows you to load a cluster configuration in clustered email gateways. You can load the cluster
configuration in the following scenarios:
• If you are migrating from an on-premise environment to a hosted environment and you want to migrate
the on-premise cluster configuration to the hosted environment.
• If an email gateway in a cluster is down or needs to be retired and you want to load the configuration
from this email gateway to a new email gateway that you plan to add to the cluster.
• If you are adding more email gateways to your cluster and you want to load the configuration from one
of the existing email gateways in the cluster to the newly added email gateways.
• If you want to load a backed-up configuration to a cluster.
Depending on your requirements, you can load a cluster configuration or email gateway configuration from
a valid cluster configuration file.
Note You cannot load the configuration of a standalone email gateway on a clustered email gateway.
Before You Begin
• Make sure that you have a valid and complete XML configuration. See Loading a Configuration File,
on page 1019.
• Create a backup of the current configuration of the email gateway to which you plan to load the
configuration. See Saving and Exporting the Current Configuration File, on page 1019.
• Create a cluster setup with all the email gateways that you plan to have in your setup. See Creating and
Joining a Cluster, on page 1222.
Note You can have all the email gateways under one group. Ensure that the interfaces for cluster communication
in your setup have same names and SSH and CCS settings as in the XML configuration.
Procedure
Step 1 Click System Administration > Configuration File.
Step 2 Choose the cluster from the Mode drop-down menu.
Step 3 Depending on whether you want to a load cluster or email gateway configuration, do one of the following:
• Load Cluster Configuration
a. In the Load Configuration section, choose Cluster from the drop-down list.
b. Load the cluster configuration, and click Load. See Loading a Configuration File, on page 1019.
c. Assign groups from the loaded configuration to the email gateways in the cluster, and copy email
gateway configuration from the email gateways in the selected group to the respective email gateways.
Use the Group Configuration and Appliance Configuration drop-down lists.
If you do not want to copy an email gateway configuration, choose Don't Copy from the Appliance
Configuration drop-down list.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1241
Centralized Management Using Clusters
Best Practices and Frequently Asked Questions
1. Review the configuration. Click Review.
2. Click Confirm.
3. Click Continue.
• Load Email Gateway Configuration
a. In the Load Configuration section, choose Appliance in cluster from the drop-down list.
b. Load the configuration, and click Load. See Loading a Configuration File, on page 1019. Note that
you cannot load the configuration of a standalone email gateway on a clustered email gateway.
c. Choose the email gateway configuration from the loaded configuration and the intended email gateway
in the cluster to which you want to load the configuration. Use the drop-down lists.
d. Click OK.
e. Click Continue.
f. To load the email gateway configuration to more email gateways, repeat Step a through Step e.
Step 4 Review the network settings of the clustered email gateways, and commit your changes.
Best Practices and Frequently Asked Questions
Best Practices
When you create the cluster, the machine you happen to be logged into is automatically added to the cluster
as the first machine, and also added to the Main_Group. Its machine level settings effectively get moved to
the cluster level as much as possible. There are no settings at the group level, and the only settings left at the
machine level are those which do not make sense at the cluster level, and cannot be clustered. Examples are
IP addresses, featurekeys, etc.
Leave as many settings at the cluster level as possible. If only one machine in the cluster needs a different
setting, copy that cluster setting to the machine level for that machine. Do not move that setting. If you move
a setting which has no factory default (e.g. HAT table, SMTPROUTES table, LDAP server profile, etc.), the
systems inheriting the cluster settings will have blank tables and will probably not process email.
To have that machine re-inherit the cluster setting, manage the CM settings and delete the machine setting.
You will only know if a machine is overriding the cluster setting when you see this display:
Settings are defined:
To inherit settings from a higher level: Delete Settings for this feature at this mode.
You can also Manage Settings.
Settings for this feature are also defined at:
Cluster: xxx
Or this display:
Delete settings from:
Cluster: xxx
Machine: yyyy.domain.com
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1242
Centralized Management Using Clusters
Copy vs Move
Copy vs Move
When to copy: when you want the cluster to have a setting, and a group or machine to also have no settings
or to have different settings.
When to move: when you want the cluster to have no setting at all, and for the group or machine to have the
settings.
Good CM Design Practices
When you LIST your CM machines, you want to see something like this:
cluster = CompanyName
Group Main_Group:
Machine lab1.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Machine lab2.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Group Paris:
Machine lab3.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Machine lab4.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Group Rome:
Machine lab5.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Machine lab6.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Be careful not to lose track of the level at which you are making changes. For example, if you have changed
the name of your Main_Group (using RENAMEGROUP) to London, it will look like this:
cluster = CompanyName
Group London:
Machine lab1.cable.nu (Serial #: 000F1FF7B3F0-CF2SX51)
...
However, this configuration tends to confuse many administrators, because they begin making changes to the
London systems at the group level, and they stop using the Cluster level as the normal configuration level for
basic settings.
Tip: it is not a good practice to have a group with the same name as the cluster, e.g. cluster London, group
London. If you are using site names for group names, it is not good practice to have a cluster name that refers
to a location.
The correct method, as explained above, is to leave as many settings at the cluster level as possible. In most
cases you should leave your primary site or main collection of machines in the Main_Group, and use groups
for your additional sites. This is true even if you consider that both sites are “equal.” Remember, CM has no
primary/secondary servers — all clustered machines are peers.
Tip: if you will be using extra groups you can easily prepare the groups before those extra machines are joined
to the cluster.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1243
Centralized Management Using Clusters
Best Practices for Accessing Spam or Policy Quarantines in Cluster Setup
Best Practices for Accessing Spam or Policy Quarantines in Cluster Setup
Accessing spam or policy quarantines of other appliances in a cluster from the logged-in email gateway may
cause excessive CPU usage on the logged-in email gateway. To avoid this scenario, you can access the spam
or policy quarantines by logging into the required email gateways.
Procedures: Configuring an Example Cluster
To configure this example cluster, log out of all GUIs on all machines before running clusterconfig . Run
clusterconfig on any one of the primary site machines. You will then join to this cluster only the other local
and remote machines that need the maximum possible shared settings (allowing for the machine only-settings
like IP address). The clusterconfig command cannot be used to join a remote machine to the cluster — you
must use the CLI on the remote machine and run clusterconfig (“join an existing cluster”).
In our example above we log in to lab1, run clusterconfig and create a cluster called CompanyName. We have
only one machine with identical requirements, so we log in to lab2, and saveconfig the existing configuration
(it will be drastically altered when it inherits most of lab1 settings.) On lab2 we can then use clusterconfig to
join an existing cluster. Repeat if you have additional machines at this site needing similar policies and settings.
Run CONNSTATUS to confirm that DNS resolves correctly. As machines are joined to the cluster, the new
machines inherit almost all of their settings from lab1 and their older settings are lost. If they are production
machines you will need to anticipate if mail will still be processed using the new configuration instead of their
previous configuration. If you remove them from the cluster, they will not revert to their old, private configs.
Next, we count the number of exceptional machines. If there is only one, it should receive a few extra machine
level settings and you will not need to create an extra group for it. Join it to the cluster and begin copying
settings down to the machine level. If this machine is an existing production machine you must back up the
configuration and consider the changes to mail processing as above.
If there are two or more, as in our example, decide if those two will share any settings with each other that
are not shared with the cluster. In that case, you will be creating one or more groups for them. Otherwise, you
will make machine level settings for each, and do not need to have extra groups.
In our case we want to run clusterconfig from the CLI on any of the machines already in the cluster, and select
ADDGROUP. We will do this twice, once for Paris and once for Rome.
Now you can begin using the GUI and CLI to build configuration settings for the cluster and for ALL the
groups, even if the groups have no machines in them yet. You will only be able to create machine specific
settings for machines after they have joined the cluster.
The best way to create your override or exceptional settings is to copy the settings from the higher (e.g. cluster)
level down to a lower (e.g. group) level.
For example, after creating the cluster our dnsconfig settings initially looked like this:
Configured at mode:
Cluster: Yes
Group Main_Group: No
Group Paris: No
Group Rome: No
Machine lab2.cable.nu: No
If we "Copy to Group" the DNS settings, it will look like this:
Configured at mode:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1244
Centralized Management Using Clusters
Summary of GUI Options for Using CM Settings Other Than the Cluster Default
Cluster: Yes
Group Main_Group: No
Group Paris: Yes
Group Rome: No
Machine lab2.cable.nu: No
Now you can edit the Paris group-level DNS settings, and other machines in the Paris group will inherit them.
Non-Paris machines will inherit the cluster settings, unless they have machine-specific settings. Besides DNS
settings, it is common to create group level settings for SMTPROUTES.
Tip When using the CLI CLUSTERSET function in various menus, you can use a special option to copy settings
to All Groups, which is not available through the GUI.
Complete listeners will be automatically inherited from the group or cluster, and you normally only create
these on the first system in the cluster. This reduces administration considerably. However, for this to work
you must name the Interfaces identically throughout your group or cluster .
Once the settings are defined correctly at the group level, you can join machines to the cluster and make them
part of this group. This requires two steps:
First, to join our remaining 4 systems to the cluster, we run clusterconfig on each. The larger and more complex
the cluster, the longer it takes to join, and this can take several minutes. You can monitor the joining progress
with the LIST and CONNSTATUS sub-commands. After the joins are complete you can use SETGROUP to
move the machines from the Main_Group into Paris and Rome. There is no way to avoid the fact that initially,
all machines added to the cluster inherit the Main_Group settings, not the Paris and Rome settings. This could
affect mail flow traffic if the new systems are already in production.
Tip Do not make your lab machines part of the same cluster as your production machines. Use a new cluster name
for lab systems. This provides an added layer of protection against unexpected changes (someone changing
a lab system and accidently losing production mail, for example).
Summary of GUI Options for Using CM Settings Other Than the Cluster Default
Override settings, and start with default settings. For example, the default settings for the SMTPROUTES
configuration is a blank table, which you can then build from scratch.
Override settings, but start with a copy of the settings currently inherited from Cluster xxx, or group yyy. For
example, you may want to a new copy of the SMTPROUTES table at the group level which is initially identical
to the cluster table. All email gateways that are contained in that same group (SETGROUP) will get this table.
Machines not in the group will still use the cluster level settings. Changing the SMTPROUTES on this
independent copy of the table will not affect other groups, machines inheriting the cluster settings, or machines
where the setting is defined at the individual machine level. This is the most common selection.
Manage settings, a sub-menu of Centralized Management Options. From this menu you can copy as above,
but you can also move or delete settings. If you move the SMTPROUTES to a group or machine level, then
the routes table will be blank at the cluster level but will exist at the more specific level.
Manage settings. Continuing our SMTPROUTES example, using the delete option will also result in a blank
SMTPROUTES table for the cluster. This is fine if you previously configured definitions for SMTPROUTES
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1245
Centralized Management Using Clusters
Setup and Configuration Questions
at the group level or machine levels. It is not a best practice to delete the cluster level settings and rely only
on group or machine settings. The cluster-wide settings are useful as defaults on newly added machines, and
keeping them reduces the number or group or site settings you have to maintain by one.
Setup and Configuration Questions
Q. I have a previously configured standalone machine and I join an existing cluster. What happens to my
settings?
A. When a machine joins a cluster, all of that machine's clusterable settings will be inherited from the cluster
level. Upon joining a cluster, all locally configured non-network settings will be lost, overwritten with the
settings of the cluster and any associated groups. (This includes the user/passphrase table; passphrases and
users are shared within a cluster).
Q. I have a clustered machine and I remove it (permanently) from the cluster. What happens to my settings?
A. When a machine is permanently removed from a cluster, its configuration hierarchy is “flattened” such
that the machine will continue to work the same as it did when it was part of the cluster. All settings that the
machine has been inheriting will be applied to the machine in the standalone setting.
For example, if there is only a cluster-mode Global Unsubscribe table, that Global Unsubscribe table data
will be copied to the machine's local configuration when the machine is removed from the cluster.
General Questions
Q. Are log files aggregated within centrally managed machines?
A. No. Log files are still retained for each individual machines. Cisco Secure Manager Email and Web Gateway
can be used to aggregate mail logs from multiple machines for the purposes of tracking and reporting.
Q. How does User Access work?
A. The email gateway share one database for the entire cluster. In particular, there is only admin account (and
passphrase) for the entire cluster.
Q. How should I cluster a data center?
A. Ideally, a data center would be a “group” within a cluster, not its own cluster. However, if the data centers
do not share much between themselves, you may have better results with separate clusters for each data center.
Q. What happens if systems are offline and they reconnect?
A. Systems attempt to synchronize upon reconnecting to the cluster.
Network Questions
Q. Is the centralized management feature a “peer-to-peer” architecture or a “primary/secondary” architecture?
A. Because every machine has all of the data for all of the machines (including all machine-specific settings
that it will never use), the centralized management feature can be considered a peer-to-peer architecture.
Q. How do I set up a box so it is not a peer? I want a “secondary” system.
A. Creating a true “secondary” machine is not possible with this architecture. However, you can disable the
HTTP (GUI) and SSH (CLI) access at the machine level. In this manner, a machine without GUI or CLI
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1246
Centralized Management Using Clusters
Planning and Configuration
access only be configured by clusterconfig commands (that is, it can never be a login host). This is similar to
having a secondary machine, but the configuration can be defeated by turning on login access again.
Q. Can I create multiple, segmented clusters?
A. Isolated “islands” of clusters are possible; in fact, there may be situations where creating them may be
beneficial, for example, for performance reasons.
Q. I would like to reconfigure the IP address and hostname on one of my clustered email gateways. If I do
this, will I lose my GUI/CLI session before being able to run the reboot command?
A. Follow these steps:
1. Add the new IP address
2. Move the listener onto the new address
3. Leave the cluster
4. Change the hostname
5. Make sure that oldmachinename does not appear in the clusterconfig connections list when viewed from
any machine
6. Make sure that all GUI sessions are logged out
7. Make sure that CCS is not enabled on any interface (check via interfaceconfig or Network > Listeners)
8. Add the machine back into the cluster
Q. Can the Destination Controls function be applied at the cluster level, or is it local machine level only?
A. It may be set at a cluster level; however, the limits are on a per-machine basis. So if you limit to 50
connections, that is the limit set for each machine in the cluster.
Planning and Configuration
Q. What can I do to maximize efficiency and minimize problems when setting up a cluster?
1. Initial Planning
• Try to configure as many things as possible at the cluster level.
• Manage by machines only for the exceptions.
• If you have multiple data centers, for example, use groups to share traits that are neither cluster-wide
nor necessarily machine-specific.
• Use the same name for Interfaces and Listeners on each of the email gateways.
2. Be aware of restricted commands.
3. Pay attention to interdependencies among settings.
For example, the listenerconfig command (even at the cluster level) depends on interfaces that only exist
at a machine level. If the interface does not exist at the machine level on all machines in the cluster, that
listener will be disabled.
Note that deleting an interface would also affect listenerconfig .
4. Pay attention to your settings!
Remember that previously-configured machines will lose their independent settings upon joining a cluster.
If you want to re-apply some of these previously configured settings at the machine level, be sure to take
note of all settings before joining the cluster.
Remember that a “disconnected” machine is still part of the cluster. When it is reconnected, any changes
you made while it was offline will be synchronized with the rest of the cluster.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1247
Centralized Management Using Clusters
Planning and Configuration
Remember that if you permanently remove a machine from a cluster, it will retain all of the settings it
had as part of that cluster. However, if you change your mind and re-join the cluster, the machine will
lose all standalone settings.
Use the saveconfig command to keep records of settings.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1248
CHAPTER 46
Testing and Troubleshooting
This chapter contains the following sections:
• Debugging Mail Flow Using Test Messages: Trace, on page 1249
• Using the Listener to Test the Email Gateway, on page 1255
• Troubleshooting the Network, on page 1259
• Troubleshooting the Listener, on page 1264
• Troubleshooting Email Delivery From the Appliance, on page 1265
• Troubleshooting Performance, on page 1267
• Web Interface Appearance and Rendering Issues , on page 1268
• Responding to Alerts , on page 1268
• Troubleshooting Hardware Issues , on page 1268
• Remotely Resetting Email Gateway Power , on page 1269
• Working with Technical Support, on page 1269
Debugging Mail Flow Using Test Messages: Trace
You can use System Administration > Trace page (the equivalent of the trace command in the CLI) to debug
the flow of messages through the system by emulating sending a test message. The Trace page (and trace
CLI command) emulates a message as being accepted by a listener and prints a summary of features that
would have been “triggered” or affected by the current configuration of the system (including uncommitted
changes ). The test message is not actually sent. The Trace page (and trace CLI command) can be a powerful
troubleshooting or debugging tool, especially if you have combined many of the advanced features available
on the email gateway.
Note Trace is not effective for testing file reputation scanning.
The Trace page (and trace CLI command) prompts you for the input parameters listed in the following
table.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1249
Testing and Troubleshooting
Debugging Mail Flow Using Test Messages: Trace
Table 158: Input for the Trace page
Value Description Example
Source IP address Type the IP address of the remote client to 203.45.98.109
mimic the source of the remote domain. This
2001:0db8:85a3::8a2e:0370:7334
can be an Internet Protocol version 4 (IPv4) or
version 6 (IPv6) address.
Note: The trace command prompts for an IP
address and a fully-qualified domain name. It
does not attempt to reverse the IP address to see
if it matches the fully-qualified domain name.
The trace command does not allow the
fully-qualified domain name field to be blank,
so it is impossible to test a scenario where the
DNS does not reverse match properly.
Fully Qualified Type the fully-qualified remote domain name smtp.example.com
Domain Name of the to mimic. If left null, a reverse DNS lookup will
Source IP be performed on the source IP address.
Listener to Trace Choose from the list of listeners configured on InboundMail
Behavior on the system to emulate sending the test message
to.
Network Owner Type the unique identification number of the 34
Organization ID network owner, or allow the system to Lookup
network owner ID associated with source IP
address. You can view this information if you
added network owners to sender groups via the
GUI.
IP Reputation Score Type the IP Reputation score you want to -7.5
provide for the spoofed domain, or allow the
system to look up the IP Reputation score
associated with the source IP address. This can
be helpful when testing policies that use IP
Reputation scores. Note that manually entered
IP Reputation scores are not passed to the
Context Adaptive Scanning Engine (CASE).
See Editing IP Reputation Filtering Score
Thresholds for a Listener , on page 96 for more
information.
Envelope Sender Type the Envelope Sender of the test message. [email protected]
Envelope Recipients Type a list of recipients for the test message. joe
Separate multiple entries with commas.
[email protected]
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1250
Testing and Troubleshooting
Debugging Mail Flow Using Test Messages: Trace
Value Description Example
Message Body Type the message body for the test message, To: [email protected]
including headers. Type a period on a separate
From: ralph
line to end entering the message body. Note that
“headers” are considered part of a message body Subject: Test
(separated by a blank line), and omitting
this is a test message
headers, or including poorly formatted ones can
cause unexpected trace results. .
After you have entered the values, click Start Trace. A summary of all features configured on the system
affecting the message is printed.
You can upload message bodies from your local file system. (In the CLI, you can test with message bodies
you have uploaded to the /configuration directory. See FTP, SSH, and SCP Access, on page 1297 for
more information on placing files for import onto the email gateway.)
After the summary is printed, you are prompted to view the resulting message and re-run the test message
again. If you enter another test message, the Trace page and the trace command uses any previous values from
the above table you entered.
Note The sections of configuration tested by the trace command listed in the following table are performed in order
. This can be extremely helpful in understanding how the configuration of one feature affects another. For
example, a recipient address transformed by the domain map feature will affect the address as it is evaluated
by the RAT. A recipient that is affected by the RAT will affect the address as it is evaluated by alias table,
and so on.
Table 159: Viewing Output When Performing a Trace
trace Command Section Output
Host Access Table (HAT) and Mail The Host Access Table settings for the listener you specified are
Flow Policy Processing processed. The system reports which entry in the HAT matched from
the remote IP address and remote domain name you entered. You can
see the default mail flow policies and sender groups and which one
matched the given entries.
If the email gateway was configured to reject the connection (either
through a REJECT or TCPREFUSE access rule), the trace command
exits at the point in the processing.
For more information on setting HAT parameters, see Understanding
Predefined Sender Groups and Mail Flow Policies, on page 110.
Envelope Sender Address Processing
These sections summarize how the email gateway configuration affects the Envelope Sender you supply.
(That is, how the MAIL FROM command would be interpreted by the configuration of the email gateway.)
The trace command prints “Processing MAIL FROM:” before this section.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1251
Testing and Troubleshooting
Debugging Mail Flow Using Test Messages: Trace
trace Command Section Output
Default Domain If you specified that a listener to change the default sender domain of
messages it receives, any change to the Envelope Sender is printed
in this section.
For more information, see Configuring the Gateway to Receive Email,
on page 77 .
Masquerading If you specified that the Envelope Sender of a message should be
transformed, the change is noted here. You enable masquerading for
the Envelope Sender on private listeners using the
listenerconfig -> edit -> masquerade -> config
subcommands.
For more information, see Configuring Routing and Delivery Features,
on page 697.
Envelope Recipient Processing
These sections summarize how the email gateway affects the Envelope Recipients you supply. (That is, how
the RCPT TO command would be interpreted by the configuration of the email gateway.) The trace command
prints “ Processing Recipient List: ” before this section.
Default Domain If you specified that a listener to change the default sender domain of
messages it receives, any changes to the Envelope Recipients are
printed in this section.
For more information, see Configuring the Gateway to Receive Email,
on page 77.
Domain Map Translation The domain map feature transforms the recipient address to an
alternate address. If you specified any domain map changes and a
recipient address you specified matches, the transformation is printed
in this section.
For more information, see Configuring Routing and Delivery Features,
on page 697.
Recipient Access Table (RAT) Each Envelope Recipient that matches an entry in the RAT is printed
in this section, in addition to the policy and parameters. (For example,
if a recipient was specified to bypass limits in the listener’s RAT.)
For more information on specifying recipients you accept, see
Configuring the Gateway to Receive Email, on page 77.
Alias Table Each Envelope Recipient that matches an entry in the alias tables
configured on the email gateway (and the subsequent transformation
to one or more recipient addresses) is printed in this section.
For more information, see Configuring Routing and Delivery Features,
on page 697.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1252
Testing and Troubleshooting
Debugging Mail Flow Using Test Messages: Trace
trace Command Section Output
Pre-Queue Message Operations
These sections summarize how the email gateway affects each message after the message contents have
been received, but before the messages are enqueued on the work queue. This processing occurs before the
final 250 ok command is returned to the remote MTA.
The trace command prints “Message Processing : ” before this section.
Virtual Gateways The altsrchost command assigns messages to a specific interface,
based on a match of the Envelope Sender’s full address, domain, or
name, or IP address. If an Envelope Sender matches entries from the
altsrchost command, that information is printed in this section.
Note that the virtual gateway address assigned at this point may be
overridden by message filter processing below.
For more information, see Configuring Routing and Delivery Features,
on page 697.
Bounce Profiles Bounce profiles are applied at three different points in the processing.
This is the first occurrence. If a listener has a bounce profile assigned
to it, it is assigned at this point in the process. That information is
printed in this section.
For more information, see Configuring Routing and Delivery Features,
on page 697.
Work Queue Operations
The following group of functions are performed on messages in the work queue. This occurs after the message
has been accepted from the client, but before the message is enqueued for delivery on a destination queue.
“Messages in Work Queue” is reported by the status and status detail commands.
Masquerading If you specified that the To:, From:, and CC: headers of messages
should be masked (either from a static table entered from a listener
or via an LDAP query), the change is noted here. You enable
masquerading for the message headers on private listeners using the
listenerconfig -> edit -> masquerade -> config
subcommands.
For more information, see Configuring Routing and Delivery Features,
on page 697.
LDAP Routing If LDAP queries have been enabled on a listener, the results of LDAP
acceptance, re-routing, masquerading, and group queries are printed
in this section.
For more information, see LDAP Queries, on page 775.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1253
Testing and Troubleshooting
Debugging Mail Flow Using Test Messages: Trace
trace Command Section Output
Message Filters Processing All messages filters that are enabled on the system are evaluated by
the test message at this point. For each filter, the rule is evaluated,
and if the end result is “true,” each of the actions in that filter are then
performed in sequence. A filter may contain other filters as an action,
and the nesting of filters is unlimited. If a rule evaluates to “false”
and a list of actions is associated with an else clause, those actions
are evaluated instead. The results of the message filters, processed in
order, are printed in this section.
See Using Message Filters to Enforce Email Policies, on page 139.
Mail Policy Processing
The mail policy processing section displays the Anti-Spam, Anti-Virus, Outbreak Filters feature, and
disclaimer stamping for all recipients you supplied. If multiple recipients match multiple policies in Email
Security Manager, the following sections will be repeated for each matching policy. The string: “Message
Going to” will define which recipients matched which policies.
Anti-Spam This section notes messages that are not flagged to be processed by
anti-spam scanning. If messages are to be processed by anti-spam
scanning for the listener, the message is processed and the verdict
returned is printed. If the email gateway is configured to bounce or
drop the messages based on the verdict, that information is printed
and the trace command processing stops.
Note: This step is skipped if anti-spam scanning is unavailable on the
system. If anti-spam scanning is available but has not been enabled
with a feature key, that information is also printed in this section.
See Managing Spam and Graymail, on page 383.
Anti-Virus This section notes messages that are not flagged to be processed by
anti-virus scanning. If messages are to be processed by anti-virus
scanning for the listener, the message is processed and the verdict
returned is printed. If the email gateway is configured to “clean”
infected messages, that information is noted. If configured to bounce
or drop the messages based on the verdict, that information is printed
and the trace command processing stops.
Note: This step is skipped if anti-virus scanning is unavailable on the
system. If anti-virus scanning is available but has not been enabled
with a feature key, that information is also printed in this section.
See the Anti-Virus, on page 365.
Content Filters Processing All content filters that are enabled on the system are evaluated by the
test message at this point. For each filter, the rule is evaluated, and if
the end result is “true,” each of the actions in that filter are then
performed in sequence. A filter may contain other filters as an action,
and the nesting of filters is unlimited. The results of the content filters,
processed in order, are printed in this section.
See Content Filters, on page 281.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1254
Testing and Troubleshooting
Using the Listener to Test the Email Gateway
trace Command Section Output
Outbreak Filters Processing This section notes that messages that contain attachments are to bypass
the Outbreak Filters feature. If messages are to be processed by
Outbreak Filters for the recipient, the message is processed and the
evaluation. If the email gateway is configured to quarantine, bounce,
or drop the messages based on the verdict, that information is printed
and the processing stops.
See Outbreak Filters, on page 425.
Footer Stamping This section notes whether a footer text resource was appended to the
message. The name of the text resource is displayed. See Message
Disclaimer Stamping, on page 644 in Text Resources, on page 643.
Delivery Operations
The following sections note operations that occur when a message is delivered. The trace command prints
“ Message Enqueued for Delivery ” before this section.
Global Unsubscribe per Domain and If any recipients you specified as input for the trace command match
per User recipients, recipient domains, or IP addresses listed in the in the Global
Unsubscribe feature, any unsubscribed recipient addresses are printed
in this section.
See Configuring Routing and Delivery Features, on page 697.
Sender Domain Reputation Displays the processing results of messages that are blocked by the
reputation verdict of the sender domain.
The following is a sample example of the processing results:
• Reputation: Neutral
• Domain Age: 33 years 9 months 6 days
• Category: N/A
• Action: Message Dropped
Final Result
When all processing has been printed, you are prompted with the final result. In the CLI, Answer y to the
question, “Would you like to see the resulting message?” to view the resulting message.
Using the Listener to Test the Email Gateway
“Sinkhole” listeners allow you to test your message generation systems and to also get a rough measure of
receiving performance. Two types of sinkhole listeners are queueing and non-queueing .
• The queueing listener saves the message to the queue, but then immediately deletes it. Use a queuing
listener when you are interested in measuring the performance of the entire injection portion of your
message generation system.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1255
Testing and Troubleshooting
Example
• The non-queueing listener accepts a message, and then immediately deletes it without saving it. Use the
non-queueing listener when you want to troubleshoot the connection from your message generation
system to the email gateway .
For example, in the following figure, you could create a sinkhole listener “C” to mirror the private listener
labeled “B.” A non-queueing version tests the performance path of the system from the groupware client to
the groupware server to the email gateway. A queueing version tests that same path and the email gateway's
ability to enqueue messages and prepare them for delivery via SMTP.
Figure 87: Sinkhole Listener for an Enterprise Gateway
In the following example, the listenerconfig command is used to create a sinkhole queueing listener named
Sinkhole_1 on the Management interface. This Host Access Table (HAT) for the listener is then edited to
accept connections from the following hosts:
• yoursystem.example.com
• 10.1.2.29
• badmail.tst
• .tst
Note The final entry, .tst , configures the listener so that any host in the .tst domain can send email to the listener
named Sinkhole_1 .
Example
mail3.example.com> listenerconfig
Currently configured listeners:
1. InboundMail (on PublicNet, 192.168.2.1) SMTP Port 25 Public
2. OutboundMail (on PrivateNet, 192.168.1.1) SMTP Port 25 Private
Choose the operation you want to perform:
- NEW - Create a new listener.
- EDIT - Modify a listener.
- DELETE - Remove a listener.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1256
Testing and Troubleshooting
Example
- SETUP - Change global settings.
[]> new
Please select the type of listener you want to create.
1. Private
2. Public
3. Sinkhole
[2]> 3
Do you want messages to be queued onto disk? [N]> y
Please create a name for this listener (Ex: "OutboundMail"):
[]> Sinkhole_1
Please choose an IP interface for this Listener.
1. Management (192.168.42.42/24: mail3.example.com)
2. PrivateNet (192.168.1.1/24: mail3.example.com)
3. PublicNet (192.168.2.1/24: mail3.example.com)
[1]> 1
Choose a protocol.
1. SMTP
2. QMQP
[1]> 1
Please enter the IP port for this listener.
[25]> 25
Please specify the systems allowed to relay email through the IronPort C60.
Hostnames such as "example.com" are allowed.
Partial hostnames such as ".example.com" are allowed.
IP addresses, IP address ranges, and partial IP addressed are allowed.
Separate multiple entries with commas.
[]> yoursystem.example.com, 10.1.2.29, badmail.tst, .tst
Do you want to enable rate limiting per host? (Rate limiting defines
the maximum number of recipients per hour you are willing to receive from a remote
domain.) [N]> n
Default Policy Parameters
==========================
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1257
Testing and Troubleshooting
Example
Maximum Message Size: 100M
Maximum Number Of Connections From A Single IP: 600
Maximum Number Of Messages Per Connection: 10,000
Maximum Number Of Recipients Per Message: 100,000
Maximum Number Of Recipients Per Hour: Disabled
Use SenderBase for Flow Control: No
Spam Detection Enabled: No
Virus Detection Enabled: Yes
Allow TLS Connections: No
Allow SMTP Authentication: No
Require TLS To Offer SMTP authentication: No
Would you like to change the default host access policy? [N]> n
Listener Sinkhole_1 created.
Defaults have been set for a Sinkhole Queuing listener.
Use the listenerconfig->EDIT command to customize the listener.
Currently configured listeners:
1. Sinkhole_1 (on Management, 192.168.42.42) SMTP Port 25 Sinkhole Queuing
2. InboundMail (on PublicNet, 192.1681.1) SMTP Port 25 Public
3. OutboundMail (on PrivateNet, 192.168.1.1) SMTP Port 25 Private
Choose the operation you want to perform:
- NEW - Create a new listener.
- EDIT - Modify a listener.
- DELETE - Remove a listener.
- SETUP - Change global settings.
[]>
Note Remember to issue the commit command for these changes to take effect.
After you have configured a sinkhole queuing listener and modified the HAT to accept connections from your
injection system, use your injection system to begin sending email to the email gateway. Use the status , status
detail , and rate commands to monitor system performance. You can also monitor the system via the Graphical
User Interface (GUI). For more information, see:
• Monitoring Using the CLI, on page 1097
• Other Tasks in the GUI, on page 1125
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1258
Testing and Troubleshooting
Troubleshooting the Network
Troubleshooting the Network
If you suspect that the email gateway has network connectivity issues, first confirm that the email gateway is
working properly.
Testing the Network Connectivity of the Email Gateway
Procedure
Step 1 Connect to the system and log in as the administrator. After successfully logging in, the following messages
are displayed:
Last login: day month date hh:mm:ss from IP address
Copyright (c) 2001-2003, IronPort Systems, Inc.
AsyncOS x.x for Cisco
Welcome to the Cisco Messaging Gateway Appliance(tm)
Step 2 Use the status or status detail commands.
mail3.example.com> status
or
mail3.example.com> status detail
The status command returns a subset of the monitored information about email operations. The statistics
returned are grouped into two categories: counters and gauges. For complete monitoring information about
email operations including rates, use the status detail command. Counters provide a running total of various
events in the system. For each counter, you can view the total number of events that have occurred since the
counter was reset, since the last system reboot, and over the system's lifetime. (For more information, see
Monitoring Using the CLI, on page 1097.)
Step 3 Use the mailconfig command to send mail to a known working address.
The mailconfig command generates a human-readable file including all configuration settings available to
the email gateway. Attempt to send the file from the email gateway to a known working email address to
confirm that the email gateway is able to send email over the network.
mail3.example.com> mailconfig
Please enter the email address to which you want to send the
configuration file.
Separate multiple addresses with commas.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1259
Testing and Troubleshooting
Troubleshooting
Do you want to include passphrases? Please be aware that a configuration without
passphrases will fail when reloaded with loadconfig. [N]> y
The configuration file has been sent to [email protected].
mail3.example.com>
Troubleshooting
After you have confirmed that the email gateway is active on the network, use the following commands to
pinpoint any network problems.
• You can use the netstat command to display network connections (both incoming and outgoing), routing
tables, and a number of network interface statistics, including the following information:
• List of active sockets
• State of network interfaces
• Contents of routing tables
• Size of the listen queues
• Packet traffic information
• You can use the diagnostic -> network -> flush command to flush all network related caches.
• You can use the diagnostic -> network -> arpshow command to show the system ARP cache.
• You can use the packetcapture command to intercept and display TCP/IP and other packets being
transmitted or received over a network to which the computer is attached.
To use packetcapture , set the network interface and the filter. The filter uses the same format the UNIX
tcpdump command. Use start to begin the packet capture and stop to end it. After stopping the capture,
you need to use SCP or FTP to download the files from the /pub/captures directory. For more information,
see Running a Packet Capture, on page 1273.
• Use the ping command to a known working host to confirm that the email gateway has an active
connection on the network and is able to reach specific segments of your network.
The ping command allows you to test connectivity to a network host from the email gateway.
mail3.example.com> ping
Which interface do you want to send the pings from?
1. Auto
2. Management (192.168.42.42/24: mail3.example.com)
3. PrivateNet (192.168.1.1/24: mail3.example.com)
4. PublicNet (192.168.2.1/24: mail3.example.com)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1260
Testing and Troubleshooting
Troubleshooting
[1]> 1
Please enter the host you wish to ping.
[]> anotherhost.example.com
Press Ctrl-C to stop.
PING anotherhost.example.com (x.x.x.x): 56 data bytes
64 bytes from 10.19.0.31: icmp_seq=9 ttl=64 time=0.133 ms
64 bytes from 10.19.0.31: icmp_seq=10 ttl=64 time=0.115 ms
^C
--- anotherhost.example.com ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.115/0.242/1.421/0.373 ms
Note You must use Control-C to end the ping command.
• Use the traceroute command to test connectivity to a network host from the email gateway and debug
routing issues with network hops.
mail3.example.com> traceroute
Which interface do you want to trace from?
1. Auto
2. Management (192.168.42.42/24: mail3.example.com)
3. PrivateNet (192.168.1.1/24: mail3.example.com)
4. PublicNet (192.168.2.1/24: mail3.example.com)
[1]> 1
Please enter the host to which you want to trace the route.
[]> 10.1.1.1
Press Ctrl-C to stop.
traceroute to 10.1.1.1 (10.1.1.1), 64 hops max, 44 byte packets
1 gateway (192.168.0.1) 0.202 ms 0.173 ms 0.161 ms
2 hostname (10.1.1.1) 0.298 ms 0.302 ms 0.291 ms
mail3.example.com>
• Use the diagnostic -> network -> smtpping command to test a remote SMTP server.
• Use the nslookup command to check the DNS functionality.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1261
Testing and Troubleshooting
Troubleshooting
The nslookup command can confirm that the email gateway is able to reach and resolve hostnames and
IP addresses from a working DNS (domain name service) server.
mail3.example.com> nslookup
Please enter the host or IP to resolve.
[]> example.com
Choose the query type:
1. A
2. CNAME
3. MX
4. NS
5. PTR
6. SOA
7. TXT
[1]>
A=192.0.34.166 TTL=2d
Table 160: Checking DNS Functionality: Query Types
A the host's Internet address
CNAME the canonical name for an alias
MX the mail exchanger
NS the name server for the named zone
PTR the hostname if the query is an Internet address, otherwise the pointer
to other information
SOA the domain's “start-of-authority” information
TXT the text information
• Use the tophosts command via the CLI or the GUI, and sort by Active Recipients.
The tophosts command returns a list of the top 20 recipient hosts in queue. This command can help you
determine if network connectivity problems are isolated to a single host or group of hosts to which you
are attempting to send email. (For more information, see “Determining the Make-up of the Mail Queue”.)
mail3.example.com> tophosts
Sort results by:
1. Active Recipients
2. Connections Out
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1262
Testing and Troubleshooting
Troubleshooting
3. Delivered Recipients
4. Soft Bounced Events
5. Hard Bounced Recipients
[1]> 1
Status as of: Mon Nov 18 22:22:23 2003
ActiveConn.Deliv.SoftHard
# Recipient HostRecipOutRecip.BouncedBounced
1 aol.com36510255218
2 hotmail.com29071982813
3 yahoo.com13461231119
4 excite.com9838494
5 msn.com8427633 29
^C
• “Drill-down” to use the hoststatus command on the top domains listed from the tophosts command
results.
The hoststatus command returns monitoring information about email operations relating to a specific
recipient host. DNS information stored in the AsyncOS cache and the last error returned from the recipient
host are also given. Data returned is cumulative since the last resetcounters command. (For more
information, see Monitoring the Status of a Mail Host, on page 1100.)
Using the hoststatus command on the top domains can isolate the performance issues with DNS
resolution to the either the email gateway or the internet. For example, if the hoststatus command for
the top active recipient host shows many pending outbound connections, then try to determine if that
particular host is down or unreachable, or if the email gateway cannot connect to all or the majority of
hosts.
• Check firewall permissions.
The email gateway may need all of the following ports to be opened in order to function properly: ports
20, 21, 22, 23, 25, 53, 80, 123, 443, and 628. (See Firewall Information, on page 1325.)
• Send email from the email gateway on your network to [email protected]
Send an email from within your network to [email protected] to perform basic DNS checks on
your system. And auto-responder email will respond with the results and details of the following four
tests:
DNS PTR Record - Does the IP address of the Envelope From match the PTR record for the domain?
DNS A Record - Does the PTR record for the domain match the IP address of the Envelope From?
HELO match - Does the domain listed in the SMTP HELO command match the DNS hostname in the Envelope
From?
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1263
Testing and Troubleshooting
Troubleshooting the Listener
Mail server accepting delayed bounce messages - Does the domain listed in the SMTP HELO command have
MX records that resolve IP addresses for that domain?
Troubleshooting the Listener
If you suspect problems with injecting email, use the following strategies:
• Confirm the IP address that you are injecting from, and then use the listenerconfig command to check
for allowed hosts.
Is the IP address allowed to connect to the listener you have created? Use the listenerconfig command
to examine the Host Access Table (HAT) for the listener. Use these commands to print the HAT for a
listener:
listenerconfig -> edit -> listener_number -> hostaccess -> print
The HAT can be configured to refuse connections by IP address, block of IP addresses, hostname, or
domains. For more information, see “Specifying Hosts that are Allowed to Connect”.
You can also use the limits subcommand to check the maximum number of connections allowed for a
listener:
listenerconfig -> edit -> listener_number -> limits
• On the machine that you are injecting from, use Telnet or FTP to manually connect to the email gateway.
For example:
injection_machine% telnet appliance_name
You can also use the telnet command within the email gateway itself to connect from the listener to
the actual email gateway:
mail3.example.com> telnet
Please select which interface you want to telnet from.
1. Auto
2. Management (192.168.42.42/24: mail3.example.com)
3. PrivateNet (192.168.1.1/24: mail3.example.com)
4. PublicNet (192.168.2.1/24: mail3.example.com)
[1]> 3
Enter the remote hostname or IP.
[]> 193.168.1.1
Enter the remote port.
[25]> 25
Trying 193.168.1.1...
Connected to 193.168.1.1.
Escape character is '^]'.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1264
Testing and Troubleshooting
Troubleshooting Email Delivery From the Appliance
If you cannot connect from one interface to another, you may have issues with the way in which the
email gateway's Management and Data1 and Data2 interfaces are connected to your network. See FTP,
SSH, and SCP Access, on page 1297 for more information. You can telnet to port 25 of the listener and
enter SMTP commands manually (if you are familiar with the protocol).
• Examine the IronPort text mail logs and injection debug logs to check for receiving errors.
Injection debug logs record the SMTP conversation between the email gateway and a specified host
connecting to the system. Injection debug logs are useful for troubleshooting communication problems
between the email gateway and a client initiating a connection from the Internet. The log records all
bytes transmitted between the two systems and classifies them as “Sent to” the connecting host or
“Received from” the connecting host.
For more information, see Using Text Mail Logs, on page 1152 and Using Injection Debug Logs, on page
1173.
Troubleshooting Email Delivery From the Appliance
If you suspect problems with delivering email from the email gateway, try the following strategies:
• Determine if the problem is domain-specific.
Use the tophosts command to get immediate information about the email queue and determine if a
particular recipient domain has delivery problems.
Are there problem domains returned when you sort by “Active Recipients?”
When you sort by Connections Out, does any one domain reach the maximum connections specified for
a listener? The default maximum number of connections for a listener is 600. The default maximum
system-wide number of connections if 10,000 (set by the deliveryconfig command). You can examine
the maximum number of connections for a listener using the command:
listenerconfig -> edit -> listener_number -> limits
Are the connections for a listener further limited by the destconfig command (either by system maximum
or by Virtual Gateway addresses)? Use this command to examine the destconfig connection limits:
destconfig -> list
• Use the hoststatus command.
“Drill-down” using the hoststatus command on the top domains listed from the results listed by the
tophosts command.
Is the host available and accepting connections?
Are there problems with one specific MX record mail server for the given host?
The hoststatus command reports the last “5XX” status code and description returned by the host if
there is a 5XX error (Permanent Negative Completion reply) for the specified host. If the last outgoing
TLS connection to the host failed, the hoststatus command displays the reason why it failed.
• Configure and/or examine the domain debug, bounce, and text mail logs to check if the recipient host is
available.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1265
Testing and Troubleshooting
Troubleshooting Email Delivery From the Appliance
Domain debug logs record the client and server communication during an SMTP conversation between
the email gateway and a specified recipient host. This log file type can be used to debug issues with
specific recipient hosts.
For more information, see Using Domain Debug Logs, on page 1172.
Bounce logs record all information pertaining to each bounced recipient.
For more information, see Using Bounce Logs, on page 1168.
Text mail logs contain details of email receiving, email delivery and bounces. These logs are a useful
source of information to understand delivery of specific messages and to analyze system performance.
For more information, see Using Text Mail Logs, on page 1152.
• Use the telnet command to connect from the email gateway to the problem domain:
mail3.example.com> telnet
Please select which interface you want to telnet from.
1. Auto
2. Management (192.168.42.42/24: mail3.example.com)
3. PrivateNet (192.168.1.1/24: mail3.example.com)
4. PublicNet (192.168.2.1/24: mail3.example.com)
[1]> 1
Enter the remote hostname or IP.
[]> problemdomain.net
Enter the remote port.
[25]> 25
• You can use the tlsverify command to establish an outbound TLS connection on demand and debug
any TLS connection issues concerning a destination domain. To create the connection, specify the domain
to verify against and the destination host. AsyncOS checks the TLS connection based on the Required
(Verify) TLS setting.
mail3.example.com> tlsverify
Enter the TLS domain to verify against:
[]> example.com
Enter the destination host to connect to. Append the port (example.com:26) if you are
not connecting on port 25:
[example.com]> mxe.example.com:25
Connecting to 1.1.1.1 on port 25.
Connected to 1.1.1.1 from interface 10.10.10.10.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1266
Testing and Troubleshooting
Troubleshooting Performance
Checking TLS connection.
TLS connection established: protocol TLSv1, cipher RC4-SHA.
Verifying peer certificate.
Verifying certificate common name mxe.example.com.
TLS certificate match mxe.example.com
TLS certificate verified.
TLS connection to 1.1.1.1 succeeded.
TLS successfully connected to mxe.example.com.
TLS verification completed.
Troubleshooting Performance
If you suspect that there are there are performance problems with the email gateway, utilize the following
strategies:
• Use the rate and hostrate commands to check the current system activity.
The rate command returns real-time monitoring information about email operations. For more information,
see Displaying Real-time Activity, on page 1103.
The hostrate command returns real-time monitoring information for a specific host.
• Use the status command to cross-check the historical rates to check for degradation.
• Use the status detail command to check the RAM utilization.
You can use the status detail command to quickly see the system’s RAM, CPU, and Disk I/O
utilization.
Note RAM utilization should always be less than 45%. If RAM utilization exceeds
45%, then, the email gateway will enter “resource conservation mode;” it initiates
a “back-off” algorithm to prevent over-subscription of resources and sends out
the following email alert:
This system (hostname: hostname) has entered a 'resource conservation' mode in order
to
prevent the rapid depletion of critical system resources.
RAM utilization for this system has exceeded the resource conservation threshold of
45%.
The allowed injection rate for this system will be gradually decreased as RAM
utilization approaches 60%.
This situation occurs only with an aggressive injection with poor deliverability facilities. If you encounter
RAM utilization exceeding 45%, check the number of messages in the queue and see if a particular
domain is down or unavailable for delivery (via the hoststatus or hostrate commands). Also check
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1267
Testing and Troubleshooting
Web Interface Appearance and Rendering Issues
the status of the system and ensure that delivery is not suspended. If after stopping the injection you
continue to experience a high RAM utilization, contact Cisco Customer Support.
• Is the problem specific to one domain?
Use the tophosts command to get immediate information about the email queue and determine if a
particular recipient domain has delivery problems.
Check the size of the queue. You can delete, bounce, suspend, or redirect messages in the email queue
to manage its size, or to deal with recipients to a specific, problematic domain. For more information,
see Managing the Email Queue, on page 1107. Use these commands:
• deleterecipients
• bouncerecipients
• redirectrecipients
• suspenddel / resumedel
• suspendlistener / resumelistener
Use the tophosts command to check the number of soft and hard bounces. Sort by “Soft Bounced Events”
(option 4 ) or “Hard Bounced Recipients” (option 5 ). If the performance for a particular domain is
problematic, use the commands above to manage the delivery to that domain.
Web Interface Appearance and Rendering Issues
See Overriding Internet Explorer Compatibility Mode, on page 1086.
Responding to Alerts
•
• Troubleshooting Alerts That Miscellaneous Disk Usage is Approaching the Quota , on page 1268
Troubleshooting Alerts That Miscellaneous Disk Usage is Approaching the
Quota
Problem
You receive an alert that Miscellaneous disk usage is approaching its quota.
Solution
You can either increase the quota or delete files. See Managing Disk Space for the Miscellaneous Quota , on
page 1024.
Troubleshooting Hardware Issues
Lights on the front and/or rear panels of your hardware email gateway indicate health and status of your email
gateway. For descriptions of these indicators, see the hardware guides , such as the Cisco x90s Series Content
Security Appliances Installation and Maintenance Guide, available from
http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-installation-guides-list.html.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1268
Testing and Troubleshooting
Remotely Resetting Email Gateway Power
Specifications for your email gateway, such as temperature ranges, are also available in these documents.
Remotely Resetting Email Gateway Power
If the email gateway requires a hard reset, you can reboot the email gateway chassis remotely using a third-party
Intelligent Platform Management Interface (IPMI) tool.
Restrictions
• Remote power cycling is available only on certain hardware.
For specifics, see Enabling Remote Power Cycling , on page 1038.
• If you want be able to use this feature, you must enable it in advance, before you need to use it.
For details, see Enabling Remote Power Cycling , on page 1038.
• Only the following IPMI commands are supported:
• status, on, off, cycle, reset, diag, soft
• Issuing unsupported commands will produce an “insufficient privileges” error.
Before You Begin
• Obtain and set up a utility that can manage devices using IPMI version 2.0.
• Understand how to use the supported IPMI commands. See the documentation for your IPMI tool.
Procedure
Step 1 Use IPMI to issue a supported power-cycling command to the IP address assigned to the Remote Power Cycle
port, which you configured earlier, along with the required credentials.
For example, from a UNIX-type machine with IPMI support, you might issue the command:
ipmitool -I lan -H 192.0.2.1 -U remoteresetuser -P password chassis power
reset
where 192.0.2.1 is the IP address assigned to the Remote Power Cycle port and remoteresetuser
and password are the credentials that you entered while enabling this feature.
Step 2 Wait at least eleven minutes for the email gateway to reboot.
Working with Technical Support
• Technical Support for Virtual Email Gateway, on page 1270
• Opening or Updating a Support Case From the Email Gateway , on page 1270
• Enabling Remote Access for Cisco Technical Support Personnel , on page 1271
• Running a Packet Capture, on page 1273
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1269
Testing and Troubleshooting
Technical Support for Virtual Email Gateway
Technical Support for Virtual Email Gateway
Requirements for getting technical support for your virtual email gateway are described in the Cisco Content
Security Virtual Appliance Installation Guide available from
http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-installation-guides-list.html
.
Opening or Updating a Support Case From the Email Gateway
Before You Begin
• If your issue is urgent, do not use this method. Instead, contact support using one of the other methods
listed in Cisco Customer Support, on page 18.
Use the following procedure only for issues such as a request for information or a problem for which
you have a workaround, but would like an alternate solution.
• Consider other options for getting help:
• Knowledge Base, on page 17
• Cisco Support Community, on page 17
• To access Cisco technical support directly from the email gateway, your Cisco.com user ID must be
associated with your service agreement contract for this email gateway. To view a list of service contracts
that are currently associated with your Cisco.com profile, visit the Cisco.com Profile Manager at
https://rpfa.cloudapps.cisco.com/rpfa/profile/profile_management.do. If you do not have a Cisco.com
user ID, register to get one. See Registering for a Cisco Account , on page 18.
Be sure to save your Cisco.com user ID and support contract ID in a safe location.
• When you open a support case using this procedure, the email gateway configuration file is sent to Cisco
Customer Support. If you do not want to send the email gateway configuration, you can contact Customer
Support using a different method.
• In cluster configurations, support requests and their saved values are machine-specific.
• The email gateway must be connected to the internet and able to send email.
• If you are sending information about an existing case, make sure you have the case number.
Procedure
Step 1 Sign in to the email gateway.
Step 2 Choose Help and Support > Contact Technical Support.
Step 3 Complete the form.
Step 4 Click Send.
Note CCO User IDs and the last-entered Contract ID are saved on the email gateway for future use.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1270
Testing and Troubleshooting
Enabling Remote Access for Cisco Technical Support Personnel
Enabling Remote Access for Cisco Technical Support Personnel
Only Cisco Customer Assistance can access your email gateway using these methods.
• Enabling Remote Access to Email Gateways With an Internet Connection , on page 1271
• Enabling Remote Access to Email Gateways Without a Direct Internet Connection , on page 1271
• Disabling Remote Access , on page 1272
• Disabling a Tech Support Tunnel , on page 1272
• Checking the Status of the Support Connection , on page 1273
Enabling Remote Access to Email Gateways With an Internet Connection
Support accesses the email gateway through an SSH tunnel that this procedure creates between the email
gateway and the upgrades.ironport.com server.
Before You Begin
Identify a port that can be reached from the internet. The default is port 25, which will work in most
environments because the system also requires general access over that port in order to send email messages.
Connections over this port are allowed in most firewall configurations.
Procedure
Step 1 Log in to the email gateway.
Step 2 From the top right side of the GUI window, choose Help and Support > Remote Access.
Step 3 Click Enable.
Step 4 Enter information:
Option Description
Seed String The seed string is used to generate a secure shared secret to be used by Cisco
Customer Support to access this email gateway.
Secure Tunnel Select the check box to use a secure tunnel for the remote access connection.
Enter a port for the connection.
The default is port 25 , which will work in most environments.
Step 5 Click Submit.
What to do next
When remote access for support personnel is no longer required, see Disabling a Tech Support Tunnel , on
page 1272.
Enabling Remote Access to Email Gateways Without a Direct Internet Connection
For appliances without a direct internet connection, access is made through a second email gateway that is
connected to the internet.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1271
Testing and Troubleshooting
Disabling a Tech Support Tunnel
Before You Begin
• The email gateway must be able to connect on port 22 to a second email gateway that is connected to
the internet.
• On the email gateway with the internet connection, follow the procedure in Enabling Remote Access to
Email Gateways With an Internet Connection , on page 1271 to create a support tunnel to that email gateway.
Procedure
Step 1 From the command-line interface of the email gateway requiring support, enter the techsupport command.
Step 2 Enter sshaccess.
Step 3 Follow the prompts.
What to do next
When remote access for support personnel is no longer required, see the following:
• Disabling Remote Access , on page 1272
• Disabling a Tech Support Tunnel , on page 1272
Disabling a Tech Support Tunnel
An enabled techsupport tunnel remains connected to upgrades.ironport.com for 7 days. After that time,
established connections will not be disconnected but will be unable to re-attach to the tunnel once disconnected.
To disable the tunnel manually:
Procedure
Step 1 Log in to the email gateway.
Step 2 From the top right side of the GUI window, choose Help and Support > Remote Access.
Step 3 Click Disable.
Disabling Remote Access
A remote access account that you create using the techsupport command remains active until you deactivate
it.
Procedure
Step 1 From the command-line interface, enter the techsupport command.
Step 2 Enter sshaccess .
Step 3 Enter disable .
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1272
Testing and Troubleshooting
Checking the Status of the Support Connection
Checking the Status of the Support Connection
Procedure
Step 1 From the command-line interface, enter the techsupport command.
Step 2 Enter status .
Running a Packet Capture
Packet Capture allows support personnel to see the TCP/IP data and other packets going into and out of the
email gateway. This allows Support to debug the network setup and to discover what network traffic is reaching
the email gateway or leaving the email gateway.
Procedure
Step 1 Choose Help and Support > Packet Capture.
Step 2 Specify packet capture settings:
a) In the Packet Capture Settings section, click Edit Settings.
b) (Optional) Enter duration, limits, and filters for the packet capture.
Your Support representative may give you guidance on these settings.
If you enter a capture duration without specifying a unit of time, AsyncOS uses seconds by default.
In the Filters section:
• Custom filters can use any syntax supported by the UNIX tcpdump command, such as host 10.10.10.10
&& port 80 .
• The client IP is the IP address of the machine connecting to the email gateway, such as a mail client
sending messages through the email gateway.
• The server IP is the IP address of the machine to which the email gateway is connecting, such as an
Exchange server to which the email gateway is delivering messages.
• You can use the client and server IP addresses to track traffic between a specific client and a specific
server, with the email gateway in the middle.
c) Click Submit.
Step 3 Click Start Capture.
• Only one capture may be running at a time.
• When a packet capture is running, the Packet Capture page shows the status of the capture in progress
by showing the current statistics, such as file size and time elapsed.
• The GUI only displays packet captures started in the GUI, not from the CLI. Similarly, the CLI only
displays the status of a current packet capture run started in the CLI.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1273
Testing and Troubleshooting
Running a Packet Capture
• The packet capture file is split into ten parts. If the file reaches the maximum size limit before the packet
capture ends, the oldest part of the file is deleted (the data is discarded) and a new part starts with the
current packet capture data. Only 1/10 of the packet capture file is discarded at a time.
• A running capture started in the GUI is preserved between sessions. (A running capture started in the
CLI stops when the session ends.)
Step 4 Allow the capture to run for the specified duration, or, if you have let the capture run indefinitely, manually
stop the capture by clicking Stop Capture.
Step 5 Access the packet capture file:
• Click the file in the Manage Packet Capture Files list and click Download File.
• Use FTP or SCP to access the file in the captures subdirectory on the email gateway.
What to do next
Make the file available to Support:
• If you allow remote access to your email gateway, technicians can access the packet capture files using
FTP or SCP. See Enabling Remote Access for Cisco Technical Support Personnel , on page 1271.
• Email the file to Support.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1274
CHAPTER 47
Optimizing the Email Gateway for Outbound Mail
Delivery Using D-Mode
This chapter contains the following sections:
• Feature Summary: D-Mode for Optimized Outbound Delivery , on page 1275
• Setting Up the Email Gateway for Optimized Outbound Mail Delivery , on page 1277
• Sending Bulk Mail Using IronPort Mail Merge (IPMM), on page 1278
Feature Summary: D-Mode for Optimized Outbound Delivery
D-Mode is a feature key-enabled feature that optimizes certain email gateways for outbound email delivery.
Features specific to inbound mail handling are disabled in D-Mode.
• Features Unique to D-Mode-Enabled Email Gateways , on page 1275
• Standard Features Disabled in D-Mode-Enabled Email Gateways , on page 1276
• Standard Features Applicable to D-Mode-Enabled Email Gateways , on page 1276
Features Unique to D-Mode-Enabled Email Gateways
• 256 Virtual Gateway Addresses - The Cisco Virtual Gateway technology allows you to configure enterprise
mail gateways for all domains you host — with distinct IP addresses, hostname and domains — and
create separate corporate email policy enforcement and anti-spam strategies for those domains, while
hosted within the same physical email gateway. See information about “Customizing Listeners” in
Configuring the Gateway to Receive Email, on page 77
• IronPort Mail Merge (IPMM) - IronPort Mail Merge (IPMM) removes the burden of generating individual
personalized messages from customer systems. By removing the need to generate thousands of individual
messages and transmit them between message generating systems and the email gateway, users benefit
from the decreased load on their systems and increased throughput of email delivery. For more information,
see Sending Bulk Mail Using IronPort Mail Merge (IPMM), on page 1278.
• Resource-conserving bounce setting - You can configure D-Mode-enabled email gateways to detect
potential blocked destinations and bounce all messages bound for that destination. For more information,
see Configuring Resource-Conserving Bounce Settings, on page 1277.
• Enhanced performance for outbound delivery
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1275
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Standard Features Disabled in D-Mode-Enabled Email Gateways
Standard Features Disabled in D-Mode-Enabled Email Gateways
• IronPort anti-spam scanning and on or off box spam quarantining — Because anti-spam scanning pertains
mostly to incoming mail, the IronPort Anti-Spam scanning engine is disabled. The Anti-Spam chapter
is, therefore, not applicable.
• Outbreak Filters — Because the Outbreak Filters feature is used to quarantine incoming mail, this feature
is disabled on D-Mode-enabled email gateways. Information in the Outbreak Filters chapter is, therefore,
not applicable.
• Service Logs - The Service Logs feature is disabled on D-mode enabled email gateways.
• Reporting — Reporting is limited. Some reports are not available, and the reporting that does occur is
set to run at a very limited level for performance reasons.
Note The totals shown in the Email Security Monitor Overview report for D-Mode-enabled email gateways may
erroneously include spam and suspect spam counts, even though these features are disabled on D-Mode-enabled
email gateways.
• Data Loss Prevention — DLP scanning for outgoing messages is disabled on D-Mode-enabled email
gateways.
Standard Features Applicable to D-Mode-Enabled Email Gateways
Table 161: AsyncOS Features Included in D-Mode Enabled Email Gateways
Feature More Information
Anti-virus scanning See Anti-Virus, on page 365
Domain Key signing DKIM/Domain Keys is a method for verifying authenticity of email based on
a signing key used by the sender. See Email Authentication, on page 601
Centralized management See Centralized Management Using Clusters, on page 1219
Delivery throttling For each domain, you can assign a maximum number of connections and
recipients that will never be exceeded by the system in a given time period. This
“good neighbor” table is defined through the destconfig command.
For more information, see Controlling Email Delivery Using Destination
Controls, on page 734.
Bounce Verification Verify the authenticity of bounce messages. See Bounce Verification, on page
735.
Delegated administration See Distributing Administrative Tasks, on page 977
Trace (debug) See Debugging Mail Flow Using Test Messages: Trace, on page 1249.
VLAN, NIC-pairing See Advanced Network Configuration, on page 1127
Optional Anti-virus engine You can add optional anti-virus scanning to ensure the integrity of your outbound
messages. See Anti-Virus Scanning Overview, on page 365.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1276
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Setting Up the Email Gateway for Optimized Outbound Mail Delivery
Setting Up the Email Gateway for Optimized Outbound Mail
Delivery
Procedure
Step 1 Apply the provided feature key. You will need to apply the key to your email gateway prior to running the
system setup wizard (prior to configuring the email gateway). Apply the key via the System Administration
> Feature Key page or by issuing the featurekey command in the CLI.
Note The preceding feature keys include a sample 30 day Sophos or McAfee Anti-Virus license you can
use to test anti-virus scanning on outbound mail.
Step 2 Reboot the email gateway.
Step 3 Run the system setup wizard (GUI or CLI) and configure your email gateway.
Keep in mind that email gateways that are optimized for outbound delivery do not include anti-spam scanning
or the Outbreak Filters feature. (Please ignore these chapters.)
Note In a clustered environment, you cannot combine email gateways that are configured with the D-Mode
feature key with AsyncOS email gateways that are not configured with the delivery performance
package.
Configuring Resource-Conserving Bounce Settings
Once the email gateway is configured for optimized outbound mail delivery, you can configure the system
to detect potential delivery problems and bounce all messages for a destination.
Note Using this setting will bounce all messages in the queue for a destination domain that is deemed undeliverable.
You will need to re-send the message once the delivery issues have been resolved.
Example of Enabling Resource-Conserving Bounce Settings
mail3.example.com> bounceconfig
Choose the operation you want to perform:
- NEW - Create a new profile.
- EDIT - Modify a profile.
- DELETE - Remove a profile.
- SETUP - Configure global bounce settings.
[]> setup
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1277
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Sending Bulk Mail Using IronPort Mail Merge (IPMM)
Do you want to bounce all enqueued messages bound for a domain if the host is down? [N]>
When using this feature, a host is considered “down” after at least 10 consecutive connection attempts fail.
AsyncOS scans for down hosts every 15 minutes, so it is possible that more than 10 attempts will be made
before the queue is cleared.
Sending Bulk Mail Using IronPort Mail Merge (IPMM)
Note IronPort Mail Merge is available only on email gateways that are D-Mode-enabled.
Overview of IronPort Mail Merge
IronPort Mail Merge removes the burden of generating individual personalized messages from customer
systems. It removes the need to generate thousands of individual messages and transmit them between message
generating systems and the email gateway, resulting in decreased load on your systems and increased throughput
of email delivery.
With IPMM, a single message body is created with variables representing locations in the message to be
replaced for personalization. For each individual message recipient, only the recipient email address and the
variable substitutions need to be transmitted to the email gateway. In addition, IPMM can be used to send
certain recipients specific “parts” of the message body, while excluding certain parts from others recipients.
(For example, suppose you needed to include a different copyright statements at the end of your messages to
recipients in two different countries.)
Benefits of the Mail Merge Function
• Ease of use for the mail administrator. The complexities of creating personalized messages for each
recipient are removed, as IPMM provides variable substitution and an abstracted interface in many
common languages.
• Reduced load on message generation systems. By requiring one copy of the message body and a table
of required substitutions, most of the message generation “work” is off-loaded from message generation
systems and moved to the email gateway that is configured for optimized outbound mail delivery.
• Increased delivery throughput. By reducing the resources necessary to accept and queue thousands of
incoming messages, the email gateway can significantly increase out-bound delivery performance.
• Queue storage efficiency. By storing less information for each message recipient, users can achieve
orders-of- magnitude, better use of queue storage on the D-Mode enabled email gateway.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1278
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Using Mail Merge
Using Mail Merge
SMTP Injection
IPMM extends SMTP as the transport protocol. There is no special configuration that needs to be made to
the email gateway. (By default, IPMM can be enabled for private listeners and disabled for public listeners
on the D-Mode-enabled email gateway.) However, if you are not currently using SMTP as your injection
protocol, you must create a new private listener that utilizes SMTP through the D-Mode enabled email gateway
interface.
Use the setipmm subcommand of listenerconfig to enable IPMM on the listener. For more information, see
Configuring the Gateway to Receive Email, on page 77
IPMM modifies SMTP by altering two commands — MAIL FROM and DATA — and adding another: XDFN
. The MAIL FROM command is replaced with XMRG FROM and, the DATA command is replaced with
XPRT .
To generate a Mail Merge message, the commands used to generate the message need to be issued in a particular
sequence.
1. The initial EHLO statement, identifying the sending host.
2. Each message starts with an XMRG FROM: statement, indicating the sender address.
3. Each recipient is then defined:
4. One or more XDFN variable allocation statements are made, including defining the parts (XDFN
*PART=1,2,3...), and any other recipient specific variables.
5. The recipient email address is defined with the RCPT TO: statement. Any variable allocations prior to
the RCPT TO:, but after the prior XMRG FROM, or RCPT TO command, will be mapped to this recipient
email address.
6. Each part is defined using the XPRT n command, with each part terminated by a period (.) character
similar to the DATA command. The last part is defined by the XPRT n LAST command.
Variable Substitution
Any part of the message body, including message headers, can contain variables for substitution. Variables
can appear in HTML messages, as well. Variables are user-defined and must begin with the ampersand ( &
) character and end with the semi-colon character ( ; ). Variable names beginning with an asterisk ( * ) are
reserved and cannot be used.
Reserved Variables
IPMM contains five special “reserved” variables that are predefined.
Table 162: IPMM: Reserved Variables
The reserved variable *FROM is derived from the “Envelope From” parameter. The
*FROM
“Envelope From” parameter is set by the “XMRG FROM:” command.
The reserved variable *TO is derived from the envelope recipient value, as set by the “RCPT
*TO
TO:” command.
The reserved variable *PARTS holds a comma separated list of parts. It is set prior to defining
*PARTS
a recipient with the “RCPT TO:” and determines which of the “XPRT n” message body
blocks a given user will receive.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1279
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Example Message 1
The reserved variable *DATE is replaced with the current date stamp.
*DATE
The reserved variable *DK is used to specify a DomainKeys Signing profile (this profile
*DK
must already exist in AsyncOS). For more information about creating DomainKeys Signing
profiles, see Email Authentication, on page 601
Example Message 1
The following example message body (including headers) contains four distinct variables and five substitution
locations that will be replaced in the final message. Note that the same variable may be used more than once
in the message body. Also, the reserved variable &*TO; is used, which will be replaced with the recipient
email address. This reserved variable does not need to be passed in as a separate variable. The variables in
the example appear in bold.
From: Mr.Spacely <[email protected]>
To: &first_name;&last_name;&*TO;
Subject: Thanks for Being an Example.Com Customer
Dear &first_name;,
Thank you for purchasing a &color; sprocket.
This message needs only be injected once into the email gateway. For each recipient, the following additional
information is required:
• A recipient email address
• Name-value pairs for the variable substitution
Part Assembly
Where SMTP uses a single DATA command for each message body, IPMM uses one or many XPRT commands
to comprise a message. Parts are assembled based upon the order specified per-recipient. Each recipient can
receive any or all of the message parts. Parts can be assembled in any order.
The special variable *PARTS holds a comma separated list of parts.
For example, the following example message contains two parts.
The first part contains the message headers and some of the message body. The second part contains an offer
that can be variably included for specific customers.
Example Message 2, Part 1
From: Mr. Spacely <[email protected]>
To: &first_name; &last_name; &*TO;
Subject: Thanks for Being an Example.Com Customer
Dear &first_name;,
Thank you for purchasing a &color; sprocket.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1280
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Example Message 2, Part 2
Example Message 2, Part 2
Please accept our offer for 10% off your next sprocket purchase.
The message parts need only be injected once into the email gateway. In this case, each recipient requires the
following additional information:
• The ordered list of parts to be included in the final message
• A recipient email address
• Name value pairs for the variable substitution
IPMM and DomainKeys Signing
IPMM does support DomainKeys Signing. Use the *DK reserved variable to specify a DomainKeys profile.
For example:
XDFN first_name="Jane" last_name="User" color="red" *PARTS=1,2 *DK=mass_mailing_1
In this example, “mail_mailing_1” is the name of a previously configured DomainKeys profile.
Command Descriptions
When a client injects IPMM messages to the listener, it uses extended SMTP with the following key commands.
XMRG FROM
Syntax:
XMRG FROM: <sender email address>
This command replaces the SMTP MAIL FROM: command and indicates that what follows is an IPMM
message. An IPMM job is initiated with the XMRG FROM: command.
XDFN
Syntax:
XDFN <KEY=VALUE> [KEY=VALUE]
The XDFN command sets the per-recipient metadata. Note that key-value pairs can optionally be enclosed
in angle brackets or square brackets.
*PARTS is a special reserved variable that indicates the index number as defined by the XPRT command
(described below). The *PARTS variable is split as a comma-delimited list of integers. The integers match
the body parts to be sent as defined by the XPRT commands. The other reserved variables are: *FROM , *TO
, and *DATE .
XPRT
Syntax:
XPRT index_number LAST
Message
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1281
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Notes on Defining Variables
The XPRT command replaces the SMTP DATA command. The command accepts the transfer of the message
part after the command is issued. The command is completed with a single period on a line followed by a
return (which is the same way an SMTP DATA command is completed).
The special keyword LAST indicates the end of the mail merge job and must be used to specify the final part
that will be injected.
After the LAST keyword is used, the message is queued, and delivery begins.
Notes on Defining Variables
• When you define variables with the XDFN command, note that the actual command line cannot exceed
the physical limit of the system. In the case of the D-Mode-enabled email gateway, this limit is 4 kilobytes
per line. Other host systems may have lower thresholds. Use caution when defining multiple variables
on very large lines.
• You can escape special characters using the forward slash “ / ” character when defining variables key-value
pairs. This is useful if your message body contains HTML character entities that might be mistakenly
replaced with variable definitions. (For example, the character entity ™ defines the HTML character
entity for a trademark character. If you created the command XDFN trade=foo and then created a IPMM
message containing the HTML character entity “ ™ ” the assembled message would contain the
variable substitution (“ foo ”) instead of the trademark character. The same concept is true for the
ampersand character “&” which is sometimes used in URLs containing GET commands.
Example IPMM Conversation
The following is an example IPMM conversation of Example Message #2 (shown above). The message will
be sent to two recipients in this example: “Jane User” and “Joe User.”
In this example, the type in bold represents what you would type in a manual SMTP conversation with the
D-Mode-enabled email gateway, type in monospaced type represents the responses from the SMTP server,
and italic type represents comments or variables.
A connection is established:
220 ESMTP
EHLO foo
250 - ehlo responses from the listener enabled for IPMM
The conversation is started:
XMRG FROM:<[email protected]> [Note: This replaces the MAIL FROM: SMTP command.]
250 OK
Variables and parts are set for each recipient:
XDFN first_name="Jane" last_name="User" color="red" *PARTS=1,2
[Note: This line defines three variables (first_name, last_name, and color) and then
uses the *PARTS reserved variable to define that the next recipient defined will receive
message parts numbers 1 and 2.]
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1282
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Example IPMM Conversation
250 OK
RCPT TO:<[email protected]>
250 recipient <[email protected]> ok
XDFN first_name="Joe" last_name="User" color="black" *PARTS=1
[Note: This line defines three variables (first_name, last_name, and color) and then
uses the *PARTS reserved variable to define that the next recipient defined will receive
message parts numbers 1 only.]
RCPT TO:<[email protected]>
250 recipient <[email protected]> ok
Next, part 1 is transmitted:
XPRT 1 [Note: This replaces the DATA SMTP command.]
354 OK, send part
From: Mr. Spacely <[email protected]>
To: &first_name; &last_name; &*TO;
Subject: Thanks for Being an Example.Com Customer
&*DATE;
Dear &first_name;,
Thank you for purchasing a &color; sprocket.
And then part 2 is transmitted. Note that the LAST keyword is used to identify Part 2 as the final part to
assemble:
XPRT 2 LAST
Please accept our offer for 10% off your next sprocket purchase.
250 Ok, mailmerge message enqueued
The “250 Ok, mailmerge message queued” notes that the message has been accepted.
Based on this example, recipient Jane User will receive this message:
From: Mr. Spacely <[email protected]>
To: Jane User <[email protected]>
Subject: Thanks for Being an Example.Com Customer
message date
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1283
Optimizing the Email Gateway for Outbound Mail Delivery Using D-Mode
Example Code
Dear Jane,
Thank you for purchasing a red sprocket.
Please accept our offer for 10% off your next sprocket purchase.
Recipient Joe User will receive this message:
From: Mr. Spacely <[email protected]>
To: Joe User <[email protected]>
Subject: Thanks for Being an Example.Com Customer
message date
Dear Joe,
Thank you for purchasing a black sprocket.
Example Code
Cisco has created libraries in common programming languages to abstract the task of injecting IPMM messages
into the email gateway listener enabled for IPMM. Contact Cisco Customer Support for examples of how to
use the IPMM library. The code is commented extensively to explain its syntax.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1284
CHAPTER 48
Centralizing Services on a Cisco Secure Email
and Web Manager (M-Series)
This chapter contains the following sections:
• Overview of Cisco Secure Email and Web Manager Services , on page 1285
• Network Planning, on page 1286
• Working with an External Spam Quarantine , on page 1286
• About Centralizing Policy, Virus, and Outbreak Quarantines , on page 1289
• Configuring Centralized Reporting, on page 1294
• Configuring Centralized Message Tracking, on page 1295
• Using Centralized Services , on page 1295
Overview of Cisco Secure Email and Web Manager Services
The Cisco Secure Email and Web Manager (M-Series appliance) is an external or “off box” location that
provides a single interface to certain services on multiple email gateways.
The Cisco Secure Email and Web Manager includes the following features:
• External spam quarantine. Holds spam and suspected spam messages for end users, and allow end users
and administrators to review messages that are flagged as spam before making a final determination.
• Centralized policy, virus, and outbreak quarantines. Provide a single location behind the firewall to store
and manage messages quarantined by anti-virus scanning, outbreak filters, and policies.
• Centralized reporting. Run reports on aggregated data from multiple email gateways.
• Centralized tracking. Track email messages that traverse multiple email gateways.
For complete information about configuring and using your Cisco Secure Email and Web Manager, see the
Cisco Secure Email and Web Manager User Guide.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1285
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Network Planning
Caution If you have enabled two-factor authentication on your email gateway, you can add it to a Cisco Secure Email
and Web Managerusing pre-shared keys. Use the smaconfig > add command in the CLI to configure this
setting.
OR
Disable two-factor authentication on your email gateway, before you add it to Cisco Secure Email and Web
Manager. For more information, see Disabling Two-Factor Authentication, on page 996.
Network Planning
The Cisco Secure Email and Web Manager lets you separate the end-user interfaces (such as mail applications)
from the more secure gateway systems residing in your various DMZs. Using a two-layer firewall can provide
you with flexibility in network planning so that end users do not connect directly to the outer DMZ.
The following figure shows a typical network configuration incorporating Cisco Secure Email and Web
Manager and multiple DMZs.
Figure 88: Typical Network Configuration with Cisco Secure Email and Web Manager
Large corporate data centers can share one Cisco Secure Email and Web Manager which acts as an external
spam quarantine for one or more email gateways. Meanwhile, remote offices can maintain local spam
quarantines on email gateways for local use.
Working with an External Spam Quarantine
• Mail Flow and External Spam Quarantine , on page 1286
• Migrating from a Local Spam Quarantine to an External Quarantine, on page 1287
• Enabling an External Spam Quarantine and External Safelist/Blocklist , on page 1288
• Disabling the Local Spam Quarantine to Activate the External Quarantine , on page 1289
• Troubleshooting an External Spam Quarantine , on page 1289
Mail Flow and External Spam Quarantine
If your network is configured as described in Network Planning, on page 1286, incoming mail from the Internet
is received by appliances in the outer DMZ. Clean mail is sent along to the mail transfer agent (MTA)
(groupware) in the inner DMZ and eventually to the end users within the corporate network.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1286
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Migrating from a Local Spam Quarantine to an External Quarantine
Spam and suspected spam (depending on your mail flow policy settings) is sent to the spam quarantine on
Cisco Secure Email and Web Manager. End users may then access the quarantine and elect to delete spam
and release messages that they would like to have delivered to themselves. Messages remaining in the spam
quarantine are automatically deleted after a configurable amount of time.
Messages that are released from the external quarantine on the Cisco Secure Email and Web Manager are
returned to the originating email gateway for delivery. These messages do not normally pass through the
following processes before delivery: HAT and other policy or scanning settings, RAT, domain exceptions,
aliasing, incoming filters, masquerading, bounce verification, and the work queue.
An email gateway that is configured to send mail to a Cisco Secure Email and Web Manager will automatically
expect to receive mail released from the Cisco Secure Email and Web Manager and will not reprocess those
messages when they are received back. For this to work, the IP address of the Cisco Secure Email and Web
Manager must not change. If the IP address of the Cisco Secure Email and Web Managerchanges, the receiving
email gateway will process the message as it would any other incoming message. You should always use the
same IP address for receiving and delivery on the Cisco Secure Email and Web Manager.
The Cisco Secure Email and Web Manager accepts mail for quarantining from the IP addresses specified in
the spam quarantine settings. To configure the spam quarantine on the Security Management appliance, see
the Cisco Secure Email and Web Manager User Guide.
Mail released by the Cisco Secure Email and Web Manager is delivered to the primary and secondary hosts
(content security appliance or other groupware host) as defined in the spam quarantine settings (see the Cisco
Secure Email and Web Manager User Guide). Therefore, regardless of the number of email gateways delivering
mail to the Cisco Secure Email and Web Manager, all released mail, notifications, and alerts are sent to a
single host (groupware or content security appliance). Take care not to overburden the primary host for delivery
from the Cisco Secure Email and Web Manager.
Migrating from a Local Spam Quarantine to an External Quarantine
If you are currently using the local spam quarantine on an email gateway but would like to migrate to an
external spam quarantine hosted on a Cisco Secure Email and Web Manager — while retaining access to the
messages in the local quarantine — you should prevent new messages from entering the local quarantine
during the transition.
Consider the following possible strategies:
• Configuring anti-spam settings — Configure the anti-spam settings on your mail policy specifying Cisco
Secure Email and Web Manager as the alternate host. This action sends new spam to the external quarantine
while still allowing access to the local quarantine.
• Setting a shorter expiration time — Configure the Schedule Delete After setting on the local quarantine
to a shorter duration.
• Deleting all of the remaining messages — To delete all remaining messages in the local quarantine,
disable the quarantine and the click the “Delete All” link on the local quarantines page (see Deleting
Messages from the Spam Quarantine, on page 974). This link only becomes available when a local spam
quarantine with messages still contained in it has been disabled.
You should now be ready to enable the external quarantine and disable the local quarantine.
Note If both the local quarantine and the external quarantine are enabled, the local quarantine is used.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1287
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Enabling an External Spam Quarantine and External Safelist/Blocklist
Enabling an External Spam Quarantine and External Safelist/Blocklist
You can enable only one external spam quarantine on an email gateway.
Before You Begin
• Review the information in Mail Flow and External Spam Quarantine , on page 1286 .
• Review and take action on the information in Migrating from a Local Spam Quarantine to an External
Quarantine, on page 1287.
• Configure Cisco Secure Email and Web Manager to support the centralized spam quarantine and
safelist/blocklist features. See the documentation for your Cisco Secure Email and Web Manager.
• If a different external spam quarantine was previously configured for the Email Security appliance, first
disable the external spam quarantine setting.
Complete the following procedure on each email gateway.
Procedure
Step 1 Select Security Services > Centralized Services > Spam Quarantine.
Step 2 Click Configure.
Step 3 Select Enable External Spam Quarantine.
Step 4 In the Name field, enter the name of Cisco Secure Email and Web Manager
The name is not significant, and is used for reference only. For example, enter the hostname of Cisco Secure
Email and Web Manager.
Step 5 Enter an IP address and port number.
These must match the IP address and port number that are specified on Cisco Secure Email and Web Manager
in the Spam Quarantines Settings page (Management Appliance > Centralized Services > Spam Quarantine.)
Step 6 (Optional) Select the check box to enable the External Safelist/Blocklist feature, and specify the appropriate
blocklist action.
Step 7 Submit and commit your changes.
Step 8 Repeat this procedure for each email gateway.
What to do next
If you have been using a local quarantine, see Disabling the Local Spam Quarantine to Activate the External
Quarantine , on page 1289.
Related Topics
• Local Versus External Spam Quarantine , on page 947
• Spam Quarantine, on page 947
• Managing Spam and Graymail, on page 383
• How to Configure the Email Gateway to Scan Messages for Spam, on page 384
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1288
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Disabling the Local Spam Quarantine to Activate the External Quarantine
Disabling the Local Spam Quarantine to Activate the External Quarantine
If you were using a local spam quarantine before enabling an external spam quarantine, you must disable the
local quarantine in order to send messages to the external quarantine.
Before You Begin
Follow all directions, including information in the Before You Begin section, in Enabling an External Spam
Quarantine and External Safelist/Blocklist , on page 1288.
Procedure
Step 1 Select Monitor > Spam Quarantine.
Step 2 In the Spam Quarantine section, click the Spam Quarantine link.
Step 3 Deselect Enable Spam Quarantine.
Ignore any warnings to adjust mail policies as a result of this change. Mail policies automatically send messages
to the external spam quarantine if you have configured the external quarantine settings.
Step 4 Submit and commit your changes.
Troubleshooting an External Spam Quarantine
Problem: Messages released from Cisco Secure Email and Web Manager are unnecessarily reprocessed by
the email gateway.
Solution: This can occur if the IP address of Cisco Secure Email and Web Manager has changed. See Mail
Flow and External Spam Quarantine , on page 1286.
About Centralizing Policy, Virus, and Outbreak Quarantines
• Centralized Policy, Virus, and Outbreak Quarantines , on page 1289
• About Migration of Policy, Virus, and Outbreak Quarantines , on page 1290
• Centralizing Policy, Virus, and Outbreak Quarantines , on page 1291
• About Disabling Centralized Policy, Virus, and Outbreak Quarantines, on page 1292
• Troubleshooting Centralized Policy, Virus, and Outbreak Quarantines , on page 1293
Centralized Policy, Virus, and Outbreak Quarantines
You can centralize policy, virus, and outbreak quarantines on a Cisco Secure Email and Web Manager.
Messages are processed by email gateways but are stored in quarantines on Cisco Secure Email and Web
Manager.
Centralizing policy, virus, and outbreak quarantines offers the following benefits:
• Administrators can manage quarantined messages from multiple email gateways in one location.
• Quarantined messages are stored behind the firewall instead of in the DMZ, reducing security risk.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1289
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Restrictions and Limitations of Centralized Policy, Virus, and Outbreak Quarantines
• Centralized quarantines can be backed up using the standard backup functionality on Cisco Secure Email
and Web Manager.
For complete information, see the user guide or online help for your Cisco Secure Email and Web Manager.
Restrictions and Limitations of Centralized Policy, Virus, and Outbreak Quarantines
• On each email gateway, either all policy, virus, and outbreak quarantines must be centralized or all must
be stored locally.
• Because scanning engines are not available on Cisco Secure Email and Web Manager, you cannot
manually test messages in policy, virus, or outbreak quarantines for viruses.
Requirements for Centralized Policy, Virus, and Outbreak Quarantines in Cluster Configurations
You can enable centralized policy, virus, and outbreak quarantines at any level for clustered appliances.
Requirements:
• Before you enable centralized policy, virus, and outbreak quarantines on an email gateway at a particular
level (machine, group, or cluster), all appliances that belong to the same level must first be added to
Cisco Secure Email and Web Manager.
• Content and message filters and DLP message actions must be configured at the same level and not
overridden at any level below that level.
• Centralized policy, virus, and outbreak quarantines settings must be configured at the same level and not
be overridden at any level below the configured level.
• Ensure that the interface to be used for communications with Cisco Secure Email and Web Manager has
the same name on all appliances in the group or cluster.
For example:
If you want to enable centralized policy, virus, and outbreak quarantines at the cluster or group level, but an
email gateway which is connected to the cluster has these settings defined at the machine level, you must
remove the centralized quarantines settings configured at the machine level before you can enable the feature
at the cluster or group level.
About Migration of Policy, Virus, and Outbreak Quarantines
When you centralize policy, virus, and outbreak quarantines, existing policy, virus, and outbreak quarantines
on your email gateway migrate to Cisco Secure Email and Web Manager.
You will configure migration on Cisco Secure Email and Web Manager, but migration occurs when you
commit the change enabling centralized policy, virus, and outbreak quarantines on the email gateway.
As soon as you commit this change, the following occur:
• Local policy, virus, and outbreak quarantines on the email gateway are disabled. All new messages
entering these quarantines will be quarantined on Cisco Secure Email and Web Manager.
• Migration of existing non-spam quarantines to Cisco Secure Email and Web Manager begins.
• All local policy, virus, and outbreak quarantines are deleted. If you configured a custom migration, any
local policy quarantines that you chose not to migrate are also deleted. For effects of deleting policy
quarantines, see About Deleting Policy Quarantines , on page 934.
• A message that was in multiple quarantines before migration will be in the corresponding centralized
quarantines after migration.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1290
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Centralizing Policy, Virus, and Outbreak Quarantines
• Migration happens in the background. The amount of time it takes depends on the size of your quarantines
and on your network. When you enable centralized quarantines on the email gateway, you can enter one
or more email addresses that will receive notification when migration is complete.
• The settings in the centralized quarantine, not those of the originating local quarantine, apply to the
messages. However, the original expiration time still applies to each message.
Note All centralized quarantines that are automatically created during migration have the default quarantine settings.
Centralizing Policy, Virus, and Outbreak Quarantines
Before you begin
Note Perform this procedure during a maintenance window or off-peak hours.
• You must first configure your Cisco Secure Email and Web Manager for centralized policy, virus, and
outbreak quarantines. See the table in the “Centralizing Policy Virus, and Outbreak Quarantines” section
in the “Centralized Policy, Virus, and Outbreak Quarantines” chapter in the online help or user guide for
Cisco Secure Email and Web Manager.
• If the space allocated to centralized quarantines on Cisco Secure Email and Web Manager will be smaller
than the amount of space that your existing local quarantines collectively occupy, messages will be
expired early based on the quarantine settings on Cisco Secure Email and Web Manager. Before migration,
consider taking manual action to reduce quarantine sizes. For more information about early expiration,
see Default Actions for Automatically Processed Quarantined Messages , on page 931.
• If you have chosen automatic migration, or configured custom migration to create centralized quarantines
during migration, consider noting the current quarantine settings on your email gateways in order to use
them as guidelines for configuring the centralized quarantines.
• If your email gateways are deployed in a cluster configuration, see Requirements for Centralized Policy,
Virus, and Outbreak Quarantines in Cluster Configurations , on page 1290.
• Be aware of the changes that will occur as soon as you commit the changes in this procedure. See About
Migration of Policy, Virus, and Outbreak Quarantines , on page 1290.
Procedure
Step 1 Choose Security Services > Centralized Services > Policy, Virus, and Outbreak Quarantines.
Step 2 Click Enable.
Step 3 Enter the interface and port to use for communication with Cisco Secure Email and Web Manager.
Make sure the interface and port are reachable from Cisco Secure Email and Web Manager.
If your email gateways are clustered, the interface you select must be available on all machines in the cluster.
Step 4 To receive notification when migration is complete, enter one or more email addresses.
Step 5 Verify the information about quarantines to be migrated to be sure that this is what you want.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1291
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
About Disabling Centralized Policy, Virus, and Outbreak Quarantines
Step 6 If you are completing a Custom migration, note any quarantines that will be deleted when you commit the
changes in this procedure.
Step 7 Verify that the information about content and message filters and DLP message actions to be updated is as
you expect it to be.
Note For cluster configurations, filters and message actions can be automatically updated on a particular
level only if filters and message actions are defined at that level and not overridden at any level
below that level. After migration, you may need to manually reconfigure filters and message actions
with centralized quarantine names.
Step 8 If you need to reconfigure migration mapping:
a) Return to Cisco Secure Email and Web Manager.
b) Reconfigure the migration mapping.
On Cisco Secure Email and Web Manager, select a quarantines to remap, then click Remove from
Centralized Quarantine. Then you can remap the quarantine.
c) Commit the new migration configuration on Cisco Secure Email and Web Manager.
d) Start this procedure from the beginning.
Important! Be sure to reload the Security Services > Centralized Services > Policy, Virus, and
Outbreak Quarantines page.
Step 9 Click Submit.
Step 10 If you need to reconfigure migration mapping, follow the procedure in Step 8.
Step 11 Commit your changes.
Note While migration is in progress, avoid making configuration changes on email gateway or Cisco
Secure Email and Web Manager.
Step 12 Look at the top of the page to monitor migration status, or, if you entered an email address when configuring
migration, await the email notifying you that migration is complete.
What to do next
Perform the remaining tasks described in the table in the “Centralizing Policy, Virus, and Outbreak Quarantines”
topic in the online help or user guide for Cisco Secure Email and Web Manager.
Related Topics
• Which User Groups Can Access Policy, Virus, and Outbreak Quarantines , on page 936
About Disabling Centralized Policy, Virus, and Outbreak Quarantines
When you disable centralized policy, virus, and outbreak quarantines on the email gateway:
• Local quarantines are automatically enabled on the email gateway.
• System-created quarantines and quarantines that are referenced by message filters, content filters, and
DLP message actions are automatically created on the email gateway. The Virus, Outbreak, and
Unclassified quarantines are created with the same settings that they had before quarantines were
centralized, including assigned user roles. All other quarantines are created with default settings.
• Newly quarantined messages go immediately to local quarantines.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1292
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Disabling Centralized Policy, Virus, and Outbreak Quarantines
• Messages in the centralized quarantine at the time it is disabled remain there until one of the following
occurs:
• Messages are manually deleted or automatically deleted when they expire.
• Messages are manually or automatically released, if one of the following is also true:
* An alternate release appliance is configured on Cisco Secure Email and Web Manager. See the online help
or documentation for Cisco Secure Email and Web Manager.
* Centralized quarantines are again enabled on the email gateway.
Disabling Centralized Policy, Virus, and Outbreak Quarantines
Before you begin
• Understand the impacts of disabling centralized policy, virus, and outbreak quarantines.
• Do one of the following:
• Process all messages that are currently in centralized policy, virus, and outbreak quarantines.
• Ensure that you have designated an alternate release appliance to process messages that are released
from the centralized quarantine after you disable it. For information, see the online help or user
guide for your Cisco Secure Email and Web Manager.
Procedure
Step 1 On the email gateway, choose Security Services > Centralized Services > Policy, Virus, and Outbreak
Quarantines.
Step 2 Disable centralized policy, virus, and outbreak quarantines.
Step 3 Submit and commit the change.
Step 4 Customize the settings of the newly created local quarantines.
Troubleshooting Centralized Policy, Virus, and Outbreak Quarantines
If a Cisco Secure Email and Web Manager Goes Out of Service
If Policy, Virus, and Outbreak Quarantines are centralized on a Cisco Secure Email and Web Manager that
goes out of service, you should disable these centralized quarantines on the email gateway.
If you deploy a replacement Cisco Secure Email and Web Manager, you must reconfigure quarantine migration
on Cisco Secure Email and Web Manager and on each email gateway. See the table in the “Centralizing Policy
Virus, and Outbreak Quarantines” section in the “Centralized Policy, Virus, and Outbreak Quarantines” chapter
in the online help or user guide for Cisco Secure Email and Web Manager.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1293
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Configuring Centralized Reporting
Configuring Centralized Reporting
Before you begin
• Enable and configure centralized reporting on a Cisco Secure Email and Web Manager. See prerequisites
and instructions in Cisco Secure Email and Web Manager User Guide.
• Ensure that sufficient disk space is allocated to the reporting service on Cisco Secure Email and Web
Manager.
Procedure
Step 1 Click Security Services > Reporting.
Step 2 In the Reporting Service section, select the Centralized Reporting option.
Step 3 Submit and commit your changes.
Requirements for Advanced Malware Protection Reporting
For required configurations for full reporting on Advanced Malware Protection (file reputation and file analysis)
features on Cisco Secure Email and Web Manager, see the information about Advanced Malware Protection
reports in the email reporting chapter of the online help or user guide for your version of Cisco Secure Email
and Web Manager software.
Availability of Reporting Information after Changing to Centralized Reporting
When centralized reporting is enabled on an email gateway:
• Existing data on the email gateway for the monthly report is not transferred to Cisco Secure Email and
Web Manager.
• Archived reports on the email gateway are not available.
• The email gateway stores only a week’s worth of data.
• New data for the monthly and yearly reports is stored on Cisco Secure Email and Web Manager.
• Scheduled reports on the email gateway are suspended.
• You can no longer access the scheduled report configuration page on the email gateway.
About Disabling Centralized Reporting
If you disable centralized reporting on the email gateway, the email gateway begins storing new monthly
report data, scheduled reports resume, and you can access its archived reports. After disabling centralized
reporting, the appliance only displays data for the past hour and day, but not the past week or month. This is
temporary. The appliance will display the reports for the past week and month after it accumulates enough
data. If the email gatewayEmail Security appliance is placed back into centralized reporting mode, it will
display data for the past week in the interactive reports.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1294
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Configuring Centralized Message Tracking
Configuring Centralized Message Tracking
Before you begin
Note You cannot enable both centralized and local tracking on an email gateway.
Procedure
Step 1 Click Security Services > Message Tracking.
Step 2 In the Message Tracking Service section, click Edit Settings.
Step 3 Select the Enable Message Tracking Service check box.
Step 4 Select the Centralized Tracking option.
Step 5 (Optional) Select the check box to save information for rejected connections.
Note Saving tracking information for rejected connections can adversely affect the performance of Cisco
Secure Email and Web Manager.
Step 6 Submit and commit your changes.
What To Do Next
To use centralized tracking, you must enable the feature on the email gateways and Cisco Secure Email and
Web Manager. To enable centralized tracking on S Cisco Secure Email and Web Manager, see Cisco Secure
Email and Web Manager User Guide.
Using Centralized Services
For instructions on using centralized services, see the Cisco Secure Email and Web Manager User Guide.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1295
Centralizing Services on a Cisco Secure Email and Web Manager (M-Series)
Using Centralized Services
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1296
APPENDIX A
FTP, SSH, and SCP Access
This appendix contains the following sections:
• IP Interfaces, on page 1297
• Configuring FTP Access to the Email Gateway, on page 1298
• Secure Copy (scp) Access , on page 1300
• Accessing the Email Gateway via a Serial Connection, on page 1301
IP Interfaces
An IP interface contains the network configuration data needed for an individual connection to the network.
You can configure multiple IP interfaces to a physical Ethernet interface. You can assign an Internet Protocol
version 4 (IPv4) or version 6 (IPv6) to an IP interface or both.
Table 163: Services Enabled by Default on Interfaces
Enabled by default?
Service Default port Management interface2 New interfaces you create
FTP 21 No No
SSH 22 Yes No
HTTP 80 Yes No
HTTPS 443 Yes No
2
The “Management Interface” settings shown here are also the default settings for the Data 1 Interface
on Cisco C170 email gateway.
• If you need to access the email gateway via the graphical user interface (GUI), you must enable HTTP
and/or HTTPS on an interface.
• If you need to access the email gateway for the purposes of uploading or downloading configuration
files, you must enable FTP on an interface.
• You can also upload or download files using secure copy ( scp ).
You can configure HTTP or HTTPS access to the spam quarantine via an IP interface.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1297
FTP, SSH, and SCP Access
How AsyncOS Selects Default IP Interface
For email delivery and Virtual Gateways, each IP interface acts as one Virtual Gateway address with a specific
IP address and hostname. You can also “join” interfaces into distinct groups (via the CLI), and the system
will cycle through these groups when delivering email.
Joining or grouping Virtual Gateways is useful for load-balancing large email campaigns across several
interfaces. You can also create VLANs, and configure them just as you would any other interface (via the
CLI). For more information, see Advanced Network Configuration, on page 1127
Related Topics
• How AsyncOS Selects Default IP Interface, on page 1298
How AsyncOS Selects Default IP Interface
AsyncOS selects the default IP interface based on the lowest IP address in which the IP interfaces appear
under Network > IP Interfaces page or in the ifconfig CLI command. The first IP interface in the list that
resides on the subnet in question is used.
If there are multiple IP addresses configured within the same subnet as the default gateway, the IP address
with the lowest number is used. For example, if the following IP addresses are configured within the same
subnet,
• 10.10.10.2/24
• 10.10.10.30/24
• 10.10.10.100/24
• 10.10.10.105/24
AsyncOS chooses 10.10.10.2/24 as the default IP interface.
Configuring FTP Access to the Email Gateway
Procedure
Step 1 Use the Network > IP Interfaces page or the interfaceconfig command to enable FTP access for the
interface.
Danger By disabling services via the interfaceconfig command, you have the potential to disconnect
yourself from the CLI, depending on how you are connected to the email gateway. Do not disable
services with this command if you are not able to reconnect to the email gateway using another
protocol, the Serial interface, or the default settings on the Management port.
Step 2 Submit and commit your changes.
Step 3 Access the interface via FTP. Ensure you are using the correct IP address for the interface. For example:
$ ftp 192.168.42.42
Note Many browsers also allow you to access interfaces via FTP.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1298
FTP, SSH, and SCP Access
FTP, SSH, and SCP Access
Step 4 Browse to the directory for the specific task you are trying to accomplish. After you have accessed an interface
via FTP, you can browse the following directories to copy and add (“GET” and “PUT”) files. See the following
table.
Directory Name Description
/configuration The directory where data from the following commands is exported to and/or imported
(saved) from:
• Virtual Gateway mappings ( altsrchost )
• configuration data in XML format ( saveconfig, loadconfig )
• Host Access Table (HAT) ( hostaccess )
• Recipient Access Table (RAT) ( rcptaccess )
• SMTP routes entries ( smtproutes )
• alias tables ( aliasconfig )
• masquerading tables ( masquerade )
• message filters ( filters )
• global unsubscribe data ( unsubscribe )
• test messages for the trace command
• Safelist/Blocklist backup file, saved in the following format:
slbl<timestamp><serial number>.csv
/antivirus The directory where the Anti-Virus engine log files are kept. You can inspect the log
files this directory to manually check for the last successful download of the virus
definition file ( scan.dat ).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1299
FTP, SSH, and SCP Access
Secure Copy (scp) Access
Directory Name Description
/configuration Created automatically for logging via the logconfig and rollovernow commands. See
Logging, on page 1141 for a detailed description of each log.
/system_logs
See “Log File Type Comparison” for the differences between each log file type.
/cli_logs
/status
/reportd_logs
reportqueryd_logs
/ftpd_logs
/mail_logs
/asarchive
/bounces
/error_logs
/avarchive
/gui_logs
/sntpd_logs
/RAID.output
/euq_logs
/scanning
/antispam
/antivirus
/euqgui_logs
/ipmitool.output
Step 5 Use your FTP program to upload and download files to and from the appropriate directory.
Secure Copy (scp) Access
If your client operating system supports a secure copy ( scp ) command, you can copy files to and from the
directories listed in the previous table. For example, in the following example, the file /tmp/test.txt is
copied from the client machine to the configuration directory of the email gateway with the hostname of
mail3.example.com .
Note that the command prompts for the passphrase for the user ( admin ). This example is shown for reference
only; your particular operating system’s implementation of secure copy may vary.
% scp /tmp/test.txt [email protected]:configuration
The authenticity of host 'mail3.example.com (192.168.42.42)' can't be established.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1300
FTP, SSH, and SCP Access
Accessing the Email Gateway via a Serial Connection
DSA key fingerprint is 69:02:01:1d:9b:eb:eb:80:0c:a1:f5:a6:61:da:c8:db.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mail3.example.com ' (DSA) to the list of known hosts.
[email protected]'s passphrase: (type the passphrase)
test.txt 100% |****************************| 1007 00:00
In this example, the same file is copied from the email gateway to the client machine:
% scp [email protected]:configuration/text.txt .
[email protected]'s passphrase: (type the passphrase)
test.txt 100% |****************************| 1007 00:00
You can use secure copy ( scp ) as an alternative to FTP to transfer files to and from the email gateway.
Note Only users in the operators and administrators group can use secure copy ( scp ) to access the email gateway.
For more information, see Adding Users , on page 980.
Accessing the Email Gateway via a Serial Connection
If you are connecting to the email gateway via a serial connection, use the following information for the
console port.
Complete information about this port is in the hardware installation guide for your appliance.
Pinout Details for the Serial Port in 80- and 90- Series Hardware
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1301
FTP, SSH, and SCP Access
Pinout Details for the Serial Port in 70-Series Hardware
Pinout Details for the Serial Port in 70-Series Hardware
The following figure illustrates the pin numbers for the serial port connector, and the following table defines
the pin assignments and interface signals for the serial port connector.
Figure 89: Pin Numbers for the Serial Port
Table 164: Serial Port Pin Assignments
Pin Signal I/O Definition
1 DCD Data carrier detect
2 SIN Serial input
3 SOUT Serial output
4 DTR Data terminal ready
5 GND n/a Signal ground
6 DSR Data set ready
7 RTS Request to send
8 CTS Clear to send
9 RI Ring indicator
Shell n/a n/a Chassis ground
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1302
APPENDIX B
Assigning Network and IP Addresses
This appendix contains the following sections:
• Ethernet Interfaces, on page 1303
• Selecting IP Addresses and Netmasks, on page 1303
• Strategies for Connecting Your Email Gateway, on page 1305
Ethernet Interfaces
Email Gateways have up to four Ethernet interfaces located on the rear panel of the system, depending on the
configuration (whether or not you have the optional optical network interface). They are labeled:
• Management
• Data1
• Data2
• Data3
• Data4
Selecting IP Addresses and Netmasks
When you configure the network, the email gateway must be able to select a unique interface to send an
outgoing packet. This requirement drives some of the decisions regarding IP address and netmask selection
for the Ethernet interfaces. The rule is that only one interface can be on a single network (as determined
through the applications of netmasks to the IP addresses of the interfaces).
An IP address identifies a physical interface on any given network. A physical Ethernet interface can have
more than one IP address for which it accepts packets. An Ethernet interface that has more than one IP address
can send packets over that interface with any one of the IP addresses as the source address in the packet. This
property is used in implementing Virtual Gateway technology.
The purpose of a netmask is to divide an IP address into a network address and a host address. The network
address can be thought of as the network part (the bits matching the netmask) of the IP address. The host
address is the remaining bits of the IP address. The number of bits in a four octet address that are significant
are sometimes expressed in Classless Inter-Domain Routing (CIDR) style. This is a slash followed by the
number of bits (1-32).
A netmask can be expressed in this way by simply counting the ones in binary, so 255.255.255.0 becomes “
/24 ” and 255.255.240.0 becomes “ /20. ”
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1303
Assigning Network and IP Addresses
Sample Interface Configurations
Sample Interface Configurations
This section shows sample interface configurations based on some typical networks. The example uses two
interfaces called Int1 and Int2. In the case of the email gateway, these interface names can represent any two
interfaces out of the three interfaces (Management, Data1, Data2).
Network 1:
Separate interfaces must appear to be on separate networks.
Interface IP Address Netmask Net Address
Int1 192.168.1.10 255.255.255.0 192.168.1.0/24
Int2 192.168.0.10 255.255.255.0 192.168.0.0/24
Data addressed to 192.168.1.X (where X is any number from 1 through 255, except for your own address, 10
in this case) go out on Int1. Anything addressed to 192.168.0.X goes out on Int2. Any packet headed for some
other address not in these formats, most likely out on a WAN or the Internet, is sent to the default gateway,
which must be on one of these networks. The default gateway then forwards the packet on.
Network 2:
The network addresses (network parts of the IP addresses) of two different interfaces cannot be the same.
Ethernet Interface IP Address Netmask Net Address
Int1 192.168.1.10 255.255.0.0 192.168.0.0/16
Int2 192.168.0.10 255.255.0.0 192.168.0.0/16
This situation presents a conflict in that two different Ethernet interfaces have the same network address. If
a packet from the content security appliance is sent to 192.168.1.11 , there is no way to decide which Ethernet
interface should be used to deliver the packet. If the two Ethernet interfaces are connected to two separate
physical networks, the packet may be delivered to the incorrect network and never find its destination. The
email gateway does not allow you to configure your network with conflicts.
You can connect two Ethernet interfaces to the same physical network, but you must construct IP addresses
and netmasks to allow the email gateway to select a unique delivery interface.
IP Addresses, Interfaces, and Routing
When you select an interface on which to perform a command or function in the GUI or CLI that allows you
to select an interface (for example, upgrading AsyncOS or configuring DNS), routing (your default gateway)
takes precedence over your selection.
For example, suppose that you have a email gateway with the three network interfaces configured, each on a
different network segment (assume all /24):
Ethernet IP
Management 192.19.0.100
Data1 192.19.1.100
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1304
Assigning Network and IP Addresses
Summary
Ethernet IP
Data2 192.19.2.100
And your default gateway is 192.19.0.1.
Now, if you perform an AsyncOS upgrade (or other command or function that allows you to select an interface)
and you select the IP that is on Data1 (192.19.1.100), you would expect all the TCP traffic to occur over the
Data1 Ethernet interface. However, instead the traffic goes out of the interface that is set as your default
gateway, in this case Management, but is stamped with the source address of the IP on Data1.
Summary
The content security appliance must always be able to identify a unique interface over which a packet can be
delivered. To make this decision, the email gateway uses a combination of the packet’s destination IP address,
and the network and IP address settings of its Ethernet interfaces. The following table summarizes the preceding
examples:
Same Different
Network Network
Same Physical Interface Allowed Allowed
Different Physical Interface Not allowed Allowed
Strategies for Connecting Your Email Gateway
Keep the following in mind when connecting your email gateway:
• Administrative traffic (CLI, web interface, log delivery) is usually little compared to email traffic.
• If two Ethernet interfaces are connected to the same network switch, but end up talking to a single
interface on another host downstream, or are connected to a network hub where all data are echoed to
all ports, no advantage is gained by using two interfaces.
• SMTP conversations over an interface operating at 1000Base-T are slightly faster than conversations
over the same interfaces operating at 100Base-T, but only under ideal conditions.
• There is no point in optimizing connections to your network if there is a bottleneck in some other part
of your delivery network. Bottlenecks most often occur in the connection to the Internet and further
upstream at your connectivity provider.
The number of interfaces that you choose to connect and how you address them should be dictated by the
complexity of your underlying network. It is not necessary to connect multiple interfaces if your network
topology or data volumes do not call for it. It is also possible to keep the connection simple at first as you
familiarize yourself with the gateway and then increase the connectivity as volume and network topology
require it.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1305
Assigning Network and IP Addresses
Strategies for Connecting Your Email Gateway
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1306
APPENDIX C
Example of Mail Policies and Content Filters
This appendix contains the following sections:
• Overview of Incoming Mail Policies , on page 1307
Overview of Incoming Mail Policies
The following example demonstrates the features of mail policies by illustrating the following tasks:
1. Editing the anti-spam, anti-virus, Outbreak Filter, and Content Filters for the default Incoming Mail Policy.
2. Adding two new policies for different sets of users — the sales organization and the engineering
organization — and then configuring different email security settings for each.
3. Creating three new content filters to be used in the Incoming Mail Overview policy table.
4. Editing the policies again to enable the content filters for some groups, but not for others.
This example is meant to show the power and flexibility with which you can manage different recipient-based
settings for anti-spam, anti-virus, Outbreak Filter, and Content Filters for mail policies. This example assigns
these a custom user role called “Policy Administrator” that has mail policy and content filters access privileges.
For more detailed information about how anti-spam, anti-virus, Outbreak filters, and delegated administration
work, refer to the chapters following this one:
• Managing Spam and Graymail, on page 383
• Anti-Virus, on page 365
• Outbreak Filters, on page 425
• Distributing Administrative Tasks, on page 977
Accessing Mail Policies
You can access incoming and outgoing mail policies by using the Mail Policies menu.
On brand new systems, if you completed all steps in the system setup wizard and you chose to enable
Anti-Spam, Sophos or McAfee Anti-Virus, and Outbreak Filters, the Incoming Mail Policies Page will resemble
in the following figure.
By default, these settings are enabled for the default Incoming Mail Policy:
• Anti-Spam (if the Spam Quarantine is enabled): Enabled
• Positively-identified spam: quarantine, prepend the message subject
• Suspected spam: quarantine, prepend the message subject
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1307
Example of Mail Policies and Content Filters
Enabled, Disabled, and “Not Available”
• Marketing email: scanning not enabled
• Anti-Spam (if the Spam Quarantine is not enabled): Enabled
• Positively-identified spam: deliver, prepend the message subject
• Suspected spam: deliver, prepend the message subject
• Marketing email: scanning not enabled
• Anti-Virus: Enabled, Scan and Repair viruses, include an X-header with anti-virus scanning results
• Repaired messages: deliver, prepend the message subject
• Encrypted messages: deliver, prepend the message subject
• Unscannable messages: deliver, prepend the message subject
• Virus infected messages: drop
• Outbreak Filters: Enabled
• No file extensions are excepted
• Retention time for messages with suspect viral attachments is 1 day
• Message modification is not enabled
• Content Filters: Disable
Figure 90: Incoming Mail Policies Page: Defaults for a Brand New Email Gateway
Note In this example, the Incoming Mail Policy will use the default anti-spam settings for when the Spam Quarantine
is enabled.
Enabled, Disabled, and “Not Available”
The columns in a mail policy table (either incoming or outgoing) display links for the state of the security
service for each policy name. If a service is enabled, the word “Enabled” or a summary of the configuration
is displayed. Similarly, the word “Disabled” is displayed if a service is disabled.
“Not Available” is displayed as a link if the license agreement for a service has not been accepted yet or a
service has expired. In these cases, clicking the “Not Available” link will display the global page within the
Security Services tab, rather than the page where you can configure per-policy settings for a service. An alert
is displayed to let you know that your page has changed to a different tab. See the following figure.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1308
Example of Mail Policies and Content Filters
Configuring the Default Anti-Spam Policies for Incoming Messages
Figure 91: Security Services Not Available
Configuring the Default Anti-Spam Policies for Incoming Messages
Each row in the mail policy table represents a different policy. Each column represents a different security
service.
• To edit the default policy, click any of the links for a security service in the bottom row of the incoming
or outgoing mail policy table.
In this example, you will change the anti-spam settings for the default policy for incoming mail to be more
aggressive. The default value is to quarantine positively identified and suspected spam messages, with marketing
email scanning disabled. This example shows how to change the setting so that positively identified spam is
dropped. Suspected spam continues to be quarantined. Marketing email scanning is enabled, with marketing
messages being delivered to the intended recipients. The subjects of marketing messages will be prepended
with the text [MARKETING] .
Procedure
Step 1 Click the link for the anti-spam security service.
Note For default security service settings, the first setting on the page defines whether the service is
enabled for the policy. You can click “Disable” to disable the service altogether.
Step 2 In the “Positively Identified Spam Settings” section, change the “Action to apply to this message” to Drop.
Step 3 In the “Marketing Email Settings” section, click Yes to enable marketing email scanning.
If enabled, the default action is to deliver legitimate marketing messages while prepending the subject with
the text [MARKETING] .
The “Add text to message” field only accepts US-ASCII characters.
Step 4 Click Submit. Note that the summary link for the anti-spam security service in the Incoming Mail Policies
table has changed to reflect the new values.
Similar to the steps above, you can change the default anti-virus and virus outbreak filter settings for the
default policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1309
Example of Mail Policies and Content Filters
Creating a Mail Policy for a Group of Sender and Recipients
Figure 92: Anti-Spam Settings Page
Creating a Mail Policy for a Group of Sender and Recipients
In this part of the example, you will create two new policies: one for the sales organization (whose members
will be defined by an LDAP acceptance query), and another for the engineering organization. Both policies
will be assigned to the Policy Administrator custom user role to make delegated administrators belonging to
this role responsible for managing these policies. You will then configure different email security settings for
each.
Procedure
Step 1 Click the Add Policy button to begin creating a new policy.
Step 2 Define a unique name for and adjust the order of the policy (if necessary).
The name of the policy must be unique to the Mail Policies table (either incoming or outgoing) in which it is
defined.
Remember that each recipient is evaluated for each policy in the appropriate table (incoming or outgoing) in
a top-down fashion.
Step 3 Click the Editable by (Roles) link and select the custom user roles for the delegated administrators who will
be responsible for managing the mail policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1310
Example of Mail Policies and Content Filters
Example of Mail Policies and Content Filters
When you click the link, AsyncOS displays the custom roles for delegated administrators that have edit
privileges for mail policies. Delegated administrators can edit a policy’s Anti-Spam, Anti-Virus, and Outbreak
Filters settings and enable or disable content filters for the policy. Only operators and administrators can
modify a mail policy’s name or its senders, recipients, or groups. Custom user roles that have full access to
mail policies are automatically assigned to mail policies.
See the Distributing Administrative Tasks, on page 977 for more information on delegated administration.
Step 4 Define users for the policy.
You define whether the user is a sender or a recipient. (See Examples of Policy Matching, on page 270 for
more detail.) The form shown in the following figure defaults to recipients for incoming mail policies and to
senders for outgoing mail policies.
Users for a given policy can be defined in the following ways:
• Full email address: [email protected]
• Partial email address: user@
• All users in a domain: @example.com
• All users in a partial domain: @.example.com
• By matching an LDAP Query
Note Entries for users are case-insensitive in both the GUI and CLI in AsyncOS. For example, if you
enter the recipient Joe@ for a user, a message sent to [email protected] will match.
If you store user information within LDAP directories in your network infrastructure — for example, in
Microsoft Active Directory, SunONE Directory Server (formerly known as “iPlanet Directory Server”), or
Open LDAP directories — you can configure the email gateway to query your LDAP servers for the purposes
of accepting recipient addresses, rerouting messages to alternate addresses and/or mail hosts, masquerading
headers, and determining if messages have recipients or senders from specific groups.
If you have configured the email gateway to do so, you can use the configured queries to define users for a
mail policy.
See LDAP Queries, on page 775 for more information.
Figure 93: Defining Users for a Policy
Step 5 Click the Add button to add users into the Current Users list.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1311
Example of Mail Policies and Content Filters
Example of Mail Policies and Content Filters
Policies can contain mixtures of senders, recipients, and LDAP queries.
Use the Remove button to remove a defined user from the list of current users.
Step 6 When you are finished adding users, click Submit.
Note that all security services settings are set to use the default values when you first add a policy.
Figure 94: Newly Added Policy — Sales Group
Step 7 Click the Add Policy button again to add another new policy.
In this policy, individual email addresses for members of the engineering team are defined:
Figure 95: Creating a Policy for the Engineering Team
Step 8 When you are finished adding users for the engineering policy, click Submit.
Step 9 Commit your changes.
Figure 96: Newly Added Policy — Engineering Team
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1312
Example of Mail Policies and Content Filters
Default, Custom, and Disabled
Note At this point, both newly created policies have the same settings applied to them as those in the
default policy. Messages to users of either policy will match; however, the mail processing settings
are not any different from the default policy. Therefore, messages that match users in the
“Sales_Group” or “Engineering” policies will not be processed any differently than the default
policy.
Default, Custom, and Disabled
The key at the bottom of the table shows how the color coding of cells for specific policies relates to the policy
defined for the default row:
• Yellow shading shows that the policy is using the same settings as the default policy.
• No shading (white) shows that the policy is using different settings than the default policy.
• Grey shading shows that the security service has been disabled for the policy.
Creating Mail Policies for Different Groups of Senders and Recipients
In this part of the example, you will edit the two policies just created in the previous section.
• For the sales group, you will change the anti-spam settings to be even more aggressive than the default
policy. (See Configuring the Default Anti-Spam Policies for Incoming Messages, on page 1309.) The
default policy of dropping positively identified spam messages will be kept. However, in this example,
you will change the setting for marketing messages so that they will be sent to the Spam quarantine.
This aggressive policy has the effect of minimizing unwanted messages being sent to sales team inboxes.
See Managing Spam and Graymail, on page 383 for more information on anti-spam settings.
• For the engineering team, customize the Outbreak Filters feature setting so that it will modify the URLs
in suspicious messages, except for links to example.com. Attachment files with the extension “dwg” will
be bypassed by the Outbreak Filter scanning.
See Outbreak Filters, on page 425 for more information on configuring Outbreak Filters.
To edit the anti-spam settings for the sales team policy:
Procedure
Step 1 Click the link for the Anti-Spam security service (the Anti-Spam) column in the sales policy row.
Because the policy was just added, the link is named: (use default) .
Step 2 On the anti-spam security service page, change the value for “Enable Anti-Spam Scanning for this Policy”
from “Use Default Settings” to “Use Anti-Spam service.”
Choosing “Use Anti-Spam service” here allows you to override the settings defined in the default policy.
Step 3 In the “Positively-Identified Spam Settings” section, change the “Apply This Action to Message” to “Drop.”
Step 4 In the “Suspected Spam Settings” section, click Yes to enable suspected spam scanning.
Step 5 In the “Suspected Spam Settings” section, change the “Apply This Action to Message” to “Spam Quarantine.”
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1313
Example of Mail Policies and Content Filters
Creating Mail Policies for Different Groups of Senders and Recipients
Note Selecting the Spam quarantine forwards mail according to the settings defined in the Spam Quarantine
chapter.
Step 6 In the “Add text to subject” field, click None.
Messages delivered to the Spam quarantine will have no additional subject tagging.
Step 7 In the “Marketing Email Settings” section, click Yes to enable scanning for marketing mail from legitimate
sources.
Step 8 In the “Apply This Action to Message” section, select “Spam Quarantine.”
Step 9 Submit and commit your changes.
Not that the shading shows that the policy is using different settings than the default policy.
At this point, any message that is suspected spam and whose recipient matches the LDAP query defined for
the sales team policy will be delivered to the Spam Quarantine.
Creating Mail Policies for Different Groups of Senders and Recipients
To edit the Outbreak Filter settings for the engineering team policy:
Procedure
Step 1 Click the link for the Outbreak Filters feature security service (the Outbreak Filters column) in the engineering
policy row.
Because the policy was just added, the link is named: (use default) .
Step 2 On the Outbreak Filters feature security service page, change the scanning setting for the policy to “Enable
Outbreak Filtering (Customize settings).”
Choosing “(Customize settings)” here allows you to override the settings defined in the default policy.
Doing so will also enable the contents of the rest of the page to allow you to select different settings.
Step 3 In the “Bypass Attachment Scanning” section of the page, type dwg in the in the file extension field.
The file extension “ dwg ” is not in the list of known file type that the email gateway can recognize by its
fingerprint when attachment scanning.
Note You do not need to type the period ( . ) before the three letter filename extension.
Step 4 Click Add Extension to add .dwg files to the list of file extensions that will bypass Outbreak Filters feature
scanning.
Step 5 Click Enable Message Modification.
Enabling message modification allows the email gateway to scan for targeted threats, such as phishing and
scams, and URLs to suspicious or malicious websites. The appliance can rewrite links in messages to redirect
the user through the Cisco Security proxy if they attempt to access the website.
Note Anti-spamming scanning must be enabled on the mail policy in order for Outbreak Filters to scan
for targeted, non-viral threats.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1314
Example of Mail Policies and Content Filters
Example of Mail Policies and Content Filters
Step 6 Select for Enable for Unsigned Messages.
This allows the email gateway to rewrite URLs in signed messages. You must enable URL rewriting to be
able to configure other Message Modification settings and the length of time that messages found to be
non-viral threats stay in the quarantine before being released. This example uses the default retention time of
4 hours.
Step 7 Enter example.com in the Bypass Domain Scanning field.
The email gateway will not modify links to example.com.
Step 8 Select System Generated for the Threat Disclaimer.
The email gateway can insert a disclaimer above the message body to warn the user about the message’s
contents. The following example uses the system generated threat disclaimer.
Figure 97: Outbreak Filters Settings
Step 9 Submit and commit your changes.
Note that the shading shows that the policy is using different settings than the default policy.
At this point, any message that contains an attachment whose file extension is dwg — and whose recipient
matches the recipients defined for the engineering team policy — will bypass the Outbreak Filter scanning
and continue processing. Messages that contain links to the example.com domain will not have their links
modified to redirect through the Cisco Security proxy and will not be considered suspicious.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1315
Example of Mail Policies and Content Filters
Finding Senders or Recipients in Mail Policies
Finding Senders or Recipients in Mail Policies
Use the “Find Policies” button to search for users already defined in policies defined in the Incoming or
Outgoing Mail Policies pages.
For example, typing [email protected] and clicking the Find Policies button will display results showing
which policies contain defined users that will match the policy.
Click the name of the policy to jump to the Edit Policy page to edit the users for that policy.
Note that the default policy will always be shown when you search for any user, because, by definition, if a
sender or recipient does not match any other configured policies, it will always match the default policy.
Managed Exceptions
Using the steps shown in the two examples above, you can begin to create and configure policies on a managed
exception basis. In other words, after evaluating your organization’s needs you can configure policies so that
the majority of messages will be handled by the default policy. You can then create additional “exception”
policies for specific users or user groups, managing the differing policies as needed. In this manner, message
splintering will be minimized and you are less likely to impact system performance from the processing of
each splinter message in the work queue.
You can define policies based on your organizations’ or users’ tolerance for spam, viruses, and policy
enforcement. The following table outlines several example policies. “Aggressive” policies are designed to
minimize the amount of spam and viruses that reach end-users mailboxes. “Conservative” policies are tailored
to avoid false positives and prevent users from missing messages, regardless of policies.
Table 165: Aggressive and Conservative Mail Policy Settings
Aggressive Settings Conservative Settings
Anti-Spam Positively identified spam: Drop Positively identified spam: Quarantine
Suspected spam: Quarantine Suspected spam: Deliver and prepend “ [Suspected Spam]
” to the subject of messages
Marketing mail: Deliver and prepend “
[Marketing] ” to the subject messages Marketing mail: Disabled
Anti-Virus Repaired messages: Deliver Repaired messages: Deliver
Encrypted messages: Drop Encrypted messages: Quarantine
Unscannable messages: Drop Unscannable messages: Quarantine
Infectious messages: Drop Infectious messages: Drop
Virus Filters Enabled, no specific filename extensions or Enabled with specific filename extensions or domains
domains allowed to bypass allowed to bypass
Enable message modification for all messages Enable message modification for unsigned messages
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1316
Example of Mail Policies and Content Filters
Filtering Messages Based on Content
Filtering Messages Based on Content
In this part of the example, you will create three new content filters to be used in the Incoming Mail Policy
table. All of these content filters will be editable by delegated administrators belonging to the Policy
Administration custom user role. You will create the following:
1. “scan_for_confidential”
This filter will scan messages for the string “confidential.” If the string is found, a copy of the message
will be sent to email alias [email protected] , and the message will be sent to the Policy quarantine area.
2. “no_mp3s”
This filter will strip MP3 attachments and notify the recipients that an MP3 file was stripped.
3. “ex_employee”
This content filter will scan for messages sent to a specific envelope recipient address (an ex-employee).
If the message matches, a specific notification message will be sent to the sender of the message and then
the message will be bounced.
After creating the content filters, you will then configure each of the policies (including the default policy)
to enable the specific content filters in differing combinations.
Quarantining Message with “Confidential” in the Subject
The first example content filter contains one condition and two actions.
Procedure
Step 1 Click the Mail Policies tab.
Step 2 Click Incoming Content Filters.
Step 3 Click the Add Filter button.
Step 4 In the Name field, type scan_for_confidential as the name of the new filter.
Filter names can contain ASCII characters, numbers, underscores or dashes. The first character of a content
filter name must be a letter or an underscore.
Step 5 Click the Editable By (Roles) link, select the Policy Administrator and click OK.
Delegated administrators who belong to the Policy Administrator user role will be able to edit this content
filter and use it in their mail policies.
Step 6 In the Description field, type the description. For example: scan all incoming mail for the string ‘confidential’
.
Step 7 Click Add Condition.
Step 8 Select Message Body.
Step 9 Type confidential in the Contains text: field and click OK.
The Add Content Filter page shows the condition added.
Step 10 Click Add Action.
Step 11 Select Send Copy To (Bcc:).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1317
Example of Mail Policies and Content Filters
Stripping MP3 Attachments from Messages
Step 12 In the Email Addresses field, type [email protected] .
Step 13 In the Subject field, type [message matched confidential filter] .
Step 14 Click OK.
The Add Content Filter page shows the action added.
Step 15 Click Add Action.
Step 16 Select Quarantine.
Step 17 In the drop-down menu, select the Policy quarantine area.
Step 18 Click OK.
The Add Content Filter page shows the second action added.
Step 19 Submit and commit your changes.
At this point, the content filter is not enabled for any incoming Mail Policy; in this example, you have only
added a new content filter to the primary list. Because it has not been applied to any policy, no email processing
by the email gateway will be affected by this filter.
Stripping MP3 Attachments from Messages
The second example content filter contains no conditions and one action.
Procedure
Step 1 Click the Add Filter button.
Step 2 In the Name field, type no_mp3s as the name of the new filter.
Step 3 Click the Editable By (Roles) link, select the Policy Administrator and click OK.
Step 4 In the Description field, type the description. For example: strip all MP3 attachments .
Step 5 Click Add Action.
Step 6 Select Strip Attachment by File Info.
Step 7 Select File type is .
Step 8 In the drop-down field, select -- mp3 .
Step 9 Enter a replacement message if desired.
Step 10 Click OK.
Step 11 Submit and commit your changes.
Note It is not necessary to specify a condition when creating a content filter. When no condition is defined,
any actions defined will always apply in the rule. (Specifying no condition is equivalent to using
the true() message filter rule — all messages will be matched if the content filter is applied to a
policy.)
Bouncing Messages Sent to a Former Employee
The third content filter example uses one condition and two actions.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1318
Example of Mail Policies and Content Filters
Applying Individual Content Filters to Different Groups of Recipients
Procedure
Step 1 Click the Add Filter button.
Step 2 In the Name: field, type ex_employee as the name of the new filter.
Step 3 Click the Editable By (Roles) link, select the Policy Administrator and click OK.
Step 4 In the Description: field, type the description. For example: bounce messages intended for Doug
.
Step 5 Click Add Condition.
Step 6 Select Envelope Recipient.
Step 7 For the envelope recipient, select Begins with , and type doug@ .
Step 8 Click OK.
The Content Filters page refreshes to show the condition added. Note that you could create an LDAP directory
containing the email addresses of former employees. As ex-employees are added to that directory, this content
filter would be dynamically updated.
Step 9 Click Add Action.
Step 10 Select Notify.
Step 11 Select the checkbox for Sender and, in the Subject field, type message bounced for ex-employee of
example.com .
Step 12 In the Use template section, select a notification template.
Note Some sections of the content filter rule builder will not appear in the user interface if the resource
has not been preconfigured. For example, content dictionaries, notification templates, and message
disclaimers will not appear as options if they have not been configured previously via the Mail
Policies > Dictionaries page (or the dictionaryconfig command in the CLI). For more
information about creating dictionaries, see Content Dictionaries, on page 643.
Step 13 Click OK.
The Add Content Filters page shows the action added.
Step 14 Click Add Action.
Step 15 Select Bounce (Final Action) and click OK.
You can only specify one final action for a content filter. If you try to attempt to add more than one final
action, the GUI displays an error.
Adding this action may will cause senders of messages to this ex-employee to potentially receive two messages:
one for the notification template, and one for the bounce notification template.
Step 16 Submit and commit your changes.
Applying Individual Content Filters to Different Groups of Recipients
In the examples above, you created three content filters using the Incoming Content Filters pages. The Incoming
Content Filters and Outgoing Content filters pages hold the “primary lists” of all possible content filters that
can be applied to a policy.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1319
Example of Mail Policies and Content Filters
Enabling Content Filters for All Recipients by Default
Figure 98: Incoming Content Filters: Three Filters Created
In this part of the example, you will apply the three new content filters to be used in the Incoming Mail Policy
table.
• The default policy will receive all three content filters.
• The engineering group will not receive the no_mp3s filter.
• The sales group will receive the content filters as the default incoming mail policy.
Enabling Content Filters for All Recipients by Default
Click the links to enable and select content filters for individual policies.
Procedure
Step 1 Click Incoming Mail Policies to return to the Incoming Mail Policy table.
The page is refreshed to show the default policy and the two policies added in Creating a Mail Policy for a
Group of Sender and Recipients, on page 1310. Note that content filtering is disable by default for all policies.
Step 2 Click the link for the Content Filters security service (the Content Filters column) in the default policy row.
Step 3 On the Content Filtering security service page, change the value Content Filtering for Default Policy from
“Disable Content Filters” to “Enable Content Filters (Customize settings).”
The content filters defined in the primary list (which were created in Overview of Content Filters , on page
281 using the Incoming Content Filters pages) are displayed on this page. When you change the value to
“Enable Content Filters (Customize settings),” the checkboxes for each filter change from disabled (greyed
out) to become enabled.
Step 4 Check the Enable checkbox for each content filter.
Step 5 Click Submit.
The table on the Incoming Mail Policies page shows the names of the filters that have been enabled for the
default policy.
Allowing MP3 Attachments for Recipients in Engineering
To disable the “no_mp3s” content filters for the “engineering” policy:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1320
Example of Mail Policies and Content Filters
Notes on Configuring Content Filters in the GUI
Procedure
Step 1 Click the link for the Content Filters security service (the Content Filters column) in the engineering team
policy row.
Step 2 On the Content Filtering security service page, change the value for Content Filtering for Policy: Engineering
from “Enable Content Filtering (Inherit default policy settings)” to “Enable Content Filtering (Customize
settings).”
Because this policy was using the default values, when you change the value from “Use Default Settings” to
“Yes,” the checkboxes for each filter change from disabled (greyed out) to become enabled.
Step 3 Deselect the checkbox for the “no_mp3s” filter.
Step 4 Click Submit.
The table on the Incoming Mail Policies page shows the names of the filters that have been enabled for the
engineering policy.
Step 5 Commit your changes.
What to do next
At this point, incoming messages that match the user list for the engineering policy will not have MP3
attachments stripped; however, all other incoming messages will have MP3 attachments stripped.
Notes on Configuring Content Filters in the GUI
• It is not necessary to specify a condition when creating a content filter. When no action is defined, any
actions defined will always apply in the rule. (Specifying no action is equivalent to using the true()
message filter rule — all messages will be matched if the content filter is applied to a policy.)
• If you do not assign a custom user role to a content filter, the content filter is public and can be used by
any delegated administrator for their mail policies. See Distributing Administrative Tasks, on page 977
for more information on delegated administrators and content filters.
• Administrators and operators can view and edit all content filters on an email gateway, even when the
content filters are assigned to custom user roles.
• When entering text for filter rules and actions, the following meta characters have special meaning in
regular expression matching: . ^ $ * + ? { [ ] \ | ( )
If you do not wish to use regular expression you should use a '\' (backslash) to escape any of these
characters. For example: "\*Warning\*"
• When you define more than one Condition for a content filter, you can define whether all of the defined
actions (that is, a logical AND) or any of the defined actions (logical OR) need to apply in order for the
content filter to be considered a match.
• You can test message splintering and content filters by creating “benign” content filters. For example,
it is possible to create a content filter whose only action is “deliver.” This content filter will not affect
mail processing; however, you can use this filter to test how the mail policy processing affects other
elements in the system (for example, the mail logs).
• Conversely, using the “primary list” concept of the Incoming or Outgoing Content Filters, it is possible
to create very powerful, wide-sweeping content filters that will immediately affect message processing
for all mail handled by the email gateway. The process for this is to:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1321
Example of Mail Policies and Content Filters
Example of Mail Policies and Content Filters
• Use the Incoming or Outgoing Content Filters page to create a new content filter whose order is 1.
• Use the Incoming or Outgoing Mail Policies page to enable the new content filter for the default
policy.
• Enable the content filter for all remaining policies.
• The Bcc: and Quarantine actions available in Content Filters can help you determine the retention settings
of quarantines you create. (See Policy, Virus, and Outbreak Quarantines, on page 927) You can create
filters that would simulate mail flow into and out of your policy quarantines so that messages are not
released too quickly from the system (that is, the quarantine areas do not fill their allotted disk space too
quickly).
• Because it uses the same settings as the Scan Behavior page or the scanconfig command, the “Entire
Message” condition does not scan a message’s headers; choosing the “Entire Message” will scan only
the message body and attachments. Use the “Subject” or “Header” conditions to search for specific header
information.
• Configuring users by LDAP query will only appear in the GUI if you have LDAP servers configured on
the email gateway (that is, you have configured the email gateway to query specific LDAP servers with
specific strings using the ldapconfig command).
• Some sections of the content filter rule builder will not appear in the GUI if the resource has not been
preconfigured. For example, notification templates and message disclaimers will not appear as options
if they have not been configured previously using the Text Resources page or the textconfig command
in the CLI.
• Content filters features will recognize, can contain, and/or scan for text in the following character
encodings:
• Unicode (UTF-8)
• Unicode (UTF-16)
• Western European/Latin-1 (ISO 8859-1)
• Western European/Latin-1 (Windows CP1252)
• Traditional Chinese (Big 5)
• Simplified Chinese (GB 2312)
• Simplified Chinese (HZ GB 2312)
• Korean (ISO 2022-KR)
• Korean (KS-C-5601/EUC-KR)
• Japanese (Shift-JIS (X0123))
• Japanese (ISO-2022-JP)
• Japanese (EUC)
You can mix and match multiple character sets within a single content filter. Refer to your web browser’s
documentation for help displaying and entering text in multiple character encodings. Most browsers can render
multiple character sets simultaneously.
Figure 99: Multiple Character Sets in a Content Filter
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1322
Example of Mail Policies and Content Filters
Example of Mail Policies and Content Filters
• On the Incoming or Outgoing Content Filters summary pages, use the links for “Description,” “Rules,”
and “Policies” to change the view presented for the content filters:
• The Description view shows the text you entered in the description field for each content filter.
(This is the default view.)
• The Rules view shows the rules and regular expressions build by the rule builder page.
• The Policies shows the policies for which each content filter is enabled.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1323
Example of Mail Policies and Content Filters
Example of Mail Policies and Content Filters
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1324
APPENDIX D
Firewall Information
This chapter contains the following sections:
• Firewall Information, on page 1325
• Protecting Email Gateway from Network Attacks, on page 1329
Firewall Information
The following table lists the possible ports that may need to be opened for proper operation of Cisco Secure
Email Gateway (these are the default values).
Table 166: Firewall Ports
Default Protocol In/Out Hostname Purpose
Port
20/21 TCP In or out AsyncOS IPs, FTP server FTP for aggregation of log files.
Data ports TCP 1024 and higher
must also all be open.
For more information, search for
FTP port information in the
Knowledge Base. See
Knowledge Base, on page 17.
22 TCP In AsyncOS IPs SSH access to the CLI,
aggregation of log files.
22 TCP Out SSH Server SSH aggregation of log files.
22 TCP Out SCP server SCP push to log server.
25 TCP Out Any SMTP to send email.
25 TCP In AsyncOS IPs SMTP to receive bounced email
or if injecting email from outside
firewall.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1325
Firewall Information
Firewall Information
53 UDP/TCP Out DNS servers DNS if configured to use Internet
root servers or other DNS servers
outside the firewall. Also for
SenderBase queries.
80 HTTP In AsyncOS IPs HTTP access to the GUI for
system monitoring.
80 HTTP Out downloads.ironport.com and McAfee definitions.
80 HTTP Out updates.ironport.com AsyncOS upgradesand McAfee
definitions.
80 HTTP Out TAXII servers Used to allow your email
gateway to consume external
threat feeds.
82 HTTP In AsyncOS IPs Used for viewing the spam
quarantine.
83 HTTPS In AsyncOS IPs Used for viewing the spam
quarantine.
110 TCP Out POP server POP authentication for end users
for spam quarantine.
123 UDP In & Out NTP server NTP if time servers are outside
firewall.
143 TCP Out IMAP server IMAP authentication for end
users for spam quarantine.
161 UDP In AsyncOS IPs SNMP Queries.
162 UDP Out Management station SNMP Traps.
389 or LDAP Out LDAP servers LDAP if LDAP directory servers
are outside firewall. LDAP
3268
authentication for Cisco Spam
Quarantine.
636 or LDAPS Out LDAPS LDAPS — ActiveDirectory’s
3269 global catalog server (uses SSL).
443 TCP In AsyncOS IPs Secure HTTP ( https ) access to
the GUI for system monitoring.
443 TCP Out res.cisco.com Verify the latest files for the
update server.
443 TCP Out update-manifests.ironport.com Obtain the list of the latest files
from the update server (for
physical hardware email
gateways.)
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1326
Firewall Information
Firewall Information
443 TCP Out update-manifests.sco.cisco.com Obtain the list of the latest files
from the update server (for
virtual email gateways.)
443 TCP Out serviceconfig.talos.cisco.com Cisco Talos Intelligence Services
- to obtain IP reputation, URL
grpc.talos.cisco.com
reputation and category, and to
email-sender-ip-rep-grpc.talos.cisco.com send Service Logs details.
For IP -based firewall:
146.112.62.0/24
146.112.63.0/24
146.112.255.0/24
146.112.59.0/24
2a04:e4c7:ffff::/48
2a04:e4c7:fffe::/48
443 TCP Out kinesis.us-west-2.amazonaws.com Register and send header details
to Cisco Advanced Phishing
sensor-provisioner.ep.prod
Protection cloud service.
.agari.com
houston.sensor.prod.agari.com
443 TCP Out As configured in Security If configured, the port for access
Services > File Reputation and to cloud services for obtaining
Analysis, Advanced Settings file reputation. The default port
for File Reputation section, is 32137. For file analysis
Cloud Server Pool parameter. services, see port 443.
443 TCP Out As configured in Security Access to cloud services for file
Services > File Reputation and analysis. For file reputation
Analysis, Advanced Settings services, see port 443 or 32137.
for File Analysis section.
443 TCP In & Out As configured in Security Access to AMP for Endpoints
Services > File Reputation and console servers.
Analysis, Advanced Settings
for File Reputation section,
AMP for Endpoints Console
Integration parameter.
api.amp.sourcefire.com
api.eu.amp.sourcefire.com
api.apjc.amp.sourcefire.com
api.amp.cisco.com
api.eu.amp.cisco.com
api.apjc.amp.cisco.com
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1327
Firewall Information
Firewall Information
443 TCP In & Out outlook.office365.com Access to Office 365 services for
login.microsoftonline.com. mailbox auto remediation.
443 TCP In & Out Hostname of the Microsoft Access to Microsoft On-premise
On-premise exchange server exchange servers for remedating
messages from the mailbox.
443 TCP Out aggregator.cisco.com Access to the Cisco Aggregator
server.
443 HTTPS Out logapi.ces.cisco.com To upload the debug logs that are
collected by Cisco TAC.
443 HTTPS Out TAXII servers Used to allow your email
gateway to consume external
threat feeds.
443 HTTPS In and Out api-sse.cisco.com Used to register your email
gateway with Cisco SecureX or
Cisco Threat Response.
443 HTTPS In and Out api.eu.sse.itd.cisco.com Used to register your email
gateway with Cisco SecureX or
Cisco Threat Response.
443 HTTPS In and Out api.apj.sse.itd.cisco.com Used to register your email
gateway with Cisco SecureX or
Cisco Threat Response.
443 HTTPS In and Out est.sco.cisco.com Used to download a certificate to
verify whether your email
gateway is accessing a verified
site when registering to Cisco
SecureX or Cisco Threat
Response.
443 HTTPS In and Out AsyncOS IPs HTTPS access to the GUI using
trailblazerconfig CLI
command.
514 UDP/TCP Out Syslog server Syslog logging.
628 TCP In & In AsyncOS IPs QMQP if injecting email from
outside firewall.
990 TCP/FTP Out support-ftp.cisco.com To upload the debug logs that are
collected by Cisco TAC.
1024 and — — — See information above for Port
higher 21 (FTP.)
2222 CCS In & In AsyncOS IPs Cluster Communication Service
(for Centralized Management).
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1328
Firewall Information
Protecting Email Gateway from Network Attacks
TCP Out AsyncOS IPs Cisco Spam Quarantine.
7025 TCP In and out AsyncOS IPs Pass policy, virus, and outbreak
quarantine data between Cisco
Secure Email Gateways and
Cisco Secure Manager Email and
Web Gateways when this feature
is centralized.
6080 HTTP In or Out AsyncOS IPs Access to API ports for HTTP
Server
6443 HTTPS In or Out AsyncOS IPs Access to API ports for HTTPS
Server
Protecting Email Gateway from Network Attacks
Make sure that you perform the following prerequisites to protect your email gateway from network attacks:
• Do not expose port 22 (SSH) to your email gateway external IP address.
• Enable only specific IP addresses to manage your email gateway using the web interface and CLI
configuration settings.
• [If required] Enable Host Header protection using the adminaccessconfig CLI command.
• Enable Cross Scripting protection using the adminaccessconfig CLI command.
• Do not configure a Relay rule on a public listener.
Note If you require a relay rule on an external listener, configure ‘SMTP AUTH’ on
a normal public listener.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1329
Firewall Information
Protecting Email Gateway from Network Attacks
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1330
APPENDIX E
End User License Agreement
This appendix contains the following sections:
• Cisco Systems End User License Agreement , on page 1331
• Supplemental End User License Agreement for Cisco Systems Content Security Software , on page 1337
Cisco Systems End User License Agreement
IMPORTANT: PLEASE READ THIS END USER LICENSE AGREEMENT CAREFULLY. IT IS
VERY IMPORTANT THAT YOU CHECK THAT YOU ARE PURCHASING CISCO SOFTWARE
OR EQUIPMENT FROM AN APPROVED SOURCE AND THAT YOU, OR THE ENTITY YOU
REPRESENT (COLLECTIVELY, THE "CUSTOMER") HAVE BEEN REGISTERED AS THE END
USER FOR THE PURPOSES OF THIS CISCO END USER LICENSE AGREEMENT. IF YOU ARE
NOT REGISTERED AS THE END USER YOU HAVE NO LICENSE TO USE THE SOFTWARE
AND THE LIMITED WARRANTY IN THIS END USER LICENSE AGREEMENT DOES NOT
APPLY. ASSUMING YOU HAVE PURCHASED FROM AN APPROVED SOURCE, DOWNLOADING,
INSTALLING OR USING CISCO OR CISCO-SUPPLIED SOFTWARE CONSTITUTES
ACCEPTANCE OF THIS AGREEMENT.
CISCO SYSTEMS, INC. OR ITS SUBSIDIARY LICENSING THE SOFTWARE INSTEAD OF CISCO
SYSTEMS, INC. ("CISCO") IS WILLING TO LICENSE THIS SOFTWARE TO YOU ONLY UPON THE
CONDITION THAT YOU PURCHASED THE SOFTWARE FROM AN APPROVED SOURCE AND
THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS END USER LICENSE AGREEMENT
PLUS ANY ADDITIONAL LIMITATIONS ON THE LICENSE SET FORTH IN A SUPPLEMENTAL
LICENSE AGREEMENT ACCOMPANYING THE PRODUCT OR AVAILABLE AT THE TIME OF
YOUR ORDER (COLLECTIVELY THE "AGREEMENT"). TO THE EXTENT OF ANY CONFLICT
BETWEEN THE TERMS OF THIS END USER LICENSE AGREEMENT AND ANY SUPPLEMENTAL
LICENSE AGREEMENT, THE SUPPLEMENTAL LICENSE AGREEMENT SHALL APPLY. BY
DOWNLOADING, INSTALLING, OR USING THE SOFTWARE, YOU ARE REPRESENTING THAT
YOU PURCHASED THE SOFTWARE FROM AN APPROVED SOURCE AND BINDING YOURSELF
TO THE AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THE AGREEMENT,
THEN CISCO IS UNWILLING TO LICENSE THE SOFTWARE TO YOU AND (A) YOU MAY NOT
DOWNLOAD, INSTALL OR USE THE SOFTWARE, AND (B) YOU MAY RETURN THE SOFTWARE
(INCLUDING ANY UNOPENED CD PACKAGE AND ANY WRITTEN MATERIALS) FOR A FULL
REFUND, OR, IF THE SOFTWARE AND WRITTEN MATERIALS ARE SUPPLIED AS PART OF
ANOTHER PRODUCT, YOU MAY RETURN THE ENTIRE PRODUCT FOR A FULL REFUND. YOUR
RIGHT TO RETURN AND REFUND EXPIRES 30 DAYS AFTER PURCHASE FROM AN APPROVED
SOURCE, AND APPLIES ONLY IF YOU ARE THE ORIGINAL AND REGISTERED END USER
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1331
End User License Agreement
End User License Agreement
PURCHASER. FOR THE PURPOSES OF THIS END USER LICENSE AGREEMENT, AN "APPROVED
SOURCE" MEANS (A) CISCO; OR (B) A DISTRIBUTOR OR SYSTEMS INTEGRATOR AUTHORIZED
BY CISCO TO DISTRIBUTE / SELL CISCO EQUIPMENT, SOFTWARE AND SERVICES WITHIN
YOUR TERRITORY TO END USERS; OR (C) A RESELLER AUTHORIZED BY ANY SUCH
DISTRIBUTOR OR SYSTEMS INTEGRATOR IN ACCORDANCE WITH THE TERMS OF THE
DISTRIBUTOR'S AGREEMENT WITH CISCO TO DISTRIBUTE / SELL THE CISCO EQUIPMENT,
SOFTWARE AND SERVICES WITHIN YOUR TERRITORY TO END USERS.
THE FOLLOWING TERMS OF THE AGREEMENT GOVERN CUSTOMER'S USE OF THE SOFTWARE
(DEFINED BELOW), EXCEPT TO THE EXTENT: (A) THERE IS A SEPARATE SIGNED CONTRACT
BETWEEN CUSTOMER AND CISCO GOVERNING CUSTOMER'S USE OF THE SOFTWARE, OR (B) THE
SOFTWARE INCLUDES A SEPARATE "CLICK-ACCEPT" LICENSE AGREEMENT OR THIRD PARTY
LICENSE AGREEMENT AS PART OF THE INSTALLATION OR DOWNLOAD PROCESS GOVERNING
CUSTOMER'S USE OF THE SOFTWARE. TO THE EXTENT OF A CONFLICT BETWEEN THE PROVISIONS
OF THE FOREGOING DOCUMENTS, THE ORDER OF PRECEDENCE SHALL BE (1)THE SIGNED
CONTRACT, (2) THE CLICK-ACCEPT AGREEMENT OR THIRD PARTY LICENSE AGREEMENT, AND
(3) THE AGREEMENT. FOR PURPOSES OF THE AGREEMENT, "SOFTWARE" SHALL MEAN COMPUTER
PROGRAMS, INCLUDING FIRMWARE AND COMPUTER PROGRAMS EMBEDDED IN CISCO
EQUIPMENT, AS PROVIDED TO CUSTOMER BY AN APPROVED SOURCE, AND ANY UPGRADES,
UPDATES, BUG FIXES OR MODIFIED VERSIONS THERETO (COLLECTIVELY, "UPGRADES"), ANY
OF THE SAME WHICH HAS BEEN RELICENSED UNDER THE CISCO SOFTWARE TRANSFER AND
RE-LICENSING POLICY (AS MAY BE AMENDED BY CISCO FROM TIME TO TIME) OR BACKUP COPIES
OF ANY OF THE FOREGOING.
License. Conditioned upon compliance with the terms and conditions of the Agreement, Cisco grants to
Customer a nonexclusive and nontransferable license to use for Customer's internal business purposes the
Software and the Documentation for which Customer has paid the required license fees to an Approved Source.
"Documentation" means written information (whether contained in user or technical manuals, training materials,
specifications or otherwise) pertaining to the Software and made available by an Approved Source with the
Software in any manner (including on CD-Rom, or on-line). In order to use the Software, Customer may be
required to input a registration number or product authorization key and register Customer's copy of the
Software online at Cisco's website to obtain the necessary license key or license file.
Customer's license to use the Software shall be limited to, and Customer shall not use the Software in excess
of, a single hardware chassis or card or such other limitations as are set forth in the applicable Supplemental
License Agreement or in the applicable purchase order which has been accepted by an Approved Source and
for which Customer has paid to an Approved Source the required license fee (the "Purchase Order").
Unless otherwise expressly provided in the Documentation or any applicable Supplemental License Agreement,
Customer shall use the Software solely as embedded in, for execution on, or (where the applicable
Documentation permits installation on non-Cisco equipment) for communication with Cisco equipment owned
or leased by Customer and used for Customer's internal business purposes. No other licenses are granted by
implication, estoppel or otherwise.
For evaluation or beta copies for which Cisco does not charge a license fee, the above requirement to pay
license fees does not apply.
General Limitations. This is a license, not a transfer of title, to the Software and Documentation, and Cisco
retains ownership of all copies of the Software and Documentation. Customer acknowledges that the Software
and Documentation contain trade secrets of Cisco or its suppliers or licensors, including but not limited to the
specific internal design and structure of individual programs and associated interface information. Except as
otherwise expressly provided under the Agreement, Customer shall only use the Software in connection with
the use of Cisco equipment purchased by the Customer from an Approved Source and Customer shall have
no right, and Customer specifically agrees not to:
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1332
End User License Agreement
End User License Agreement
(i) transfer, assign or sublicense its license rights to any other person or entity (other than in compliance with
any Cisco relicensing/transfer policy then in force), or use the Software on Cisco equipment not purchased
by the Customer from an Approved Source or on secondhand Cisco equipment, and Customer acknowledges
that any attempted transfer, assignment, sublicense or use shall be void;
(ii) make error corrections to or otherwise modify or adapt the Software or create derivative works based upon
the Software, or permit third parties to do the same;
(iii) reverse engineer or decompile, decrypt, disassemble or otherwise reduce the Software to human-readable
form, except to the extent otherwise expressly permitted under applicable law notwithstanding this restriction
or except to the extent that Cisco is legally required to permit such specific activity pursuant to any applicable
open source license;
(iv) publish any results of benchmark tests run on the Software;
(v) use or permit the Software to be used to perform services for third parties, whether on a service bureau or
time sharing basis or otherwise, without the express written authorization of Cisco; or
(vi) disclose, provide, or otherwise make available trade secrets contained within the Software and
Documentation in any form to any third party without the prior written consent of Cisco. Customer shall
implement reasonable security measures to protect such trade secrets.
To the extent required by applicable law, and at Customer's written request, Cisco shall provide Customer
with the interface information needed to achieve interoperability between the Software and another
independently created program, on payment of Cisco's applicable fee, if any. Customer shall observe strict
obligations of confidentiality with respect to such information and shall use such information in compliance
with any applicable terms and conditions upon which Cisco makes such information available.
Software, Upgrades and Additional Copies. NOTWITHSTANDING ANY OTHER PROVISION OF THE
AGREEMENT: (1) CUSTOMER HAS NO LICENSE OR RIGHT TO MAKE OR USE ANY ADDITIONAL
COPIES OR UPGRADES UNLESS CUSTOMER, AT THE TIME OF MAKING OR ACQUIRING SUCH
COPY OR UPGRADE, ALREADY HOLDS A VALID LICENSE TO THE ORIGINAL SOFTWARE AND
HAS PAID THE APPLICABLE FEE TO AN APPROVED SOURCE FOR THE UPGRADE OR
ADDITIONAL COPIES; (2) USE OF UPGRADES IS LIMITED TO CISCO EQUIPMENT SUPPLIED BY
AN APPROVED SOURCE FOR WHICH CUSTOMER IS THE ORIGINAL END USER PURCHASER
OR LESSEE OR OTHERWISE HOLDS A VALID LICENSE TO USE THE SOFTWARE WHICH IS
BEING UPGRADED; AND (3) THE MAKING AND USE OF ADDITIONAL COPIES IS LIMITED TO
NECESSARY BACKUP PURPOSES ONLY.
Proprietary Notices. Customer agrees to maintain and reproduce all copyright, proprietary, and other notices
on all copies, in any form, of the Software in the same form and manner that such copyright and other
proprietary notices are included on the Software. Except as expressly authorized in the Agreement, Customer
shall not make any copies or duplicates of any Software without the prior written permission of Cisco.
Term and Termination. The Agreement and the license granted herein shall remain effective until terminated.
Customer may terminate the Agreement and the license at any time by destroying all copies of Software and
any Documentation. Customer's rights under the Agreement will terminate immediately without notice from
Cisco if Customer fails to comply with any provision of the Agreement. Upon termination, Customer shall
destroy all copies of Software and Documentation in its possession or control. All confidentiality obligations
of Customer, all restrictions and limitations imposed on the Customer under the section titled "General
Limitations" and all limitations of liability and disclaimers and restrictions of warranty shall survive termination
of this Agreement. In addition, the provisions of the sections titled "U.S. Government End User Purchasers"
and "General Terms Applicable to the Limited Warranty Statement and End User License Agreement" shall
survive termination of the Agreement.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1333
End User License Agreement
End User License Agreement
Customer Records. Customer grants to Cisco and its independent accountants the right to examine Customer's
books, records and accounts during Customer's normal business hours to verify compliance with this Agreement.
In the event such audit discloses non-compliance with this Agreement, Customer shall promptly pay to Cisco
the appropriate license fees, plus the reasonable cost of conducting the audit.
Export, Re-Export, Transfer and Use Controls. The Software, Documentation and technology or direct products
thereof (hereafter referred to as Software and Technology), supplied by Cisco under the Agreement are subject
to export controls under the laws and regulations of the United States (U.S.) and any other applicable countries'
laws and regulations. Customer shall comply with such laws and regulations governing export, re-export,
transfer and use of Cisco Software and Technology and will obtain all required U.S. and local authorizations,
permits, or licenses. Cisco and Customer each agree to provide the other information, support documents,
and assistance as may reasonably be required by the other in connection with securing authorizations or
licenses. Information regarding compliance with export, re-export, transfer and use may be located at the
following URL:
https://www.cisco.com/web/about/doing_business/legal/global_export_trade/general_export/contract_
compliance.html
U.S. Government End User Purchasers. The Software and Documentation qualify as "commercial items," as
that term is defined at Federal Acquisition Regulation ("FAR") (48 C.F.R.) 2.101, consisting of "commercial
computer software" and "commercial computer software documentation" as such terms are used in FAR
12.212. Consistent with FAR 12.212 and DoD FAR Supp. 227.7202-1 through 227.7202-4, and notwithstanding
any other FAR or other contractual clause to the contrary in any agreement into which the Agreement may
be incorporated, Customer may provide to Government end user or, if the Agreement is direct, Government
end user will acquire, the Software and Documentation with only those rights set forth in the Agreement. Use
of either the Software or Documentation or both constitutes agreement by the Government that the Software
and Documentation are "commercial computer software" and "commercial computer software documentation,"
and constitutes acceptance of the rights and restrictions herein.
Identified Components; Additional Terms. The Software may contain or be delivered with one or more
components, which may include third-party components, identified by Cisco in the Documentation, readme.txt
file, third-party click-accept or elsewhere (e.g. on https://www.cisco.com/ ) (the "Identified Component(s)")
as being subject to different license agreement terms, disclaimers of warranties, limited warranties or other
terms and conditions (collectively, "Additional Terms") than those set forth herein. You agree to the applicable
Additional Terms for any such Identified Component(s)."
Limited Warranty
Subject to the limitations and conditions set forth herein, Cisco warrants that commencing from the date of
shipment to Customer (but in case of resale by an Approved Source other than Cisco, commencing not more
than ninety (90) days after original shipment by Cisco), and continuing for a period of the longer of (a) ninety
(90) days or (b) the warranty period (if any) expressly set forth as applicable specifically to software in the
warranty card accompanying the product of which the Software is a part (the "Product") (if any): (a) the media
on which the Software is furnished will be free of defects in materials and workmanship under normal use;
and (b) the Software substantially conforms to the Documentation. The date of shipment of a Product by Cisco
is set forth on the packaging material in which the Product is shipped. Except for the foregoing, the Software
is provided "AS IS". This limited warranty extends only to the Software purchased from an Approved Source
by a Customer who is the first registered end user. Customer's sole and exclusive remedy and the entire liability
of Cisco and its suppliers under this limited warranty will be (i) replacement of defective media and/or (ii) at
Cisco's option, repair, replacement, or refund of the purchase price of the Software, in both cases subject to
the condition that any error or defect constituting a breach of this limited warranty is reported to the Approved
Source supplying the Software to Customer, within the warranty period. Cisco or the Approved Source
supplying the Software to Customer may, at its option, require return of the Software and/or Documentation
as a condition to the remedy. In no event does Cisco warrant that the Software is error free or that Customer
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1334
End User License Agreement
End User License Agreement
will be able to operate the Software without problems or interruptions. In addition, due to the continual
development of new techniques for intruding upon and attacking networks, Cisco does not warrant that the
Software or any equipment, system or network on which the Software is used will be free of vulnerability to
intrusion or attack.
Restrictions. This warranty does not apply if the Software, Product or any other equipment upon which the
Software is authorized to be used (a) has been altered, except by Cisco or its authorized representative, (b)
has not been installed, operated, repaired, or maintained in accordance with instructions supplied by Cisco,
(c) has been subjected to abnormal physical or electrical stress, abnormal environmental conditions, misuse,
negligence, or accident; or (d) is licensed for beta, evaluation, testing or demonstration purposes. The Software
warranty also does not apply to (e) any temporary Software modules; (f) any Software not posted on Cisco's
Software Center; (g) any Software that Cisco expressly provides on an "AS IS" basis on Cisco's Software
Center; (h) any Software for which an Approved Source does not receive a license fee; and (i) Software
supplied by any third party which is not an Approved Source.
DISCLAIMER OF WARRANTY
EXCEPT AS SPECIFIED IN THIS WARRANTY SECTION, ALL EXPRESS OR IMPLIED
CONDITIONS, REPRESENTATIONS, AND WARRANTIES INCLUDING, WITHOUT LIMITATION,
ANY IMPLIED WARRANTY OR CONDITION OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, NON-INFRINGEMENT, SATISFACTORY QUALITY,
NON-INTERFERENCE, ACCURACY OF INFORMATIONAL CONTENT, OR ARISING FROM A
COURSE OF DEALING, LAW, USAGE, OR TRADE PRACTICE, ARE HEREBY EXCLUDED TO
THE EXTENT ALLOWED BY APPLICABLE LAW AND ARE EXPRESSLY DISCLAIMED BY
CISCO, ITS SUPPLIERS AND LICENSORS. TO THE EXTENT THAT ANY OF THE SAME
CANNOT BE EXCLUDED, SUCH IMPLIED CONDITION, REPRESENTATION AND/OR
WARRANTY IS LIMITED IN DURATION TO THE EXPRESS WARRANTY PERIOD REFERRED
TO IN THE "LIMITED WARRANTY" SECTION ABOVE. BECAUSE SOME STATES OR
JURISDICTIONS DO NOT ALLOW LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY
LASTS, THE ABOVE LIMITATION MAY NOT APPLY IN SUCH STATES. THIS WARRANTY
GIVES CUSTOMER SPECIFIC LEGAL RIGHTS, AND CUSTOMER MAY ALSO HAVE OTHER
RIGHTS WHICH VARY FROM JURISDICTION TO JURISDICTION. This disclaimer and exclusion
shall apply even if the express warranty set forth above fails of its essential purpose.
Disclaimer of Liabilities - Limitation of Liability. IF YOU ACQUIRED THE SOFTWARE IN THE UNITED
STATES, LATIN AMERICA, CANADA, JAPAN OR THE CARIBBEAN, NOTWITHSTANDING
ANYTHING ELSE IN THE AGREEMENT TO THE CONTRARY, ALL LIABILITY OF CISCO, ITS
AFFILIATES, OFFICERS, DIRECTORS, EMPLOYEES, AGENTS, SUPPLIERS AND LICENSORS
COLLECTIVELY, TO CUSTOMER, WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE),
BREACH OF WARRANTY OR OTHERWISE, SHALL NOT EXCEED THE PRICE PAID BY CUSTOMER
TO ANY APPROVED SOURCE FOR THE SOFTWARE THAT GAVE RISE TO THE CLAIM OR IF THE
SOFTWARE IS PART OF ANOTHER PRODUCT, THE PRICE PAID FOR SUCH OTHER PRODUCT.
THIS LIMITATION OF LIABILITY FOR SOFTWARE IS CUMULATIVE AND NOT PER INCIDENT
(I.E. THE EXISTENCE OF TWO OR MORE CLAIMS WILL NOT ENLARGE THIS LIMIT).
IF YOU ACQUIRED THE SOFTWARE IN EUROPE, THE MIDDLE EAST, AFRICA, ASIA OR OCEANIA,
NOTWITHSTANDING ANYTHING ELSE IN THE AGREEMENT TO THE CONTRARY, ALL LIABILITY
OF CISCO, ITS AFFILIATES, OFFICERS, DIRECTORS, EMPLOYEES, AGENTS, SUPPLIERS AND
LICENSORS COLLECTIVELY, TO CUSTOMER, WHETHER IN CONTRACT, TORT (INCLUDING
NEGLIGENCE), BREACH OF WARRANTY OR OTHERWISE, SHALL NOT EXCEED THE PRICE
PAID BY CUSTOMER TO CISCO FOR THE SOFTWARE THAT GAVE RISE TO THE CLAIM OR IF
THE SOFTWARE IS PART OF ANOTHER PRODUCT, THE PRICE PAID FOR SUCH OTHER PRODUCT.
THIS LIMITATION OF LIABILITY FOR SOFTWARE IS CUMULATIVE AND NOT PER INCIDENT
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1335
End User License Agreement
End User License Agreement
(I.E. THE EXISTENCE OF TWO OR MORE CLAIMS WILL NOT ENLARGE THIS LIMIT). NOTHING
IN THE AGREEMENT SHALL LIMIT (I) THE LIABILITY OF CISCO, ITS AFFILIATES, OFFICERS,
DIRECTORS, EMPLOYEES, AGENTS, SUPPLIERS AND LICENSORS TO CUSTOMER FOR PERSONAL
INJURY OR DEATH CAUSED BY THEIR NEGLIGENCE, (II) CISCO'S LIABILITY FOR FRAUDULENT
MISREPRESENTATION, OR (III) ANY LIABILITY OF CISCO WHICH CANNOT BE EXCLUDED
UNDER APPLICABLE LAW.
Disclaimer of Liabilities - Waiver of Consequential Damages and Other Losses. IF YOU ACQUIRED THE
SOFTWARE IN THE UNITED STATES, LATIN AMERICA, THE CARIBBEAN OR CANADA,
REGARDLESS OF WHETHER ANY REMEDY SET FORTH HEREIN FAILS OF ITS ESSENTIAL
PURPOSE OR OTHERWISE, IN NO EVENT WILL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY
LOST REVENUE, PROFIT, OR LOST OR DAMAGED DATA, BUSINESS INTERRUPTION, LOSS OF
CAPITAL, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE DAMAGES
HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY OR WHETHER ARISING
OUT OF THE USE OF OR INABILITY TO USE SOFTWARE OR OTHERWISE AND EVEN IF CISCO
OR ITS SUPPLIERS OR LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES. BECAUSE SOME STATES OR JURISDICTIONS DO NOT ALLOW LIMITATION OR
EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY
NOT APPLY TO YOU.
IF YOU ACQUIRED THE SOFTWARE IN JAPAN, EXCEPT FOR LIABILITY ARISING OUT OF OR
IN CONNECTION WITH DEATH OR PERSONAL INJURY, FRAUDULENT MISREPRESENTATION,
AND REGARDLESS OF WHETHER ANY REMEDY SET FORTH HEREIN FAILS OF ITS ESSENTIAL
PURPOSE OR OTHERWISE, IN NO EVENT WILL CISCO, ITS AFFILIATES, OFFICERS, DIRECTORS,
EMPLOYEES, AGENTS, SUPPLIERS AND LICENSORS BE LIABLE FOR ANY LOST REVENUE,
PROFIT, OR LOST OR DAMAGED DATA, BUSINESS INTERRUPTION, LOSS OF CAPITAL, OR FOR
SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE DAMAGES HOWEVER
CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY OR WHETHER ARISING OUT OF
THE USE OF OR INABILITY TO USE SOFTWARE OR OTHERWISE AND EVEN IF CISCO OR ANY
APPROVED SOURCE OR THEIR SUPPLIERS OR LICENSORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
IF YOU ACQUIRED THE SOFTWARE IN EUROPE, THE MIDDLE EAST, AFRICA, ASIA OR OCEANIA,
IN NO EVENT WILL CISCO, ITS AFFILIATES, OFFICERS, DIRECTORS, EMPLOYEES, AGENTS,
SUPPLIERS AND LICENSORS, BE LIABLE FOR ANY LOST REVENUE, LOST PROFIT, OR LOST
OR DAMAGED DATA, BUSINESS INTERRUPTION, LOSS OF CAPITAL, OR FOR SPECIAL, INDIRECT,
CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE DAMAGES, HOWSOEVER ARISING, INCLUDING,
WITHOUT LIMITATION, IN CONTRACT, TORT (INCLUDING NEGLIGENCE) OR WHETHER ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF, IN EACH CASE, CISCO,
ITS AFFILIATES, OFFICERS, DIRECTORS, EMPLOYEES, AGENTS, SUPPLIERS AND LICENSORS,
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES OR
JURISDICTIONS DO NOT ALLOW LIMITATION OR EXCLUSION OF CONSEQUENTIAL OR
INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT FULLY APPLY TO YOU. THE
FOREGOING EXCLUSION SHALL NOT APPLY TO ANY LIABILITY ARISING OUT OF OR IN
CONNECTION WITH: (I) DEATH OR PERSONAL INJURY, (II) FRAUDULENT MISREPRESENTATION,
OR (III) CISCO'S LIABILITY IN CONNECTION WITH ANY TERMS THAT CANNOT BE EXCLUDED
UNDER APPLICABLE LAW.
Customer acknowledges and agrees that Cisco has set its prices and entered into the Agreement in reliance
upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an
allocation of risk between the parties (including the risk that a contract remedy may fail of its essential purpose
and cause consequential loss), and that the same form an essential basis of the bargain between the parties.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1336
End User License Agreement
Supplemental End User License Agreement for Cisco Systems Content Security Software
Controlling Law, Jurisdiction. If you acquired, by reference to the address on the purchase order accepted by
the Approved Source, the Software in the United States, Latin America, or the Caribbean, the Agreement and
warranties ("Warranties") are controlled by and construed under the laws of the State of California, United
States of America, notwithstanding any conflicts of law provisions; and the state and federal courts of California
shall have exclusive jurisdiction over any claim arising under the Agreement or Warranties. If you acquired
the Software in Canada, unless expressly prohibited by local law, the Agreement and Warranties are controlled
by and construed under the laws of the Province of Ontario, Canada, notwithstanding any conflicts of law
provisions; and the courts of the Province of Ontario shall have exclusive jurisdiction over any claim arising
under the Agreement or Warranties. If you acquired the Software in Europe, the Middle East, Africa, Asia or
Oceania (excluding Australia), unless expressly prohibited by local law, the Agreement and Warranties are
controlled by and construed under the laws of England, notwithstanding any conflicts of law provisions; and
the English courts shall have exclusive jurisdiction over any claim arising under the Agreement or Warranties.
In addition, if the Agreement is controlled by the laws of England, no person who is not a party to the Agreement
shall be entitled to enforce or take the benefit of any of its terms under the Contracts (Rights of Third Parties)
Act 1999. If you acquired the Software in Japan, unless expressly prohibited by local law, the Agreement and
Warranties are controlled by and construed under the laws of Japan, notwithstanding any conflicts of law
provisions; and the Tokyo District Court of Japan shall have exclusive jurisdiction over any claim arising
under the Agreement or Warranties. If you acquired the Software in Australia, unless expressly prohibited by
local law, the Agreement and Warranties are controlled by and construed under the laws of the State of New
South Wales, Australia, notwithstanding any conflicts of law provisions; and the State and federal courts of
New South Wales shall have exclusive jurisdiction over any claim arising under the Agreement or Warranties.
If you acquired the Software in any other country, unless expressly prohibited by local law, the Agreement
and Warranties are controlled by and construed under the laws of the State of California, United States of
America, notwithstanding any conflicts of law provisions; and the state and federal courts of California shall
have exclusive jurisdiction over any claim arising under the Agreement or Warranties.
For all countries referred to above, the parties specifically disclaim the application of the UN Convention on
Contracts for the International Sale of Goods. Notwithstanding the foregoing, either party may seek interim
injunctive relief in any court of appropriate jurisdiction with respect to any alleged breach of such party's
intellectual property or proprietary rights. If any portion hereof is found to be void or unenforceable, the
remaining provisions of the Agreement and Warranties shall remain in full force and effect. Except as expressly
provided herein, the Agreement constitutes the entire agreement between the parties with respect to the license
of the Software and Documentation and supersedes any conflicting or additional terms contained in any
Purchase Order or elsewhere, all of which terms are excluded. The Agreement has been written in the English
language, and the parties agree that the English version will govern.
Product warranty terms and other information applicable to Cisco products are available at the following
URL:
http://www.cisco.com/go/warranty
Supplemental End User License Agreement for Cisco Systems
Content Security Software
IMPORTANT: READ CAREFULLY
This Supplemental End User License Agreement ("SEULA") contains additional terms and conditions for the
Software product licensed under the End User License Agreement ("EULA") between You ("You" as used
herein means You and the business entity you represent or "Company") and Cisco (collectively, the
"Agreement"). Capitalized terms used in this SEULA but not defined will have the meanings assigned to them
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1337
End User License Agreement
End User License Agreement
in the EULA. To the extent that there is a conflict between the terms and conditions of the EULA and this
SEULA, the terms and conditions of this SEULA will take precedence.
In addition to the limitations set forth in the EULA on your access and use of the Software, you agree to
comply at all times with the terms and conditions provided in this SEULA.
DOWNLOADING, INSTALLING, OR USING THE SOFTWARE CONSTITUTES ACCEPTANCE OF
THE AGREEMENT, AND YOU ARE BINDING YOURSELF AND THE BUSINESS ENTITY THAT
YOU REPRESENT TO THE AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF
THE AGREEMENT, THEN CISCO IS UNWILLING TO LICENSE THE SOFTWARE TO YOU AND (A)
YOU MAY NOT DOWNLOAD, INSTALL OR USE THE SOFTWARE, AND (B) YOU MAY RETURN
THE SOFTWARE (INCLUDING ANY UNOPENED CD PACKAGE AND ANY WRITTEN MATERIALS)
FOR A FULL REFUND, OR, IF THE SOFTWARE AND WRITTEN MATERIALS ARE SUPPLIED AS
PART OF ANOTHER PRODUCT, YOU MAY RETURN THE ENTIRE PRODUCT FOR A FULL REFUND.
YOUR RIGHT TO RETURN AND REFUND EXPIRES 30 DAYS AFTER PURCHASE FROM CISCO
OR AN AUTHORIZED CISCO RESELLER, AND APPLIES ONLY IF YOU ARE THE ORIGINAL END
USER PURCHASER.
For purposes of this SEULA, the Product name and the Product description You have ordered is any of the
following Cisco Systems Email Security Appliance ("ESA"), Cisco Systems Web Security Appliance ("WSA")
and Cisco Systems Security Management Application ("SMA") (collectively, "Content Security") and their
Virtual Appliance equivalent ("Software"):
Cisco AsyncOS for Email
Cisco AsyncOS for Web
Cisco AsyncOS for Management
Cisco Email Anti-Spam, Sophos Anti-Virus
Cisco Email Outbreak Filters
Cisco Image Analyzer
McAfee Anti-Virus
Cisco Intelligent Multi-Scan
Cisco Data Loss Prevention
Cisco Email Encryption
Cisco Email Delivery Mode
Cisco Web Usage Controls
Cisco Web Reputation
Sophos Anti-Malware
Webroot Anti-Malware
McAfee Anti-Malware
Cisco Email Reporting
Cisco Email Message Tracking
Cisco Email Centralized Quarantine
Cisco Web Reporting
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1338
End User License Agreement
End User License Agreement
Cisco Web Policy and Configuration Management
Cisco Advanced Web Security Management with Splunk
Email Encryption for Encryption Appliances
Email Encryption for System Generated Bulk Email
Email Encryption and Public Key Encryption for Encryption Appliances
Large Attachment Handling for Encryption Appliances
Secure Mailbox License for Encryption Appliances
Definitions
For purposes of this SEULA, the following definitions apply:
"Company Service" means the Company's email, Internet, security management services provided to End
Users for the purposes of conducting Company's internal business.
"End User" means: (1) for the WSA and SMA, the employee, contractor or other agent authorized by Company
to access the Internet and the SMA via the Company Service; and (2) for the ESA, the email boxes of the
employees, contractors, or other agent authorized by Company to access or use the email services via the
Company Service.
"Ordering Document" means the purchase agreement, evaluation agreement, beta, pre-release agreement or
similar agreement between the Company and Cisco or the Company and a Cisco reseller, or the valid terms
of any purchase order accepted by Cisco in connection therewith, containing the purchase terms for the
Software license granted by this Agreement.
"Personally Identifiable Information" means any information that can be used to identify an individual,
including, but not limited to, an individual's name, user name, email address and any other personally identifiable
information.
"Server" means a single physical computer or devices on a network that manages or provides network resources
for multiple users.
"Services" means Cisco Software Subscription Services.
"Service Description" means the description of the Software Subscription Support Services at
https://www.cisco.com/c/en/us/about/legal/service-descriptions.html
"Telemetry Data" means samples of Company's email and web traffic, including data on email message and
web request attributes and information on how different types of email messages and web requests were
handled by Company's Cisco hardware products. Email message metadata and web requests included in
Telemetry Data are anonymized and obfuscated to remove any Personally Identifiable Information.
"Term" means the length of the Software subscription You purchased, as indicated in your Ordering Document.
"Virtual Appliance" means the virtual version of Cisco's email security appliances, web security appliances,
and security management appliances.
"Virtual Machine" means a software container that can run its own operating system and execute applications
like a Server.
Additional License Terms and Conditions
LICENSE GRANTS AND CONSENT TO TERMS OF DATA COLLECTION
License of Software.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1339
End User License Agreement
End User License Agreement
By using the Software and the Documentation, Company agrees to be bound by the terms of this Agreement,
and so long as Company is in compliance with this Agreement, Cisco hereby grants to Company a nonexclusive,
non-sublicensable, non-transferable, worldwide license during the Term to use the Software only on Cisco's
hardware products, or in the case of the Virtual Appliances, on a Virtual Machine, solely in connection with
the provision of the Company Service to End Users. The number of End Users licensed for the use of the
Software is limited to the number of End Users specified in the Ordering Documents. In the event that the
number of End Users in connection with the provision of the Company Service exceeds the number of End
Users specified in the Ordering Documents, Company shall contact an Approved Source to purchase additional
licenses for the Software. The duration and scope of this license(s) is further defined in the Ordering Document.
The Ordering Document supersedes the EULA with respect to the term of the Software license. Except for
the license rights granted herein, no right, title or interest in any Software is granted to the Company by Cisco,
Cisco's resellers or their respective licensors. Your entitlement to Upgrades to the Software is subject to the
Service Description. This Agreement and the Services are co-terminus.
Consent and License to Use Data.
Subject to the Cisco Privacy Statement at https://www.cisco.com/c/en/us/about/legal/privacy.html, Company
hereby consents and grants to Cisco a license to collect and use Telemetry Data from the Company. Cisco
does not collect or use Personally Identifiable Information in the Telemetry Data. Cisco may share aggregated
and anonymous Telemetry Data with third parties to assist us in improving your user experience and the
Software and other Cisco security products and services. Company may terminate Cisco's right to collect
Telemetry Data at any time by disabling Service Logs in the Software. Instructions to enable or disable Service
Logs are available in the Software configuration guide.
Description of Other Rights and Obligations
Please refer to the Cisco Systems, Inc. End User License Agreement, Privacy Statement and Service Description
of Software Subscription Support Services.
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
1340
INDEX
< 78, 1098, 1101, 1102, 1103, 1105, 1106, 1107, 1108, 1110, 1111, 1112, anti-virus (continued)
1114 dropping attachments 372
$EnvelopeSender variable 127 Encrypted 372, 373
$TRUSTED mail flow policy 376 modify message recipient 375
modify message subject 374
scan and repair 372
A scan only 372
accepting email 102 send custom alert notification 376
access privileges for custom user roles 984 send to alternate destination host 375
Active Directory Wizard 48 sending default notification 375
Adaptive Scanning 437 Unscannable 373
address rewriting 702 Virus Infected 373
address tagging key 745 Anti-Virus Archive Logs 1141
purging 745 Anti-Virus Logs 1141
Advanced Malware Protection 481 anti-virus quarantine. See quarantine, virus 928
alert messages 42, 62 archivemessage command 1114
alert settings 42, 62 AsyncOS reversion 1039
alertlisting 1047 AsyncOS upgrades 1034
alerts 437, 1043 AutoSupport feature 43, 62, 1044
enabling for Outbreak Filters 437
severities 1043 B
ALL entry 102, 103, 134
in HAT 102, 103 Base DN 786
in RAT 134 blackhole listener 78, 1255
ALLOWED_LIST sender group 376 body scanning 172
alternate address 365 Bounce Logs 1141
always rule 432 bouncerecipients command 1108
AMP Archive 1141 bouncing recipients 1109
AMP Engine Logs 1141 all 1109
AMP. See Advanced Malware Protection. 481 by Envelope From 1109
anti-spam 89, 366, 386, 404, 405, 406, 422 by hostname 1109
HAT parameter 89 bypassing 137, 219
IronPort Anti-Spam 386 anti-spam 219
reporting false positives and negatives 406 throttling 137
scanning appliance-generated messages 405
selecting a default scanning engine 404
testing 422
C
using multiple scanning engines 366 call-ahead SMTP server 667, 673
Anti-Spam Archive Logs 1141 routing 673
Anti-spam logs 1141 CASE (Context Adaptive Scanning Engine [TM]) 419
anti-virus 372, 373, 374, 375, 376, 661 case-sensitivity 161, 786, 790
actions 373 in LDAP queries 786, 790
add custom header 375 in message filters 161
advanced options 373 categories 468
archive original message 374 adult 468
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-1
INDEX
categories (continued) categories (continued)
advertisements 468 reference 468
alcohol 468 religion 468
arts 468 SaaS and B2B 468
astrology 468 safe for kids 468
auctions 468 science and technology 468
business and industry 468 search engines and portals 468
chat and instant messaging 468 sex education 468
cheating and plagiarism 468 shopping 468
child abuse content 468 social networking 468
computer security 468 social science 468
computers and internet 468 society and culture 468
dating 468 software updates 468
digital postcards 468 sports and recreation 468
dining and drinking 468 streaming audio 468
dynamic and residential 468 streaming video 468
education 468 tobacco 468
entertainment 468 transportation 468
extreme 468 travel 468
fashion 468 unclassified 468
file transfer services 468 weapons 468
filter avoidance 468 web hosting 468
finance 468 web page translation 468
freeware and shareware 468 web-based email 468
gambling 468 centralized management 1024
games 468 Centralized Management 937, 1246
government and law 468 and Destination Controls 1246
hacking 468 and quarantines 937
hate speech 468 certificate 679
health and nutrition 468 certificate authority 679
humor 468 Certificate Signing Request 679
illegal activities 468 certificates 53, 559, 675, 678, 679
illegal downloads 468 demo 53
illegal drugs 468 generating a request 559
infrastructure and content delivery networks 468 generating and signing your own 679
internet telephony 468 importing 675
job search 468 intermediate certificates 678
lingerie and swimsuits 468 chain query 801
lotteries 468 creating 801
mobile phones 468 charset 952
nature 468 CIDR address block 103
news 468 Cisco Security Intelligence Operations 427
non-governmental organizations 468 Cisco Web Security Services 452
non-sexual nudity 468 clean messageemail 840
online communities 468 clean message 840
online storage and backup 468 CLI 21
online trading 468 see Command Line Interface 21
organizational email 468 CLI Audit Logs 1141
parked domains 468 cluster 453
peer file transfer 468 Code-in-Body> 78, 1098, 1101, 1102, 1103, 1105, 1106, 1107, 1108, 1110,
personal sites 468 1111, 1112, 1114
photo searches and images 468 community string 1116
politics 468 conformance level 624
pornography 468 SPF/SIDF verification 624
professional networking 468 connectivity issues, troubleshooting 1259
real estate 468
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-2
INDEX
content filters 282, 290, 297, 301, 928, 1317, 1318, 1321 DLP (continued)
actions 290 risk factor score 524
conditions 282 severity scale 528
example 1317, 1318 troubleshooting 538
non-ascii character sets 301, 1321 updating the engine and classifiers 536
variables 297 DLP policies 517, 520, 524, 527
content matching classifier 517 content matching classifier 517
Content Scanner 225 detection rule 520, 524
counters 1092 filtering attachments 527
CPU usage 1094 filtering senders and recipients 527
CRAM-MD5 808 DNS 43, 53, 843, 1067, 1068
CSV data 865 authoritative server 1067
custom header 415 disabling reverse DNS lookup timeoutReverse DNS Lookup 1068
custom SMTP response 127 disabling 1068
variable 127 double lookup 843
priority 1067
servers 43, 53
D setting 43, 53
D-Mode 511 splitting 1067
data loss prevention 928 timeout 1067
default 38, 42, 43, 51, 52, 133 timeout for reverse DNS lookups 1068
domain 133 DNS cache 1105
gateway 43, 52 DNS list 175
hostname 42, 51 DNS lookup 1105
IP address 38 DNS servers 1067
router 43, 52 DNSBL 175
default DNS server 1068 dnsstatus command 1105
default router 43 Domain Debug Logs 1141
delete all messages in the spam quarantine 974 Domain Keys 601, 602, 604, 612
deleterecipients command 1107 importing signing keys 612
delivering mail 747 signing key size 604
message time out 747 verification 601
possible delivery 747 verifying signatures 602
delivernow command 1112 Domain Name Service (DNS) 43, 53
Delivery Connection ID (DCID) 1092 settings 43, 53
Delivery Logs 1141 domain profile 615
delivery queue 1107 deleting all existing profiles 615
delivery queue, monitoring 1102 double-DNS verified 844, 892
demo certificate 53 drop-attachments-where-dictionary-match 234
Destination Controls 1246 DSR 1135
and Centralized Management 1246 load balancing 1135
detection rule 520, 524 loopback interface 1135
Direct Server Return (DSR) 1135 Virtual IP (VIP) 1135
Directory Harvest Attack (DHA) 802 DTD (document type definition) 1019
disclaimer stamping 656, 658 dual DKIM and DomainKey signing 607
multiple encodings 658 dummy accounts 97
disclaimers 654, 655, 656 duplex settings, editing 1127
adding to messages 656
HTML text resources 654 E
using text resources 655
DKIM verification 621 Early Expiration 930
Authentication-Results header 621 for quarantine 930
DLP 510, 517, 518, 520, 524, 528, 535, 536, 538 email 702
false positives, minimizing 510, 517, 518, 520, 524 rewriting addresses 702
including sensitive content in Message Tracking 535 email injector 53
see listener 53
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-3
INDEX
Email Security Monitor 833, 839, 843, 844, 865, 875, 892 G
automated reporting 865
external domains received listing 843 gauges 1094
Items Displayed menu 844, 892 global counters 1106
summary table 839, 875 good neightbor table 684
Time Range menu 839, 875 graphical user interface 21
encoding 658 see GUI 21
in disclaimers 658 graphs 1126
encryption 88, 546, 565, 675 grouping, of appliances for File Analysis result details in the cloud 494
use with filter action 546, 565 GUI 21, 22, 53, 1125
encryption headers 549 accessing 22
End User Quarantine 966 browser requirements 21
see spam quarantine, end user access 966 enabling 53, 1125
enterprise gateway 63 GUI logs. See HTTP logs 1141
Enterprise Gateway configuration 90 GUI session timeout 999, 1000
Envelope Recipient 166
Envelope Recipient, rewriting 702
H
Envelope Sender 167
envelope sender DNS verification 126 hard power reset 1038, 1269
evaluation key 61 HAT 110, 115, 121
McAfee 61 exporting 121
Sophos 61 testing HAT variables 110
evaluation key for IronPort Anti-Spam 60 HAT order 114
evaluation key for Outbreak Filters 48, 61 editing via GUI 114
explained 126 headers 702
exporting 653, 654 headers, inserting 549
HTML text resources 654 headers, logging 420
text resources 653 headers, stripping with message filters 216
external authentication 812, 992, 993 Host Access Table (HAT) 114
enabling LDAP 992 reordering in GUI 114
enabling RADIUS 993 hostname 42, 51
specifying the hostname during setup 42
F hostrate command 1103
hoststatus command 1101
factory configuration 38 HTTP 53, 1125, 1297
feeback about this documentation, sending 18 enabling 53
filtering unparsable messages 165 GUI 1125
filters 139, 141, 148, 160, 165, 172, 176 HTTP authentication 866
comment character 141 HTTP Logs 1141
matching dictionary terms 148, 176 HTTPS 53, 694, 1125, 1297
matching empty headers 165 certificate for 694
regular express and Python 160 enabling 53
scannable archive file types 172 GUI 1125
unparsable messages 165 HTTPS login 22
final entry, in HAT 102
findevent 1115
I
finding senders 115
forcing updates 381 image analysis 228, 282, 290
forward DNS lookup 1104 image scanning 228
FTP 1297 image verdicts 228
FTP Access 1298 IMAP authentication 966
FTP Server Logs 1141 implementsv 128
fully-qualified domain name 103 importing 653, 654
HTML text resources 654
text resources 653
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-4
INDEX
importing signing keys 612 LDAP (continued)
incoming relay 415, 416 load-balancing 818
custom header 415 Microsoft Exchange 5.5 support 783
received header 416 multiple servers 818
incoming relays 622 OpenLDAP queries 792
Incoming Relays 420 query tokens 786
example log entry 420 recursive queries 787
Injection Connection ID (ICID) 1092 SSL 787
injection control counter reset 124 SunONE queries 792
injection control periodicity 124 test servers 780
Injection Debug Logs 1141 testing queries 785, 790
injector 53 testing servers 780
see listener 53 LDAP Debug Logs 1141
insecure relay 134 LDAP errors 791
inserting headers 549 LDAP routing query 672
installation 1039 with SMTP call-ahead recipient validation 672
reverting 1039 LDAPS certificate 787
invalid recipient 840 limits 699
IP interfaces 43, 53 SMTP Routes 699
assigning 43 link aggregation 1128
defining listeners on 53 listener 87, 88, 656
IronPort Anti-Spam 47, 60, 384, 422 adding disclaimers 656
evaluation key 47, 60 encryption on 88
filters 384 malformed MAIL FROM and default domain 87
testing 422 listenerconfig command 78
IronPort Email Encryption 539, 542, 546, 565 load 1094
configuring 539 log file type 1141
envelope settings 542 log subscription 374, 1141
key server settings 542 Sophos 374
message settings 542 log subscriptions 1150
notification settings 542 logging,headers 420
use with filter action 546, 565 logical IP interface 43
IronPort Spam Quarantine 72 logs 1141, 1146, 1150, 1192, 1207, 1209, 1211, 1264
released messages and email pipeline 72 Anti-Spam Archive 1141
IronPort Spam Quarantine. See Spam quarantine 928 Anti-Virus 1141
IronPort Text Mail Logs 1141 Anti-Virus Archive 1141
Bounce Logs 1141
CLI Audit Logs 1141
K comparison 1146
key size 604 Configuration History Logs 1192
definition 1141
Delivery Logs 1141
L extensions in filenames 1211
format 1141
LDAP 166, 167, 780, 783, 785, 786, 787, 790, 792, 793, 806, 812, 816, 818,
FTP Server Logs 1141
964, 966, 992
global attributes 1209
alias consolidation query 816
HTTP Logs 1141
alias expansion 793
Injection Debug Logs 1141
anonymous queries 787
IronPort Text Mail Logs 1141
base DN 786
LDAP Debug Logs 1141
connection pooling 806
levels 1207
connections 790
log subscription defined 1141
external authentication 812, 992
NTP Logs 1141
failover 818
qmail Format Delivery Logs 1141
group queries 166, 167
Scanning 1141
LDAPS certificate 787
Status Logs 1141
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-5
INDEX
logs (continued) message filters (continued)
subscriptions 1150 moving 238
troubleshooting with 1264 ordering 143
loopback interface 1135 overview 139
random numbers in 170
rules 140
M SenderBase Reputation Score 175
M-Series 1285 status 238
MAIL FROM 148, 282 syntax 141
mail loops, detecting 257 time and date 169
mail policies 270 variables 203
First Match Wins 270 message headers 170
mail policies, outgoing 529 message headers, inserting with message filters 216
DLP 529 Message ID (MID) 1092
mail protocol 78 message modification level threshold 441
defining in < 78 message replication 194, 211
mail transfer agent. See MTA. 1286 message splintering 271
mailertable feature 697 defined 271
mailing lists 971 message tracking 419
notifications 971 Incoming Relays 419
malware 366 Message Tracking 535
defined 366 and sensitive content 535
marketing messages 840 message variables 968
matching empty headers 165 spam quarantine notifications 968
maximum 89, 97 MIB file 1117
message size in HAT 89 monitoring 1097
messages per connection in HAT 89 monitoring Virtual Gateway addresses 756
recipients per hour in HAT 97 MTA 63, 90, 675
recipients per message in HAT 89 multilayer anti-virus scanning 366
maximum recipients per hour 89 multiple appliances 38
mbox format 215 multiple recipients 271
mbox-format log file 374 MX 25
McAfee 61
evaluation key 61 N
McAfee anti-virus engine 369
memory 1094 negative scores 106
message body scanning 172 netmask 43
message encoding 244 network access list 997
modifying 244 network time protocol (NTP) 42, 62
message filter 194 settings 42, 62
filter actions 194 NIC pairing 1128, 1129
message filter action variables 656 alerts 1129
using in disclaimers 656 named on upgrade 1129
message filter for SBRS 98 NIC teaming 1128
message filters 139, 140, 141, 143, 148, 169, 170, 172, 173, 175, 176, 203, Normal Expiration 930
238, 242, 928 for quarantine 930
adding 238 not.double.verified 126
attachment-protected 148 NTP Logs 1141
attachment-unprotected 148 NTP server 1084
body-dictionary-match 176 removing 1084
combining 141, 148 NXDOMAIN 126, 132
deleting 238
encryption 173
exporting 242
O
making (in)active 238 oldmessage command 1114
MIME types 172
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-6
INDEX
open relay, definition 134 private listeners 102
opening links in a separate window 839 default entries 102
Outbreak Filters 48, 61, 290, 425, 427, 428, 429, 430, 431, 432, 433, 434, prototcol 78
437, 439, 440, 441, 446 see mail protocol 78
Adaptive rules defined 430 proxy server for IronPort Anti-Spam Rules 1030
Adaptive Scanning 437 public blocked list 175
alerts 446 public listeners 102
always rule 432 default entries 102
anti-virus updates 433 purging address tagging keys 745
bypassed file extensions 440 PVO. See quarantines, policy, virus, and outbreak 928
Context Adaptive Scanning EngineOutbreak Filters 428
CASE 428
delaying messages 428
Q
enabling alerts 437 qmail Format Delivery Logs 1141
evaluation key 48, 61 quarantine 499, 928, 930, 931, 934, 938, 939, 941, 943, 945
modifying messagesOutbreak Filters 430 applying actions to messages in 939
message modification 430 default action 931, 934
multiple scores 433 displaying non-ascii characters in subject 499
non-viral threats 427 early expiration 930
Outbreak rules defined 430 In other quarantines 941
overview 425 international character sets 938
re-evaluating messages 433, 434 normal expiration 930
redirecting links 429 outbreak 928
rule 431 outbreak, reporting messages to Cisco 945
setting a message modification level threshold 441 retention time 930
setting a quarantine level threshold 440 spam. See Spam quarantine 928
skipping 290 stripping attachments 499
SNMP Traps 446 subject tagging 499
threat categoriesOutbreak Filters 427 testing messages for viruses 943
virus outbreaks 427 unclassified 934
updating rules 439 virus 928
using without anti-virus scanning 433 quarantine level threshold 440
overflow 433 quarantine overflow 433
Quarantine Threat Level Threshold 431
P recommended default 431
setting 431
partial address 103, 136 quarantines 928, 929, 937
in HAT 103 centralized policy, virus, and outbreak quarantines 937
in RAT 136 policy 928
passphrase 991 policy, virus, and outbreak 937
settings 991 centralized 937
pausing the work queue 1113 policy, virus, and outbreak, managing 929
PEM format, for certificates 559 types 928
performance 1267 queries 792, 793, 794, 796, 805, 812, 816
phased approach to reputation filters 95 acceptance 792
pinout for serial connection 33 external authentication 812
POP authentication 966 group 796
POP/IMAP servers 90 masquerading 794
positive scores 106 routing 793
possible delivery 747 SMTP authentication 805
pre-policy filters 241 spam quarantine alias consolidation 816
importing 241 queue 78
private injector 56
private key 675
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-7
INDEX
R RFC (continued)
1067 1116
RADIUS external authentication 993 1213 1116
RAM 1267 1907 1116
RAM Utilization 1094 2047 499
RAT 137 2487 675
bypassing recipients 137 2821 19
bypassing recipients (CLI) 137 821 269
bypassing recipients (GUI) 137 822 269
rate command 1103 risk factor score 510, 524
rates 1096 DLP 524
RBL 148 rolling over log files 1211
RCPT TO 148, 282 root servers (DNS) 43, 53
RCPT TO command 135 routing 673
real-time monitoring 1103 SMTP call-ahead server 673
received header 416
receiving control, bypass 137
receiving errors 1264
S
Recipient Access Table (RAT) 133, 134 safelist/blocklist 953, 954, 955, 962, 963
default entry 134 and external spam quarantine 955
definition 133 backing up and restoring 962
editing via CLI 134 enabling 954
recipient validation 667 importing and exporting 962
recipients, counting in message filters 171 managing 955
reconfigure 38 troubleshooting 963
recursive DNS queries 1068 workqueue 953
recursive queries, LDAP 787 SBRS 97, 106, 175
redirecting email 44 none 106, 175
redirecting URLs in messages 458 testing 97
redirectrecipients 1109 SBRS see Senderbase Reputation Service Score 106
relaying email 102 scannable archive file types 172
relaying messages 53 scanning images 228
remote 1027 Scanning Logs 1141
removemessage command 1114 scheduled log rollover 1211
reporting 419 scp command 1300
Incoming Relays 419 SDS. See Cisco Web Security Services 452
required TLS 683 secure copy 1300
resetcounters command 1106 secure HTTP (https) 675
Resource Conservation mode 1094, 1267 Secure LDAP 787
resume command 1112 Secure Socket Layer (SSL) 675
resumedel command 1111 selecting a notification 661
resumelistener command 1112 SenderBase 89, 106
resuming email delivery 1111 SBO in sender groups 106
resuming receiving 1112 SenderBase Affiliate network 93
Retention Time 930 SenderBase Network Owner Identification Number 103
for quarantines 930 SenderBase Reputation score 419
retrospective verdict 505 SenderBase Reputation Score 94, 106
retry message delivery 849 SenderBase Reputation Scores, syntax in CLI 106
reverse DNS lookup 108, 749, 1104 SenderBase Reputation Service 93, 833
revert 1039 SenderBase Reputation Service Score 106
installation 1039 SenderBase, querying 106
rewriting email addresses 702 separate window icon 839
rewriting URLs in messages 458 serial connection pinouts 1301
RFC 19, 269, 499, 675, 1116 SERVFAIL 126, 132
1065 1116 severity scale 528
1066 1116 DLP 528
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-8
INDEX
showmessage command 1114 Sophos 47, 61, 381
showrecipients 1110 evaluation key 47, 61
SIDF records 623 updates 381
testing 623 Sophos virus scanning 375
valid 623 filters 375
SIDF verification 148, 622, 624, 628, 631 spam 422
configuring 622 testing 422
conformance level 624 spam message 840
enabling 624 spam quarantine 947, 949, 964, 965, 966, 968, 971, 973, 974, 975, 1288
results 628 alias consolidation 971
testing 631 behavior when full 949
signing key 604 deleting all messages 974, 975
size 604 disabling 975
signing keys 612 end user access 966
deleting all existing keys 612 end-user access 964
removing specific keys 612 external 947, 1288
SMI file 1117 IMAP/POP authentication 965
SMTP 90, 135, 422 LDAP authentication 965
messages 90 local 947
response 135 message details 973
testing IronPort Anti-Spam 422 message variables 968
SMTP Auth 805, 808 notification 968
DIGEST-MD5 808 receiving multiple notifications 971
MD5 805 released messages and email pipeline 974
SHA 805 testing notifications 971
suported authentication mechanisms 805 specifying an offset 1084
TLS 808 SPF records 623
SMTP authenticated user match filter rule 180 testing 623
SMTP Authentication profile 808 valid 623
SMTP call-ahead recipient validation 667, 671, 672, 674 SPF verification 622, 624, 627, 628, 631
bypassing 674 configuring 622
conversation workflow 667 conformance level 624
SMTP server responses 671 enabling 624
with LDAP routing query 672 received SPF header 627
SMTP CAll-Ahead Server Profile 669, 672 results 628
creating 669 testing 631
enabling on a listener 672 spf-passed filter rule 148, 631
SMTP conversation 667 spf-status filter rule 148, 629
SMTP call-ahead server 667 SPFverification 148
SMTP daemon 53 SSH 24
see injector 53 SSL 787
see listener 53 STARTTLS 675
SMTP Routes 697, 699, 700 definition 675
limits 699 stateless logs 1166
mail delivery and splintering 700 status command 1098
SNMP 1116, 1117, 1118 status detail command 1098
community string 1116 Status Logs 1141
MIB file 1117 stopped by content filter 840
overview 1116 stopped by reputation filtering 840
SMI file 1117 streaming upgrades 1027
specifying multiple trap targets 1118 strip headers 216
traps 1118 strip-header filter action 216
SNMP (Simple Network Management Protocol) 1116 subnet 43
snmpconfig command 1118 suspenddel command 1110
SNMPv1 1116 suspending email delivery 1110
SNMPv2 1116 suspending receiving 1111
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-9
INDEX
suspendlistener command 1111 U
synchronizing time 42, 62
System Capacity 860, 861, 862, 879, 880, 881 unary form, in message filters 170
All page 862, 881 unclassified quarantine. See quarantine, unclassified 928
Incoming Mail page 861, 879 unparsable messages 165
memory page swapping 862, 880 unsolicited commercial email 93
Outgoing Mail page 861, 879 updates 536
System Load page 861, 880 DLP engine and classifiers 536
WorkQueue page 860, 879 upgrades 1027, 1028, 1038
system clock 42, 62 available 1038
System Logs 1141 local 1027
system quarantine. See quarantines, policy, virus, and outbreak 928 obtaining via GUI 1028
system setup wizard 38 streaming 1027
system time 42, 62 URL reputation 449
setting 42, 62 user accounts 977, 991
limits 977
locking and unlocking 991
T user groups 977, 978
testing 379, 422 user types 978
IronPort Anti-Spam 422 uuencoded attachments 143
Sophos virus engine 379
testing HAT variables 110 V
text resources 652, 653, 654, 655
code view 654 verdict 282, 290
disclaimers 655 image analysis 282, 290
exporting 653 verification 622
exporting and importing into HTML resources 654 SIDF 622
HTML-based 654 SPF 622
importing 653 version 863
managing 652 virtual appliance 1141
using in policies and settings 655 license 1141
third-party relay 134 virtual Email Security appliance 32
Threat Level 430 loading the license 32
defined 430 Virtual Gateway addresses 215
Threat Operations Center (TOC) 430 Virtual Gateway queue 749
thresholds, in SenderBase Reputation Scores 106 Virtual IP (VIP) 1135
throttling 93 virus message 840
time servers 42, 62 virus quarantine. See quarantine 928
time zone 1084 virus. 928
time zone, setting 42, 62 VLAN 1131
time, system 42, 62 defined 1131
TLS 675, 684 labels 1131
certificates 675
default 684
W
preferred 684
required 684 WBRS 449
tophosts command 1102 See URL reputation 449
topin command 1105 web interface 53
trace 419 enabling 53
trace command 97 web reputation 186, 222
troubleshooting 538 message filters 186, 222
DLP 538 Web UI session timeout 999, 1000
trustworthiness 106 weekly status updates 62
TTL 1100 white space 158
whitespace 374
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-10
INDEX
wizard 38, 48 X
Active Directory 48
system setup 38 X-headers, adding 499
work queue 1094, 1113 X-IronPort-AV header 372
work queue, pausing 1113 XML 1019, 1126, 1141
XML Status feature 1126
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-11
INDEX
User Guide for AsyncOS 14.0 for Cisco Secure Email Gateway - GD (General Deployment)
IN-12
You might also like
- VLab Demo - ASM - Protecting Against Cookie Modification - V13.0.ANo ratings yetVLab Demo - ASM - Protecting Against Cookie Modification - V13.0.A7 pages
- Oracle Process Manufacturing: Product Development Security User's GuideNo ratings yetOracle Process Manufacturing: Product Development Security User's Guide40 pages
- SCRUM: Mastering Agile Project Management for Exceptional Results (2023 Guide for Beginners)From EverandSCRUM: Mastering Agile Project Management for Exceptional Results (2023 Guide for Beginners)No ratings yet
- 8.1.4.7 Packet Tracer - Subnetting Scenario 1 PDFNo ratings yet8.1.4.7 Packet Tracer - Subnetting Scenario 1 PDF4 pages
- BRKRST-3114 The Art of Network Architecture100% (1)BRKRST-3114 The Art of Network Architecture60 pages
- Cisco Basic CCNA Lab Setup InstructionsNo ratings yetCisco Basic CCNA Lab Setup Instructions13 pages
- Lab 3.4 Configuring Site-To-Site Ipsec Vpns With SDM: Learning ObjectivesNo ratings yetLab 3.4 Configuring Site-To-Site Ipsec Vpns With SDM: Learning Objectives40 pages
- CCNP Routing and Switching ROUTE 300-101 Official Cert Guide100% (3)CCNP Routing and Switching ROUTE 300-101 Official Cert Guide189 pages
- CompTIA Server+ Certification All-in-One Exam Guide (Exam SK0-005), 2nd Edition Daniel Lachance - Download the ebook with all fully detailed chapters100% (1)CompTIA Server+ Certification All-in-One Exam Guide (Exam SK0-005), 2nd Edition Daniel Lachance - Download the ebook with all fully detailed chapters33 pages
- Exam Topics Need To KN 2. Videos 3. Revision: 1.0 Network Fundamentals 20%No ratings yetExam Topics Need To KN 2. Videos 3. Revision: 1.0 Network Fundamentals 20%4 pages
- VLab Demo - ASM - Blocking Cross-Site Scripting Attacks - V13.0.ANo ratings yetVLab Demo - ASM - Blocking Cross-Site Scripting Attacks - V13.0.A6 pages
- Training - Azure Administrator Associate CertifiedNo ratings yetTraining - Azure Administrator Associate Certified2 pages
- How To Setup Your Lab - Step by Step InstructionsNo ratings yetHow To Setup Your Lab - Step by Step Instructions10 pages
- CCNP - BSCI.Quick - Reference.Sheets - Exam.642901 Ebook - Ipmanager.ir PDF100% (1)CCNP - BSCI.Quick - Reference.Sheets - Exam.642901 Ebook - Ipmanager.ir PDF73 pages
- Check Point Certified Security Administrator 156-215.80 (CCSA R80) 2017-12-08No ratings yetCheck Point Certified Security Administrator 156-215.80 (CCSA R80) 2017-12-0877 pages
- Checkpoint Actualtests 156-215 75 v2012-04-08No ratings yetCheckpoint Actualtests 156-215 75 v2012-04-08178 pages
- Network Security 1.0 Modules 11 - 12 - Intrusion Prevention Group Exam AnswersNo ratings yetNetwork Security 1.0 Modules 11 - 12 - Intrusion Prevention Group Exam Answers13 pages
- CCNA Security v20 Final Exam Answers 100No ratings yetCCNA Security v20 Final Exam Answers 10014 pages
- Catalyst 6500 Series and Cisco 7600 Series Firewall Services Module Installation and Configuration NoteNo ratings yetCatalyst 6500 Series and Cisco 7600 Series Firewall Services Module Installation and Configuration Note218 pages
- Check Point Security Management: Administration GuideNo ratings yetCheck Point Security Management: Administration Guide172 pages
- How To Configure Dual ISP Network With GlobalProtect VPN Using A Virtual Router and Policy-Based ForwardingNo ratings yetHow To Configure Dual ISP Network With GlobalProtect VPN Using A Virtual Router and Policy-Based Forwarding11 pages
- Deploying and Managing a Cloud Infrastructure: Real-World Skills for the CompTIA Cloud+ Certification and Beyond: Exam CV0-001From EverandDeploying and Managing a Cloud Infrastructure: Real-World Skills for the CompTIA Cloud+ Certification and Beyond: Exam CV0-001No ratings yet
- MCSA Windows Server 2012 R2 Complete Study Guide: Exams 70-410, 70-411, 70-412, and 70-417From EverandMCSA Windows Server 2012 R2 Complete Study Guide: Exams 70-410, 70-411, 70-412, and 70-417No ratings yet
- Mastering The Spritekit Framework: Develop Professional Games With This New Ios 7 FrameworkFrom EverandMastering The Spritekit Framework: Develop Professional Games With This New Ios 7 FrameworkNo ratings yet
- SecurityDayTunisia FortinetTeam Slides KB1 SecOPsNo ratings yetSecurityDayTunisia FortinetTeam Slides KB1 SecOPs28 pages
- Instant download Handbook of SCADA control systems security Second Edition Brodsky pdf all chapter100% (5)Instant download Handbook of SCADA control systems security Second Edition Brodsky pdf all chapter52 pages
- Computers in Industry: Marianna Lezzi, Mariangela Lazoi, Angelo CoralloNo ratings yetComputers in Industry: Marianna Lezzi, Mariangela Lazoi, Angelo Corallo14 pages
- Whitepaper - State of Construction TechnologyNo ratings yetWhitepaper - State of Construction Technology16 pages
- Technical Note: Fortios V4.0 Mr3 L2Tp/Ipsec and Windows7 With PSKNo ratings yetTechnical Note: Fortios V4.0 Mr3 L2Tp/Ipsec and Windows7 With PSK12 pages
- ﺔﻛﺮﺸﻟا فﺮﺸُﻣ تﺎﻧﺎﻴﺑ ةرﺎﻤﺘﺳا:ﺖﻧﺮﺘﻧﻹا ﺮﺒﻋ تﺎﻛﺮﺸﻠﻟ ﺔﻴﻓﺮﺼﻤﻟا تﺎﻣﺪﺨﻟا Corporate Internet Banking: Corporate Admin User FormNo ratings yetﺔﻛﺮﺸﻟا فﺮﺸُﻣ تﺎﻧﺎﻴﺑ ةرﺎﻤﺘﺳا:ﺖﻧﺮﺘﻧﻹا ﺮﺒﻋ تﺎﻛﺮﺸﻠﻟ ﺔﻴﻓﺮﺼﻤﻟا تﺎﻣﺪﺨﻟا Corporate Internet Banking: Corporate Admin User Form1 page
- Download Ethics and Technology: Controversies, Questions, and Strategies for Ethical Computing, 5th Edition 5th Edition – Ebook PDF Version ebook All Chapters PDF100% (9)Download Ethics and Technology: Controversies, Questions, and Strategies for Ethical Computing, 5th Edition 5th Edition – Ebook PDF Version ebook All Chapters PDF41 pages
- Job Description of Information Technology OfficerNo ratings yetJob Description of Information Technology Officer3 pages
- ASM_and_Grid_Infrastructure_Oracle_RAC_1721622927No ratings yetASM_and_Grid_Infrastructure_Oracle_RAC_172162292730 pages
- A Dynamic DNA For Key-Based CryptographyNo ratings yetA Dynamic DNA For Key-Based Cryptography5 pages
- Medium Com Omarelgabrys Blog Microservices With Spring Boot Authentication With JWT Part 3 Fafc9d7187e8No ratings yetMedium Com Omarelgabrys Blog Microservices With Spring Boot Authentication With JWT Part 3 Fafc9d7187e819 pages
- Aljaz+Mali+-+Secure+your+APEX+application Final HROUGNo ratings yetAljaz+Mali+-+Secure+your+APEX+application Final HROUG148 pages
