Tumbleweed Email Firewall Administrator’s Guide Release 6.2
Tumbleweed® Communications Corp. 700 Saginaw Drive Redwood City, CA 94063 (650) 216-2000 http://www.tumbleweed.com AG-EMF-620-Rev00
Copyright Notice The contents of this manual, the associated Tumbleweed Active Agents™, Tumbleweed SecureTransport™, Integrated Messaging Exchange™ (IME™) software, Messaging Management System™ (MMS™), Tumbleweed Dynamic Anti-spam Service™, Tumbleweed Email Firewall™ (EMF™), Tumbleweed Validation Authority™, Tumbleweed Valicert Validation Authority™ and other computer programs (hereinafter collectively called “Tumbleweed Software”) offered by Tumbleweed Communications Corp. (Tumbleweed) are the property of Tumbleweed and are copyrighted. Use of Tumbleweed Software is governed by the license agreement accompanying the original media. Your right to copy Tumbleweed Software and its documentation is limited by copyright law. Making copies, adaptations, or compilation works (except copies of Tumbleweed Software for archival purposes or as an essential step in the utilization of the program in conjunction with the equipment) without prior written authorization from Tumbleweed is prohibited by law. Tumbleweed may revise this publication from time to time without notice. Copyright 1997-2004 Tumbleweed Communications Corp. All rights reserved. Some of the processes, arrangements, user interfaces, transaction sequences, site and system architectures, data arrangements, and data processing algorithms, described or embodied in the Tumbleweed Software, are covered by one or more of the following U.S. Patents Nos. 5,790,790; 6,061,448; 6,119,137; 6,151,675; 6,192,407; 399,836; 6,385,655; 6,470,086; 6,487,599; 6,502,191; 6,516,411; 6,529,956; 6,609,196; 6,651,166; 6,725,381 and 6,748,529.
Restricted Rights Legend Use, duplication or disclosure by the Government is subject to restrictions set forth in subparagraphs (a) through (d), excluding subparagraph (c)(2)(iv), of FAR 52.227-19 when applicable, or in DFARS 227.7202-3, and in similar clauses in the NASA FAR Supplement.
Trademarks Tumbleweed®, is a registered trademark, and Integrated Messaging Exchange™, IME™, Messaging Management System (MMS)™, Secure Inbox™, Secure Envelope™, Secure Redirect™, Secure Response™, IME Statements™, IME Developer™, IME Messenger™, Tumbleweed Secure Mail™, Tumbleweed Dynamic Anti-spam Service™, Tumbleweed Email Firewall™ (EMF™), Tumbleweed Message Protection Lab™, Tumbleweed Active Agents™, Tumbleweed SecureTransport™, Tumbleweed Validation Authority™ and Tumbleweed Valicert Validation Authority™ are trademarks of Tumbleweed Communications Corp.
Contents Preface
xxv
Chapter 1
Introduction 1.1 1.2 1.3
Chapter 2
1
Intended Audience .......................................................................................... 2 Overview of Email Firewall 6.2 ..................................................................... 3 Other Documentation ..................................................................................... 4
Setting Up Email Firewall Administration 2.1 2.2
2.3
2.4
7
Overview of Administrator Setup Tasks ........................................................ 8 Administrative Security .................................................................................. 9 2.2.1 Web Administration Access Controls ................................................ 9 2.2.2 Logging In ........................................................................................ 10 Setting Up Secure Login ............................................................. 10 2.2.3 Main Menu ........................................................................................ 12 System Status ............................................................................................... 14 2.3.1 Info and Alerts Status ....................................................................... 14 2.3.2 Message Queues Status ..................................................................... 17 2.3.3 Email Firewall Services Status ......................................................... 19 Automatic Email Firewall Services Restarts .............................. 21 Setting Up Admin Roles and Accounts ........................................................ 21 2.4.1 Admin Roles Access and Capabilities .............................................. 23 SQL Server Access Requirements for SuperAdmin ................... 23 Standard Access Categories, Access and Capabilities ................ 24 Contents iii
2.5
iv Contents
Queues .........................................................................................25 Policies ........................................................................................25 Policy Modules ............................................................................25 Directory .....................................................................................26 Logs and Reports .........................................................................26 Setup and Configuration .............................................................26 2.4.2 Assigning and Creating Admin Roles ...............................................27 2.4.3 Creating New Administrator Accounts .............................................29 2.4.4 Preferences ........................................................................................31 Setting Up Relays .........................................................................................32 2.5.1 Relay Settings Configuration ............................................................33 2.5.2 Global Relay Settings .......................................................................34 Stopping Inbound or Outbound Mail ..........................................34 Enabling and Disabling Preprocessing and Policy Engine .........35 2.5.3 Limit Settings ....................................................................................36 Maximum Connections and Delay Settings ................................36 Network Connections and Replication Environments ................37 Message Size and Recipient Limits ............................................37 2.5.4 Identity Settings ................................................................................38 Setting the SMTP Port ................................................................38 Specifying the Relay Host Name ................................................39 Specifying the SMTP Greeting and Postmaster Information ......39 Hiding Email Firewall Version Number in Message Headers ....40 Local MX Hosts Configuration ...................................................41 2.5.5 Specifying the DNS Servers .............................................................41 2.5.6 Specifying DNSBL Settings .............................................................42 2.5.7 Exceptions to Mail Delivery .............................................................43 Specifying Illegal Characters in Email Address Formats ...........43 Dropping Mailbox-Only Recipients ............................................44 Deleting Bounced Notifications ..................................................44 2.5.8 Miscellaneous Relay Settings ...........................................................45 Delivery Status Notifications ......................................................46 Alternate Lookups .......................................................................46 Load Balancing by Randomizing Order of MX Hosts ................47 Received Headers Content ..........................................................47 SMTP Relay Delay and Non-Delivery Notifications Sent .........48 2.5.9 Network Connections Concepts ........................................................49 Understanding Internal vs. External Networks ...........................50 Rejecting Connections From Malicious Clients .........................50 2.5.10 Domain-Based Authentication Protocols ..........................................51 Sender Policy Framework ...........................................................52 Microsoft’s Caller ID ..................................................................53 2.5.11 Setting Up Network Connections .....................................................54 Editing Network Connections .....................................................57 2.5.12 Mail Routing Rules Overview ..........................................................57
2.6
2.7
2.8
Servers, Routing Rules and TLS ................................................. 58 Configuring Email Firewall To Prevent Open Relaying ............ 59 2.5.13 Setting Up Mail Routing Rules ......................................................... 60 Setting Up Exact Matching for a Domain ................................... 65 Best Match Algorithm and Wildcards ........................................ 66 Editing Routing Rules ................................................................. 66 2.5.14 Address Rewriting Concepts ............................................................ 67 Address Rewriting Rules ............................................................ 68 Match Specifiers ......................................................................... 68 Rewrite Actions ........................................................................... 69 Matching and Substitution Examples ......................................... 70 A Complete Example .................................................................. 70 2.5.15 Setting Up Address Rewriting .......................................................... 71 Creating Custom Address Rewriting Rules ................................ 74 2.5.16 Testing Address Rewriting ............................................................... 75 2.5.17 SMTP Relay and Message Retry Configuration .............................. 76 2.5.18 Troubleshooting the SMTP Relay Service ....................................... 76 SMTP Relay Service Not Accepting Messages .......................... 76 Email Firewall Relay Not Identifying Itself Properly ................. 77 Troubleshooting Outbound Message Backlogs .......................... 78 Troubleshooting TLS .................................................................. 80 Setting Up Anti-virus and Anti-spam ........................................................... 80 2.6.1 Setting Up Anti-virus and Anti-spam Downloads ............................ 82 Virus Scanning Heuristics ........................................................... 84 2.6.2 Setting Up Dynamic Anti-spam Service Settings ............................. 84 Adding Spam Categories to Scanned Messages ......................... 85 Do Not Scan Messages Received From Internal Networks ........ 86 Do Not Scan Messages Larger Than 200 KB In Size ................. 86 Setting Up Global Policy Settings ................................................................ 87 2.7.1 Setting Up Peak Time for Policy Actions ......................................... 87 2.7.2 Setting Up Archive for Policy Actions ............................................. 88 Archiving Options for Virus-Infected Messages ........................ 90 2.7.3 Setting Up Other Global Policy Options .......................................... 91 Scanning Bytes of Non-Text Attachments .................................. 93 Limitations in Scanning Non-Text Attachments ........................ 93 Marking Text Parts That Use Unsupported Character Sets ........ 94 Marking Messages With Invalid MIME Structure or Illegal Character Encoding as Decomposition Failures ............................ 94 Isolating BCC recipients on Separate Copies of the Message .... 95 Quarantining Messages That Grow to Excessive Size ................ 96 Quarantining Deeply Nested MIME Messages .......................... 96 2.7.4 Setting Up Policy-based Routing ...................................................... 97 Avoiding Infinite Message Looping ........................................... 99 Setting Up Event Logging .......................................................................... 100 2.8.1 Setting Up Event Logging .............................................................. 101 Contents v
2.9
Chapter 3
Working With Queues 3.1 3.2
3.3
3.4
3.5
vi Contents
2.8.2 Setting Up Centralized Event Logging and Reporting ...................101 Prerequisites to Enabling Centralized Event Logging and Reporting for Email Firewall Systems in a Domain .....................................101 Prerequisites to Enabling Centralized Event Logging and Reporting for Email Firewall Systems in Workgroups .................................102 Enabling and Setting Up Centralized Event Logging and Reporting ...............................................................................103 Other Setup Tasks .......................................................................................105 2.9.1 Setting Up Message Queues ...........................................................105 What is the Personal Quarantine Manager? ..............................106 2.9.2 Setting Up Reporting ......................................................................106 2.9.3 Setting Up Policies ..........................................................................106 2.9.4 Setting Up the Directory .................................................................107 2.9.5 Setting Up Security .........................................................................107 2.9.6 What is the Dynamic Anti-spam Service? ......................................107 2.9.7 What is Secure Redirect? ................................................................108 2.9.8 What is Secure Messenger? ............................................................108 2.9.9 Setting Up Proxy Servers ................................................................109 Setting up HTTP Proxy Server .................................................111 Setting up FTP Proxy Server .....................................................111
113
Message Queues Status ..............................................................................114 Setting Up Message Queues .......................................................................116 3.2.1 Queue Configuration .......................................................................119 3.2.2 Setting Up Queue Actions ..............................................................120 Resetting Queue Actions ...........................................................121 3.2.3 Setting Up Queue Aging .................................................................122 3.2.4 Setting Retry Queue Retry Intervals ...............................................123 3.2.5 Creating Quarantine Custom Queues ..............................................125 Setting Up Queue Searches ........................................................................126 3.3.1 Limitation on Queue Search Results ...............................................126 3.3.2 Creating a Queue Search .................................................................127 3.3.3 Modifying Queue Searches .............................................................130 3.3.4 SQL Jobs and Deleting Messages in Queue Filters ........................130 Working With Messages in the Queues .....................................................131 3.4.1 Deleting Multiple Messages From the Queues ...............................132 3.4.2 Viewing Individual Messages in the Queues ..................................132 Quarantine Queue Management .................................................................133 3.5.1 Setting Up a Model Spam Review Process .....................................134
3.5.2 Additional Queue Management Tips .............................................. 134 Use Bulk Actions on Messages ................................................. 134 Use Quarantine Queue Threshold Actions ................................ 135 Use Quarantine Queue Aging ................................................... 135 Create Quarantine Queue Custom Queues ................................ 135 3.5.3 Checking the Quarantine Queue for Inbound Messages ................ 135 3.5.4 Stopping Inbound Message Acceptance ......................................... 136 3.5.5 Getting Rid of Undeliverable Bounced Messages .......................... 137 3.6 Troubleshooting Inbound and Outbound Queues ...................................... 138 Stopping the SMTP Relay From Accepting More Messages ... 138 3.6.1 Troubleshooting Inbound Queue Backups -- Full File Groups ...... 139 3.6.2 Troubleshooting Outbound Queue Backups ................................... 141 3.7 Using Personal Quarantine Manager .......................................................... 142 3.7.1 Personal Quarantine Manager Server ............................................. 143 3.7.2 Quarantine Summary Notification Messages ................................. 144 QSNs and Quarantine Queue Aging ......................................... 144 User Requests for Access to Quarantined Messages ................ 145 Identifying QSN Message Headers ........................................... 145 PQM Server Responses ............................................................. 146 3.7.3 Setting Up PQM Server Settings .................................................... 147 Testing the PQM Server ............................................................ 148 3.7.4 Specifying User Domains To Receive QSNs ................................. 149 Editing and Removing User Domains ...................................... 150 3.7.5 Setting Up the QSN Format and Schedule ..................................... 151 Enabling QSN On-demand Access and White-listing .............. 154 Turning Off QSN Deliveries ..................................................... 155 QSN Format Issues with Outlook Express 6 on Windows 2003 ............................................................................. 156 3.7.6 Setting Up QSN Access Restrictions .............................................. 156 Tags and Outbound Security Policies ....................................... 157 Procedures for Setting Up QSN Tags ....................................... 158 Editing and Deleting QSN Access Tags ................................... 160 3.8 PQM Reports Sent to Users ....................................................................... 161 3.8.1 HTML Format QSN Blocked Messages Reports ........................... 161 3.8.2 Text Format QSN Blocked Messages Reports ............................... 165 3.8.3 User Requests for QSNs “On-Demand” ......................................... 166 3.8.4 User Requests for “White List” ...................................................... 168 3.8.5 Bookmarking the QSN Update URL .............................................. 168 3.8.6 PQM and Message Security Concerns ........................................... 169 Sending QSNs in the Clear ....................................................... 169 Message Contents Not Displayed ............................................. 170 3.9 Using Policies with PQM ........................................................................... 171 3.9.1 Policies to Prevent QSNs from Being Sent to Specific Users ........ 173 3.9.2 QSNs for Recipients with Multiple Aliases .................................... 174 3.10 Personal Quarantine Manager Maintenance .............................................. 175 Contents vii
3.10.1 Changing the PQM Server Account Password ...............................175 3.10.2 PQM Tables that Must Not be Replicated ......................................175 3.10.3 PQM and IIS Server Configuration Issues ......................................176 Authentication Methods ............................................................176 PQM Server Anonymous Account ............................................177 Application Protection ..............................................................177 Secure HTTP Access .................................................................178 PQM Server Logging ................................................................179 Diagnosing Authentication Problems .......................................179 3.11 Troubleshooting the PQM ..........................................................................181 3.11.1 PQM Notification Service “Not Running” or Not Shown ..............181 3.11.2 Localization Issues and PQM Message Display .............................182 3.11.3 Duplicate Notifications from Notification Service .........................182 3.11.4 Personal Quarantine Manager FAQs ..............................................183
Chapter 4
Working With the Event Log 4.1
4.2 4.3
4.4
Chapter 5
viii Contents
Setting Up Email Firewall Event Logging .................................................186 4.1.1 Setting up Global Event Log Settings .............................................187 4.1.2 Setting Up Logging Levels .............................................................187 4.1.3 Setting Up Event Aging ..................................................................188 4.1.4 Event Log Export ............................................................................189 4.1.5 Cleanup Jobs and Message Processing ...........................................189 4.1.6 SQL Server Job Events Not Reported ............................................190 Searching the Event Log ............................................................................190 Using Event Log Filters ..............................................................................192 4.3.1 Creating Event Log Filters ..............................................................192 4.3.2 Creating Custom Events .................................................................194 Searching for Message Events ....................................................................199
Understanding Policies 5.1
185
203
Policy Overview .........................................................................................204 5.1.1 Definitions .......................................................................................204 Policy .........................................................................................204 Rules ..........................................................................................204 Actions ......................................................................................204
5.2
5.3
5.4
5.1.2 Example .......................................................................................... 205 Name ......................................................................................... 206 Catch Conditions ....................................................................... 206 Exclude Conditions ................................................................... 207 Actions ...................................................................................... 208 Backup Actions ......................................................................... 209 Summary ................................................................................... 209 Policy Categories and Types ...................................................................... 210 5.2.1 Basic Mail Filtering Policy Types .................................................. 211 Random Selection ..................................................................... 213 5.2.2 Attachments Policy Types .............................................................. 215 File Attachment Stripping ......................................................... 215 Convert UUencoded Attachments to MIME Format. ............... 216 5.2.3 LDAP Policy Types ........................................................................ 216 5.2.4 Virus Policy Types ......................................................................... 217 Infected Message ....................................................................... 217 Clean Stamp Uninfected Messages ........................................... 217 5.2.5 Security Policy Types ..................................................................... 217 5.2.6 SPN Policy Types ........................................................................... 218 5.2.7 Headers Type Policies .................................................................... 218 Remove MIME Headers ........................................................... 219 Remove Hostnames and Subdomains From MIME Headers ... 219 Normalize Email Addresses in MIME Headers ........................ 219 Message Header Fields ............................................................. 219 Email Firewall Directory ........................................................................... 220 5.3.1 Directory Objects ............................................................................ 220 Folders ....................................................................................... 221 Domain Records ........................................................................ 221 Default Domain Record ............................................................ 221 User Records ............................................................................. 222 5.3.2 Default Directory Structure ............................................................ 222 All Folder .................................................................................. 223 External Folder .......................................................................... 223 Internal Folder ........................................................................... 224 5.3.3 Viewing Policies Applied to Directory Objects ............................. 224 5.3.4 Adding New Directory Objects ...................................................... 224 Adding Folders .......................................................................... 225 Adding Domain Records ........................................................... 227 Adding User Records ................................................................ 228 5.3.5 How Policies and User Records Work Together ............................ 231 5.3.6 Using LDAP Import ....................................................................... 232 How Email Firewall Applies Policies ........................................................ 233 5.4.1 Hierarchy of Message Actions ........................................................ 233 Non-hierarchical Policy Actions ............................................... 235 Timing and Ordering of Policy Action Application ................. 235 Contents ix
5.5
5.6
5.7
x Contents
5.4.2 How Severity of Action Affects Policy Enforcement .....................235 5.4.3 Understanding Policy Inheritance and Overrides ...........................237 5.4.4 Policy Inheritance Example ............................................................237 5.4.5 Policy Override Example ................................................................238 5.4.6 Preventing Policy Overrides ...........................................................238 General Policy Planning Considerations ....................................................240 5.5.1 Inheritance Is From Parent Folders Only ........................................240 5.5.2 When to Use Sender Polices ...........................................................240 5.5.3 When to Use Recipient Policies ......................................................241 5.5.4 Where To Apply Anti-spam Policies ..............................................241 Using a Recipient Policy for Spam Example ............................243 5.5.5 Use Directory Folder Policies Whenever Possible .........................243 Default Policies and Folders .......................................................................245 5.6.1 General Rules About Policy Application ........................................245 5.6.2 Policies Applied to the All Folder ..................................................246 Decompression Errors ...............................................................246 Decomposition Errors ..............................................................246 Partial Message Block ...............................................................247 Virus Hoax Block ......................................................................247 5.6.3 Additional Policies Applied to the External Folder ........................248 Outbound Size Deferral .............................................................248 5.6.4 Additional Policies Applied to the Internal Folder .........................248 EXE Blocking ...........................................................................250 Inbound Size Deferral ...............................................................250 Infected Message (Recipient) ....................................................250 Infected Message (Sender) ........................................................250 Long Filename Quarantine ........................................................251 Multimedia Attachments Deferral .............................................251 Outbound Message Archival .....................................................251 Résumé Block ...........................................................................251 Sensitive Info Review ...............................................................252 5.6.5 HIPAA Compliance Policy .............................................................252 5.6.6 Dynamic Anti-spam Service Policies .............................................252 Spam - DAS: Adult ...................................................................252 Spam - DAS: High Confidence .................................................253 Spam - DAS: Moderate Confidence .........................................253 Policy Building Tools .................................................................................253
Chapter 6
Creating and Editing Policies 6.1 6.2
6.3
255
Introduction to Policy Building .................................................................. 256 6.1.1 Using Multiple Policy Actions ....................................................... 256 Lists and Tags ............................................................................................. 257 6.2.1 Cautions on Using Text Wildcards in Lists .................................... 258 6.2.2 Word Lists ...................................................................................... 258 Using Wildcards in Word Lists ................................................. 259 Word Lists and Wildcards Caution ........................................... 260 Word List Construction and Weighted Word List Syntax ........ 260 Validating and Saving Word Lists Using Advanced Add ........ 261 6.2.3 Advanced Add, Character Sets and Lists ....................................... 262 6.2.4 Using Regular Expressions in Word Lists ...................................... 262 6.2.5 Creating a Word List Example ....................................................... 263 Plan the New Word List First ................................................... 263 Associate the External Word List and Create the List .............. 264 6.2.6 Address Lists .................................................................................. 265 Address Lists and Wildcards Caution ....................................... 266 6.2.7 Creating an Address List Example ................................................. 266 6.2.8 Attachment Lists ............................................................................. 268 Viewing File Types for Attachment Lists ................................. 269 Using Advanced Add and Wildcards in Attachment Lists ....... 270 Attachment Lists and Wildcards Caution ................................. 270 Special Considerations for File Names and File Types ............ 271 6.2.9 Creating an Attachment List Example ............................................ 271 6.2.10 Exporting Lists ................................................................................ 273 6.2.11 Tags ................................................................................................. 274 6.2.12 Creating a New Tag Example ......................................................... 275 Advanced Add for Tags ............................................................ 277 Annotations ................................................................................................ 278 6.3.1 Global Settings for In-line Annotations .......................................... 279 Using Placeholders in Global In-line Annotations ................... 280 6.3.2 Using Placeholders in Policy Annotation Text ............................... 281 6.3.3 Skipping Annotation Text ............................................................... 281 6.3.4 Annotating All Outbound Mail with a Disclaimer ......................... 282 Plan the Outbound Disclaimer Policy ....................................... 283 Create the Outbound Disclaimer Annotation ............................ 284 Create the Outbound Disclaimer Policy .................................... 285 Apply the New Disclaimer Policy to the Policy Hierarchy ...... 285 Test the New Policy .................................................................. 286
Contents xi
6.4
Notifications ...............................................................................................287 6.4.1 Global Notification Settings ...........................................................288 Notification Routing ..................................................................289 Default Global Notification Settings .........................................289 6.4.2 Creating a New Notification for a Policy Action ............................290 Avoiding Duplicate Notifications .............................................292 Dropped or Returned Message Notification Option .................293 Virus in Message Notification Option ......................................293 6.5 Using Events as Policy Actions ..................................................................295 6.6 Creating Policies .........................................................................................296 6.6.1 Viewing the Default Policies ..........................................................296 Editing Default Policies to Scan HTML Tags ..........................296 6.6.2 Creating a New Policy Example .....................................................298 6.7 Applying the Policy to a Directory Object .................................................301 6.7.1 Adding Policies to Directory Objects .............................................302 6.8 Using Virus- and File-Stripping Policies ...................................................303 6.8.1 How Virus-Stripping Policies Work ...............................................303 6.8.2 How File-Stripping Policies Work ..................................................304 6.9 Policy Protection Against New Viruses .....................................................305 6.9.1 Defining Content-Based Policies for Viruses .................................305 Creating the New Policy ...........................................................305 Applying the New Policy to the Directory ................................308 Testing the New Policy .............................................................309 6.9.2 Using Policies to Detect HTML Mobile Code ...............................310 Catching Script Tags .................................................................310 6.9.3 Troubleshooting Virus Protection ...................................................311 Common Ways Email Firewall is Misconfigured .....................311 Other Channels for Virus Infiltration ........................................312 6.10 Using Headers Type Policies ......................................................................313 6.11 Using DAS Message Properties .................................................................315 6.11.1 Default Dynamic Anti-spam Service Policies ................................315 6.11.2 What a DAS Policy Should Look For .............................................316 DAS Message Properties Added ...............................................317 DAS Message X-headers Added ...............................................317 Acting on Spam Messages ........................................................318 6.11.3 Using the Broadcast Content Rating in Policies .............................319 6.11.4 Applying the Anti-spam Policy to the Directory ............................319 6.11.5 Testing the Anti-spam Policy ..........................................................320 Special Test Keywords for Testing an Anti-spam Policy .........321 6.11.6 Creating a Broadcast Exception Policy ...........................................321 6.12 Troubleshooting Policy Enforcement .........................................................324 6.12.1 Policy Configuration Errors ............................................................324 Policy Applied to Wrong Folder ...............................................324 Policy Enabled at Wrong Directory Level ................................324 Policy Disabled .........................................................................324 xii Contents
Conditions Not Configured Properly ........................................ 324 Directory Object Has Not Inherited a Policy ............................ 324 Exclude Conditions Not Configured Properly .......................... 325 Two Similar Policies Specify Different Actions ....................... 325 Policy Should Be Recipient (or Sender) ................................... 325 Address List Uses Non-Word Characters ................................. 325 Annotations Not Skipped .......................................................... 325 Signed Messages Not Being Caught ......................................... 326 6.12.2 Other Problems ............................................................................... 326 Virus Pattern File Needs to Be Updated ................................... 326 Virus Scan Engine Needs to Be Updated .................................. 326 SMTP Relay Service Is Stopped ............................................... 326 Policy Enforcement Not Enabled .............................................. 326 List Not Configured Correctly .................................................. 327 Notification Address Is Incorrect .............................................. 327 Queue Backups ......................................................................... 327
Chapter 7
Dynamic Anti-Spam Service 7.1
7.2
7.3 7.4
7.5
329
Introduction to Stopping Spam .................................................................. 330 7.1.1 At-the-Relay Protection .................................................................. 331 7.1.2 Incoming Message Classification ................................................... 331 7.1.3 Acting on Spam Messages .............................................................. 332 Dynamic Anti-spam Service Overview ...................................................... 332 7.2.1 Email Firewall Spam Analysis Engine ........................................... 332 7.2.2 Email Firewall Download Service .................................................. 333 7.2.3 Tumbleweed Message Protection Lab ............................................ 333 Dynamic Anti-Spam Service Architecture ................................................. 334 7.3.1 Mail Flow with the Dynamic Anti-spam Service ........................... 334 How the Engine Processes Messages ......................................................... 337 7.4.1 What the Engine Looks For ............................................................ 337 7.4.2 Messages Not Analyzed by the Service .......................................... 338 Large Messages ......................................................................... 338 Secure Response Service Messages .......................................... 338 SPN or Encrypted Messages ..................................................... 339 7.4.3 Internal Message Analysis .............................................................. 339 Message Categorization ............................................................................. 340 7.5.1 Message Assessment and Properties Added ................................... 340 What the Spam Confidence Rating Means .............................. 341 What the Spam Content Rating Means ..................................... 341 7.5.2 Catching Dubious Messages ........................................................... 342 7.5.3 Upgrades, X-Headers and Message Properties ............................... 342 Contents xiii
7.6
Dynamic Anti-spam Service Administration .............................................343 7.6.1 Spam Analysis Engine Maintenance ..............................................344 7.6.2 SMTP Relay Routing Option Behavior ..........................................344 7.6.3 Enabling and Disabling the Service ................................................344 Moving All Messages Out of the Spam Analysis Queue ..........345 7.6.4 Enabling DAS X-headers ................................................................345 Spam Filter Version Identifier ..................................................345 7.6.5 Removing Internal Mail From Engine Processing ..........................346 7.6.6 Adding Large Messages to Engine Processing ...............................346 7.6.7 License Changes And License Events ............................................347 7.6.8 Error Handling in the Spam Analysis Engine .................................347 7.6.9 Performance Counters .....................................................................348 Preliminary Steps Required for Log Mode ...............................349 Setting Up a Spam Analysis Engine Counter ...........................349 Starting a Spam Analysis Engine Counter ................................350 Stopping a Spam Analysis Engine Counter ..............................350 7.6.10 Spam Analysis Engine Event Log Events ......................................351 7.7 Dynamic Anti-spam Filter Downloads .......................................................351 7.7.1 Downloading Filter Data From the FTP Server ..............................351 7.7.2 Updating the Email Firewall Database Tables ................................352 7.8 Download Service Maintenance .................................................................353 7.8.1 Manually Checking for Updates .....................................................353 7.8.2 Rolling Back To An Earlier Filter Data Version ............................353 7.8.3 Removing A Corrupted Filter Version ..........................................353 7.8.4 Increasing MMSConfigData Filegroup Size ..................................354 7.8.5 Troubleshooting Updates ................................................................354 7.9 The Tumbleweed Message Protection Lab ................................................355 7.9.1 Message Protection Lab Tools ........................................................356 7.9.2 Submitting Examples To the Lab ...................................................356 How To Forward Unmarked Spam ...........................................357 Microsoft Outlook and Netscape Users ....................................357 Automating Spam Submittal For Your Users ...........................357 Submitting False Positives ........................................................359 Submitting False Positives Using Email Firewall Web Admin 359 7.10 The Anti-spam Toolbox .............................................................................360
xiv Contents
Chapter 8
Email Encryption and Authentication Overview 363 8.1 8.2
8.3
8.4 8.5
8.6
Introduction to Email Encryption and Authentication in EMF .................. 364 S/MIME and OpenPGP Overview ............................................................. 365 8.2.1 Email Firewall and S/MIME .......................................................... 366 8.2.2 Email Firewall and OpenPGP ......................................................... 368 Email Firewall Gateway-to-Gateway Security .......................................... 369 8.3.1 Understanding Local Secure Domains ........................................... 370 8.3.2 Setting up SPN Links ...................................................................... 371 8.3.3 Certificate Import and Export ......................................................... 372 8.3.4 The Email Firewall SPN-Type Policies .......................................... 372 Non-SPN Message Received From SPN Domain (Inbound) ... 372 Imperfect SPN Message Received (Inbound) ........................... 372 Unable to Encrypt and Sign to SPN Domain (Outbound) ........ 372 Email Firewall Security using TLS ............................................................ 373 TLS Certificate Requirements .................................................. 374 Email Firewall Server-to-Client Proxy Security ........................................ 375 8.5.1 How Email Firewall Performs Proxy Security ............................... 377 Proxy Encryption ...................................................................... 379 Proxy Decryption ...................................................................... 380 Proxy Signature ......................................................................... 380 Proxy Verification ..................................................................... 380 Automatic Lookup of User Certificates .................................... 381 8.5.2 Email Firewall and Automatic Certificate Association. ................. 382 Policy Usage ............................................................................. 382 New Certificates ........................................................................ 383 Policy Limitations ..................................................................... 383 Root Key Purpose ..................................................................... 383 8.5.3 The Email Firewall Proxy Security Policy Types .......................... 384 Proxy Decrypt and Verify ......................................................... 384 Proxy Encrypt and/or Sign ........................................................ 384 Automatic Certificate Association (for S/MIME only) ............ 384 Unencrypted Message Filter ..................................................... 385 Client Encryption and Signature ............................................... 385 Email Firewall Client-to-Client Security ................................................... 385 8.6.1 “Allow” Client-to-Client Security Policies .................................... 387 Plaintext Access ........................................................................ 387 Understanding Plaintext Access ................................................ 388 Allow Security Stripping .......................................................... 388 8.6.2 “Require” Client-to-Client Security Policies .................................. 389 Unencrypted Message Filter Policy .......................................... 389 8.6.3 The Client Encryption and Signature Policy .................................. 390 Contents xv
8.7
8.8
8.9
8.10
8.11 8.12
8.13 8.14
xvi Contents
The Sender Signature Policy Type .............................................................391 8.7.1 Background .....................................................................................391 8.7.2 Conceptual Overview ......................................................................392 8.7.3 Email Firewall Signing Certificate Validation ...............................393 Understanding Certificate Harvesting ........................................................394 8.8.1 S/MIME Certificate Harvesting ......................................................394 8.8.2 OpenPGP Key Harvesting ..............................................................394 Understanding Certificate and PGP Key Responders ................................395 8.9.1 Certificate Responder and Server Certificates ................................395 8.9.2 Certificate Responder and Proxy Certificates .................................396 8.9.3 Understanding PGP Key Responder ...............................................396 Third-Party Certificates and Email Firewall ..............................................397 8.10.1 Supported Third-Party Server S/MIME Certificates ......................398 8.10.2 Third Party TLS Certificate Requirements .....................................399 8.10.3 SMG Mode Certificates ..................................................................400 Third Party PGP Keys and Email Firewall .................................................400 Understanding Certificate Rollovers ..........................................................401 8.12.1 Server Certificate Expiration and Proxy Security ...........................402 8.12.2 Certificate Rollover Coordination Required ...................................403 8.12.3 Certificate Rollover Preparation Checklist .....................................404 8.12.4 Certificate Rollover Process Concepts ............................................404 Generate or Import the New Certificate ....................................404 Distribute The New Certificate .................................................405 Associate the New Certificate with the Local Secure Domain .405 Complete the Rollover ..............................................................406 Certificate Rollover Completion Wrap-Up and Consequences 407 8.12.5 Proxy PGP Key Rollover ................................................................407 The PGP Trust Model .................................................................................408 Trust and Interoperability of S/MIME Certificates ....................................408 8.14.1 Understanding Key Size Issues .......................................................409 8.14.2 Understanding Root Key Purposes .................................................411 8.14.3 Understanding S/MIME Interoperability Issues .............................412 Trusting a Certificate .................................................................412 Trusting Self-Signed Certificates ..............................................412 Associating an Email Address with a Certificate ......................413 Associating Self-Signed Certificates .........................................413 Understanding Server or Role Certificates in Email Firewall ..413 Understanding Proxy Certificates in Email Firewall ................414 8.14.4 Email Firewall S/MIME Certificate Verification ...........................416 8.14.5 Establishing Trust Relationships .....................................................416 8.14.6 Certificate Authorities .....................................................................417 8.14.7 Certificate Revocation Lists ............................................................419 Obtaining CRLs ........................................................................419 Scheduling CRL Downloads .....................................................420
8.14.8 Email Firewall and CRL Distribution Points .................................. 420 8.14.9 Email Firewall and CRL Processing Precedence ........................... 421 8.15 Frequently Asked Questions ...................................................................... 422 8.16 Commonly Used Security Terms ............................................................... 424 Certificate .................................................................................. 424 Certificate Authority ................................................................. 424 Certification Practice Statement ................................................ 424 Certificate Revocation List (CRL) ............................................ 424 CRL Distribution Point ............................................................. 424 Chain Trust, or Trust According to Certificate Status .............. 425 Decryption ................................................................................. 425 Digital Signature ....................................................................... 425 Encryption ................................................................................. 425 Fingerprint ................................................................................. 425 Key ............................................................................................ 425 OpenPGP ................................................................................... 425 Private Key ................................................................................ 426 Public Key ................................................................................. 426 S/MIME .................................................................................... 426 SMG .......................................................................................... 426 SPN ........................................................................................... 426 TLS ........................................................................................... 427
Chapter 9
Security Configuration 9.1
9.2
429
Setting Up Email Firewall Security ........................................................... 430 9.1.1 Email Firewall Security Prerequisites ............................................ 431 9.1.2 Using the Email Firewall Security Setup ........................................ 432 Setting Up Key Pairs and Certificates for S/MIME ................................... 433 9.2.1 Generating an Email Firewall Certificate and Key Pair ................. 434 9.2.2 Sharing the Certificate and Root Key ............................................. 435 Exporting the Certificate and Root Key .................................... 436 Publishing the Certificate as a Root Key .................................. 436 9.2.3 Enabling Email Firewall Certificate Responder ............................. 437 What an External User Must Do to Invoke Certificate Responder ................................................................... 437 9.2.4 Importing Third-Party Server Certificates ...................................... 438 Entrust-Specific Requirements for Certificates ........................ 438 From Entrust Certificate and Private Key to PKCS#12 File .... 439 VeriSign-Specific Requirements for Certificates ..................... 439 9.2.5 Importing a PKCS#12 File Into Email Firewall ............................. 440
Contents xvii
9.3
9.4 9.5
9.6
9.7 9.8
xviii Contents
9.2.6 Obtaining Certificate Authority Root Certificates ..........................440 Obtaining Entrust Root Certificates ..........................................441 Obtaining Verisign Root Certificates ........................................441 Setting Up PGP Keys .................................................................................442 9.3.1 Generating a PGP Proxy Domain Key ............................................443 9.3.2 Enabling Email Firewall PGP Key Responder ...............................444 What an External User Must Do to Invoke PGP Key Responder .....................................................................444 9.3.3 Importing PGP Keys Into Email Firewall .......................................445 Setting Up Certificates for TLS ..................................................................445 9.4.1 Creating a TLS Message Exchange Policy .....................................448 Setting Up for Sender Signature Policies ...................................................451 9.5.1 Administrator Actions Required .....................................................451 9.5.2 Expected Signing Behaviors ...........................................................454 9.5.3 Troubleshooting Sender Signature Policies ....................................456 Setting Up a Secure Public Network ..........................................................458 9.6.1 Defining and Associating Local Secure Domains ..........................458 Editing a Local Secure Domain ................................................460 9.6.2 Enabling SPN Links ........................................................................461 Requesting an SPN Link From External Email Firewall Servers .................................................................461 9.6.3 Setting Up Email Firewall to Respond to SPN Links .....................463 Checking For and Accepting SPN Links ..................................465 9.6.4 Verifying the SPN and Security for the Domain ............................466 9.6.5 Creating a Policy to Check for Successful SPN .............................467 Setting Up for SMG Mode .........................................................................471 9.7.1 Set Up Differences in SMG Mode ..................................................471 Setting Up S/MIME Proxy Security ...........................................................474 9.8.1 Configuring S/MIME Proxy Security Checklist .............................474 9.8.2 Configuring S/MIME Proxy Security Example ..............................476 9.8.3 Generating a Key Pair and Certificate ............................................476 9.8.4 Configuring Email Firewall to Use the New Certificate ................477 9.8.5 Exporting and Publishing the Root Certificate ...............................478 9.8.6 Enabling S/MIME Proxy Certificate Usage and Responder ...........479 9.8.7 Creating the S/MIME Proxy Security Policies ...............................480 Creating a Client Encryption and Signature Policy ..................480 Creating a Detect Cert-query Policy for the External Folder ....482 Creating a Proxy Decrypt and Verify Policy ............................484 Creating a Proxy Encrypt and/or Sign Policy ...........................485 9.8.8 Enabling Automatic Certificate Association ..................................490 Setting Root Key Purposes ........................................................492 9.8.9 Creating the User Records ..............................................................494 9.8.10 Exchanging and Verifying Certificates ...........................................495 9.8.11 Completing the Association ............................................................496 9.8.12 Dynamic Lookups in S/MIME Proxy Security ...............................496
9.9
Rolling Over S/MIME Certificates ............................................................ 497 9.9.1 Rolling Over a Certificate ............................................................... 497 Generating or Importing The New Certificate .......................... 497 Distributing The New Certificate .............................................. 498 Associating The Server Certificate With the Local Domain .... 499 Enabling Proxy Partners To Obtain The Proxy Certificates ..... 499 Completing the Certificate Rollover ......................................... 500 9.10 Downloading Certificate Revocation Lists ................................................ 500 9.10.1 Specifying CRL Source and Download Schedule .......................... 501 9.10.2 Specifying the HTTP Proxy Server for Downloads ....................... 502 9.10.3 Manually Invoking CRL Downloads .............................................. 502 9.11 Specifying the CRL DP LDAP Lookup ..................................................... 503 9.12 Setting Up OpenPGP Proxy Security ........................................................ 504 9.12.1 Configuring OpenPGP Proxy Security Checklist ........................... 504 9.12.2 Configuring OpenPGP Proxy Security Example ............................ 506 9.12.3 Generating an Internal PGP Key (Local Key) ................................ 506 9.12.4 Configuring Email Firewall to Use the New PGP Key .................. 507 9.12.5 Creating the OpenPGP Proxy Security Policies ............................. 507 Create a Policy to Detect PGP Keys Sent to EMF Server ........ 508 Creating an Proxy Decrypt and Verify Policy .......................... 509 Creating a Proxy Encrypt and/or Sign Policy ........................... 511 9.12.6 Creating the User Records .............................................................. 516 9.12.7 Exchanging and Verifying PGP Keys ............................................ 517 9.12.8 Completing the Association ............................................................ 518 9.12.9 Putting It All Together .................................................................... 518 9.13 Rolling Over OpenPGP Proxy Domain Keys ............................................ 519 9.13.1 Rolling Over a PGP Key ................................................................. 519 Generating the New PGP Key .................................................. 519 Distributing the New PGP Key ................................................. 520 Associating the Server PGP Key With the Local Domain ........ 520 Enabling Proxy Partners To Obtain The Proxy PGP Key ........ 520 9.14 Setting Up S/MIME and OpenPGP Client-to-Client Security 521 9.14.1 Creating Plaintext Access Policies ................................................. 521 9.14.2 Creating Allow Security Stripping Policies .................................... 524 9.14.3 Creating an Unencrypted Message Filter Policy ............................ 525 Sender-Based Unencrypted Message Filter Solution ................ 527 9.14.4 Creating a Client Encryption and Signature Policy ........................ 528
Contents xix
Chapter 10
Administrative Tools
531
10.1 Email Firewall Directory Tools ..................................................................532 10.1.1 Find User .........................................................................................532 10.1.2 LDAP Import ..................................................................................533 10.2 Setting Up LDAP Directory Imports ..........................................................534 10.2.1 Configuring LDAP Import Mappings .............................................535 Attribute Mapping .....................................................................536 10.2.2 Understanding the Directory Import Sequence ...............................539 Special Considerations When Using Active Directory .............540 10.2.3 Identifying the Data Source for LDAP Import ..............................540 LDAP Import and MS Exchange Issue .....................................544 10.2.4 Configuring a Query for LDAP Import ..........................................545 10.2.5 Configuring a Mapping for LDAP Import ......................................548 10.2.6 The Email Firewall LDAP Import Process .....................................550 10.3 Performing the LDAP Import .....................................................................552 10.3.1 LDAP Import Scheduling ...............................................................553 How Deleting Directory Import Sequences Affects User Records ................................................................................555 10.3.2 Creating LDIF Files ........................................................................555 10.3.3 Stopping Updating of User Records ...............................................557 10.3.4 Cleaning Up the Directory ..............................................................558 10.3.5 Email Firewall LDAP Import Log File ...........................................559 10.4 Using the Command Line Program Tools ..................................................560 10.4.1 MMSLDIFImportConfig ................................................................560 10.4.2 EMFSave .........................................................................................561 10.5 Using the Word List Tester ........................................................................564 10.5.1 Validating Word Lists .....................................................................564 10.5.2 Checking Word List Processing Time ............................................566 10.5.3 Checking Address List Processing Time ........................................567 10.6 Using the PrivateKeyWizard Tool .............................................................568 10.6.1 Specifying a New Password ............................................................569 10.6.2 Inputting a Password to Protect Private Keys .................................571 10.6.3 Importing Private Keys from a PKCS#12 File ...............................574 10.6.4 Importing PGP Keys .......................................................................579 10.6.5 Removing Certificates and PGP Keys ............................................582 10.7 Using the Email Firewall Diagnostics Utility ............................................582 10.7.1 SQL Server Related Tests ...............................................................583 10.7.2 Email Firewall Related Tests ..........................................................584 10.7.3 Windows Related Tests ...................................................................586 10.7.4 Additional Tests ..............................................................................586 10.7.5 EMFDiagnostics Utility in Distributed Installations ......................587 10.7.6 Diagnostic Utility Usage .................................................................587
xx Contents
10.8 Using the EMFDebugLogCapture Tool ..................................................... 590 10.9 Using EMFSave ......................................................................................... 592 10.9.1 EMFSave and Administration Data ................................................ 592 10.9.2 EMFSave and Replication .............................................................. 593 10.9.3 Starting EMFSave ........................................................................... 593 10.9.4 Restoring EMFSave Files ............................................................... 599 Missing Data and Restore Errors .............................................. 601 10.9.5 Using EMFSave in a Cluster Environment .................................... 601 10.10 Using the Email Firewall Update Service .................................................. 602 10.11 Using the Configuration Editor .................................................................. 609
Chapter 11
Email Firewall Reports
611
11.1 Setting Up Email Firewall Reports ............................................................ 612 11.1.1 Global Reports Setup ...................................................................... 612 11.1.2 Reporting Statistics and Queues Issues .......................................... 615 11.2 Volume Reports .......................................................................................... 616 11.2.1 Attachment Volume and Size ......................................................... 617 11.2.2 Message Volume and Size .............................................................. 617 11.2.3 Message Volume by Policy Disposition Report ............................. 618 11.2.4 Attachment Volume for a Specific Attachment Type .................... 619 11.2.5 Virus Type and Volume .................................................................. 619 11.2.6 SPF Volume Report ........................................................................ 620 11.2.7 Caller ID Volume Report ................................................................ 621 11.2.8 Spam Volume Report ..................................................................... 621 Interpreting the Spam Volume Report ...................................... 623 11.3 Frequency Reports ...................................................................................... 624 11.3.1 Frequently Detected Virus .............................................................. 624 11.3.2 Frequent Policy Violation ............................................................... 624 11.3.3 Frequent Receiving Domains ......................................................... 624 11.3.4 Frequent Recipient Policy Violation .............................................. 624 11.3.5 Frequent Sender Policy Violation ................................................... 625 11.3.6 Frequent Sending Domains ............................................................. 625 11.3.7 Frequent Sending IP Addresses ...................................................... 625 11.3.8 Frequent Virus Sender .................................................................... 625 11.3.9 Frequent SPF and Caller ID Violators ............................................ 626 11.3.10Frequent Senders Released from Quarantine ................................. 626 11.4 User Reports ............................................................................................... 627 11.4.1 Attachment Volume for Specific Recipient .................................... 627 11.4.2 Message Volume for Specific Recipient ........................................ 627 11.4.3 Policy Violation for Specific Recipient .......................................... 628 11.4.4 Attachment Volume for Specific Sender ........................................ 628 Contents xxi
11.4.5 Message Volume for Specific Sender .............................................628 11.4.6 Policy Violation for Specific Sender ..............................................628 11.4.7 Virus Detected for Specific Sender .................................................628 11.5 Audit Reports ..............................................................................................629 11.5.1 Directory and Policy Audit .............................................................629 11.5.2 Directory Audit ...............................................................................629 11.5.3 Policy Audit ....................................................................................629 11.5.4 Directory and Policy Audit for a Single User .................................629 11.5.5 Directory Audit for a Single User ...................................................630 11.5.6 Policy Audit for a Single User ........................................................630 11.6 Customizing Email Firewall Reports .........................................................630 11.6.1 Customizing Volume Reports .........................................................631 11.6.2 Customizing Frequency Reports .....................................................632 11.6.3 Customizing User Reports ..............................................................633 11.6.4 Customizing Audit Reports .............................................................634 11.7 Printing and Saving Reports .......................................................................635 11.7.1 Printing Reports ..............................................................................635 11.7.2 Saving Reports ................................................................................636
Appendix A
File Types Scanned
639
A.1 General Overview .......................................................................................640 A.1.1 File Types and File Type Lists Provided ........................................640 A.1.2 Scanning Limitations ......................................................................642 A.1.3 Compressed Files and Embedded Objects ......................................643 Embedded Objects in Microsoft Office Files ............................643 Limitations in File Type Decompression and Decomposition ..644 A.2 “All Supported” File Types ........................................................................645 A.2.1 All Supported Compressed Files ....................................................645 A.2.2 All Supported Database Files ..........................................................645 A.2.3 All Supported Document Files ........................................................646 A.2.4 All Supported Drawing Files ..........................................................647 A.2.5 All Supported Executable Files ......................................................647 A.2.6 All Supported Image Files ..............................................................648 A.2.7 All Supported Multimedia Files ......................................................648 A.2.8 All Supported Password-Protected Archive Files ...........................649 A.2.9 All Supported Password-Protected Files ........................................649 A.2.10 All Supported Presentation Files ....................................................649 A.2.11 All Supported Spreadsheet Files .....................................................650 A.3 Groups ........................................................................................................651 A.3.1 Adobe Acrobat (PDF) .....................................................................651 A.3.2 Adobe Illustrator .............................................................................651 xxii Contents
A.3.3 AutoCAD ........................................................................................ 651 A.3.4 Corel Draw ...................................................................................... 651 A.3.5 Help Files ........................................................................................ 651 A.3.6 Lotus 123 ........................................................................................ 652 A.3.7 Microsoft Excel .............................................................................. 652 A.3.8 Microsoft PowerPoint ..................................................................... 652 A.3.9 Microsoft PowerPoint with Macros ................................................ 652 A.3.10 Microsoft Word .............................................................................. 652 A.3.11 Paradox ........................................................................................... 653 A.3.12 Quattro/Quattro Pro ........................................................................ 653 A.3.13 Windows Bitmap (BMP) ................................................................ 653 A.3.14 WordPerfect .................................................................................... 653 A.4 File Types Recognized ............................................................................... 655 A.5 File Types Scanned .................................................................................... 659 A.5.1 Word Processing Formats ............................................................... 659 Adobe Portable Document Format (PDF) ................................ 660 A.5.2 Picture Formats ............................................................................... 660 A.5.3 Presentation Formats ...................................................................... 661 A.5.4 Spreadsheet Formats ....................................................................... 661 A.5.5 Multimedia Formats ........................................................................ 661 A.5.6 Compression Formats ..................................................................... 662
Appendix B
Code Set Support
663
B.1 Definitions and Concepts ........................................................................... 664 B.1.1 Characters and Code Sets ............................................................... 664 B.1.2 Message Text Parts ......................................................................... 665 B.1.3 Non-ASCII-7 Text in Message Headers ......................................... 665 B.1.4 The Default Recipient Locale ......................................................... 665 B.2 Data In The Email Firewall Database ........................................................ 666 B.2.1 Word List Data ............................................................................... 666 Special Treatment of Japanese Text On Word Lists ................. 667 B.2.2 Issues With Handling Non-English Text ........................................ 667 Personal Quarantine Manager and Character Sets .................... 668 B.3 Extraction of Text From Message Content ................................................ 669 B.3.1 Extraction of Text From Attachments ............................................ 669 B.3.2 Handling Text From Unsupported or Unidentified Code Sets ....... 669 B.3.3 Handling of Unmapped Characters ................................................ 670 B.4 Policy Engine Expected Behaviors ............................................................ 671 B.4.1 Annotations ..................................................................................... 671 Inline Annotations ..................................................................... 671 Attached Annotations ................................................................ 671 Contents xxiii
B.5 B.6 B.7 B.8
Appendix C
B.4.2 Notifications ....................................................................................672 B.4.3 Events ..............................................................................................672 B.4.4 Subject Alteration ...........................................................................673 B.4.5 MIME Header Field Policies ..........................................................673 International Text Usage ............................................................................674 Japanese Character Issues .........................................................675 Message Body and Attachments ................................................................677 Message Subject .........................................................................................678 ISO Tables ..................................................................................................679
Using Regular Expressions
683
C.1 General Issues .............................................................................................684 C.1.1 Using Asterisks ...............................................................................684 Using Question Marks ...............................................................685 C.1.2 Incorrect Usage in Regular Expressions .........................................685 C.2 Operators ....................................................................................................686 C.3 Character Class Operators ..........................................................................687 C.4 Tutorial Examples ......................................................................................690
Appendix D
Creating Custom Reports D.1
693
Creating and Installing a New Report .......................................................694 D.1.1 Summary of Steps ...........................................................................694 D.1.2 Creating and Installing the Report ..................................................694 D.1.3 Example SQL Server Script for Adding Reports ............................696 D.2 Report Customization Section Selection ....................................................698 D.3 Parameter Field Order in the Report ..........................................................699 D.4 Report Categories .......................................................................................701
xxiv Contents
Preface
Welcome to the Tumbleweed Email Firewall™ 6.2 Administrator’s Guide. This guide provides a description of the components, capabilities, and operation of Tumbleweed Email Firewall 6.2. It provides background, conceptual, and procedural information for planning your Tumbleweed Email Firewall installation, and provides instructions for setting up and configuring Email Firewall policies for your organization. This preface contains the following sections: Conventions Used in this Guide................................................xxvi Contact Information and Support ............................................xxvii
xxv
Conventions Used in this Guide The following type and style conventions are used in this guide. Table P.1: Conventions Convention
Meaning
body text
This font is used for regular body text.
Bold
Bold blue text indicates a menu, button, text entry or icon choice.
Italics
Italics indicate a table title, book title, or crossreference.
Command
The Courier New font indicates application code or computer generated text.
Angle brackets indicate a user-specified command line parameter.
http://www.example.com
Small blue print indicates a URL or email link for additional relevant information.
1., 2., 3., ...
Bold blue numbers indicate steps in a procedure. The Note icon signals additional relevant information.
The Warning icon signals important information that may affect the operation of or may be a potential threat to the system. The Tip icon signals a tip that may save time or effort.
xxvi
Preface
Contact Information and Support The following modes of contact can be used for Tumbleweed Global Support assistance.
For Tumbleweed Global Support Table P.2: Global Support Contact Information Type of Contact
Description
Global Support Online
http://www.tumbleweed.com/en/support/
Global Support Email
[email protected]
Global Support Helpline 650-216-2109 Global Support Request http://www.tumbleweed.com/dy/supForm port/request/request_support.php Customer Service,
[email protected] License Keys and Shipping Orders
If possible, log into the Tumbleweed product before contacting a Tumbleweed Global Support representative directly, and have the following information ready: • • •
Product version and Dynamic Anti-spam Update service filter version in use. (Select Status on the main menu and scroll to the License/version tab.) The text of the error or warning message. A description of the problem and attempts made to fix the problem.
Please include your name, email address, company, and server URL in all correspondence.
xxvii
For General Information The following modes of contact can be used for general information. Table P.3: General Contact Information
xxviii
Preface
Type of Contact
Description
World Wide Web
Visit the Tumbleweed Web site for general information and current issues. http://www.tumbleweed.com
Email Address
Send email to the following address:
[email protected]
Telephone
Use the following telephone number for general inquiries: 650-216-2000
Postal Address
Send regular mail to the following address: Tumbleweed Communications Corp. 700 Saginaw Drive Redwood City, CA 94063
1
Introduction
Tumbleweed Email FirewallTM is a content security and policy management solution for Internet email. It integrates multiple protection modules, including access control, spam filtering, content filtering, attachment management, and virus and mobile code scanning to allow administrators to create and enforce SMTP email security policies across an organization. Email Firewall 6.2 is the latest release in the Tumbleweed family of products. It is the email solution for enterprise communications. Email Firewall uses a modular architecture built around a Microsoft SQL Server database. Configuration data, policies, security certificates and keys, directory information, and message meta-data are stored in a central SQL Server database. This database is accessed by Email Firewall components, including one or more Policy Engines, SMTP relays, and other services, deployed on one or more (typically more) computers. With this easily scalable architecture, Email Firewall fits robustly into the enterprise network. This chapter contains the following sections: 1.1 1.2 1.3
Intended Audience ...................................................................... 2 Overview of Email Firewall 6.2 ................................................. 3 Other Documentation ................................................................. 4
1
1.1
Intended Audience This guide is intended for the people who design, plan, and administer email messaging solutions. It outlines the capabilities of Tumbleweed Email Firewall, describes how it works, and provides instructions for deployment and effective use in today’s business organizations. This guide assumes a working familiarity with messaging systems, networking concepts, and server administration. This guide describes what the Tumbleweed Email Firewall is and how to use its features. Included are discussions of email security options, descriptions of the default policies and what they do, and examples designed to help you to understand how to create, apply, and test your own policies. This guide also provides instructions for customizing Email Firewall policies specifically for your organization, and provides examples of such policies at work. Also included are instructions on maintenance administration, troubleshooting, and an overview of the Email Firewall reporting features.
2
Chapter 1: Introduction
1.2
Overview of Email Firewall 6.2 Organizations use Tumbleweed Email Firewall for a variety of reasons. You can use Email Firewall to: • • • • • • • • •
exchange secure email protect against threats introduced by viruses and executable files quarantine suspicious email reduce or eliminate spam and hoax traffic prevent leakage of sensitive and confidential information establish conformance to corporate policy defer large messages to off-peak hours redirect messages to secure Tumbleweed Secure Messenger or IME servers. archive messages for a detailed audit trail of email communication
The administrative functions of Tumbleweed Email Firewall support deployment and management of Email Firewall in large enterprises. The browser-based Web Admin component provides centralized administration of all of the Email Firewall components. Web Admin provides fully functional remote administration, authentication of administrators, and auditing of administrators’ actions. Administrator accounts are role-based to provide multiple levels of administration with granular access to sensitive controls or data. Secure access by multiple remote administrators with only the access privileges specifically granted provides a highly flexible overall enterprise security solution. The modular, Microsoft SQL Server-based architecture allows Email Firewall to be deployed across multiple machines and in multiple remote locations. The SQL Server database management system enables enhanced throughput and centralized management of all Email Firewall data resources. Email Firewall configuration data, policies, certificates, directory information, event log data, and message meta-data are stored on a central SQL Server database server using its relational database. Complete directory support allows policies to be applied globally, to groups, or to individual users. Information stored in LDAP-compliant directories can be easily imported and updated, and used to define to whom email usage policies apply. S/MIME security enables email encryption and authentication using digital certificates and standards, such as S/MIME and Transport Layer Security
1.2 Overview of Email Firewall 6.2
3
(TLS). Using PGP keys instead of certificates, OpenPGP security also enables email encryption and authentication. Mail can be digitally signed and encrypted by Email Firewall for an entire organization, for specified groups within the organization, or for individual users using either S/MIME or OpenPGP security. For more information on using Tumbleweed Email Firewall 6.2, see the Tumbleweed Email Firewall Help link located on each page in Web Admin. for more general information, visit the Tumbleweed Web site at www.tumbleweed.com.
1.3
Other Documentation For additional information about how to install, configure, and administer Email Firewall 6.2, see the following sources: •
•
•
•
4
Tumbleweed Email Firewall Help The Help in the Tumbleweed Email Firewall Web Administration component contains context-sensitive information as well as a Table of Contents and Index available from every page. You can access the Help by clicking the Help button in the Web Admin UI. The Help also contains troubleshooting information and step-by-step instructions for configuration tasks. Tumbleweed Email Firewall 6.2 Release Notes The Tumbleweed Email Firewall 6.2 Release Notes include prerequisites, hardware and software requirements, additional pre-installation and installation instructions, licensing information, new features since the EMF 6.1.1 release, and known limitations. Tumbleweed Email Firewall 6.2 Installation and Upgrade Guide This document provides background and conceptual information for planning your Email Firewall installation, and provides detailed installation instructions. It also provides instructions for upgrading EMF 6.1.1 to Email Firewall 6.2. Tumbleweed Email Firewall Best Practices Guide This document provides information about setting up Email Firewall optimally in large and complex environments. Included is information about SQL Server database setup, inbound and outbound email routing options, load balancing, and backup and failover strategies.
Chapter 1: Introduction
•
•
Tumbleweed Email Firewall Anti-spam Best Practices Guide This document provides additional information about setting up Email Firewall to combat spam. Secure Redirect Administrator’s Guide This Administrator’s Guide describes how to set up the Secure Redirect service to transparently redirect email to a Tumbleweed IME server.
If you are installing Secure Messenger 6.2 with EMF 6.2, see the following sources for information about how to install, configure, and administer Secure Messenger 6.2: •
•
•
•
•
Tumbleweed Secure Messenger 6.2 Release Notes The Release Notes include up-to-date information related to hardware and software requirements, additional pre-installation instructions, licensing information and known limitations. Tumbleweed Secure Messenger 6.2 Administrator’s Guide This guide presents an overview of Email Firewall and describes configuration procedures and administration functions. It describes various use cases, and provides troubleshooting tips for operating Email Firewall 6.2. Tumbleweed Secure Messenger Help The online help in the Secure Messenger 6.2 Web Admin component contains context-sensitive information as well as a Table of Contents and Index available from every page. You can access the Help by clicking the Help button in the Web Admin user interface. The Help also contains troubleshooting information and step-by-step instructions for configuration tasks. Tumbleweed Secure Messenger 6.2 Developer’s Guide This document provides information about branding the Secure Messenger end-user interfaces and integrating third party authentication infrastructure. Tumbleweed Email Firewall 6.2 Administrator's Guide This guide must be read and understood before deployment of Tumbleweed Secure Messenger 6.2 to obtain a comprehensive understanding of the entire Tumbleweed secure email solution.
1.3 Other Documentation
5
6
Chapter 1: Introduction
2
Setting Up Email Firewall Administration
This chapter describes many of the features and tools in the Email Firewall Status page and the Setup links in Web Administration. Use this chapter as a road map for setting up, administering and monitoring Email Firewall. This chapter also contains references to other sections of this guide containing more detailed information about each administrative task. This chapter contains the following sections: 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9
Overview of Administrator Setup Tasks...................................... 8 Administrative Security............................................................... 9 System Status ............................................................................ 14 Setting Up Admin Roles and Accounts ..................................... 21 Setting Up Relays ..................................................................... 32 Setting Up Anti-virus and Anti-spam........................................ 80 Setting Up Global Policy Settings ............................................ 87 Setting Up Event Logging....................................................... 100 Other Setup Tasks ................................................................... 105
7
2.1
Overview of Administrator Setup Tasks Table 2.1 lists the tasks that should be performed to set up and administer Email Firewall in its entirety. It is recommend that you review the concepts and overview sections before performing these tasks. Table 2.1: Overall Setup Tasks
Step
8
Task
Description and Procedures
1
Create additional administrators
2.4 Setting Up Admin Roles and Accounts on page 21
2
(Optional) Set up Centralized Event Logging and Reporting
2.8.2 Setting Up Centralized Event Logging and Reporting on page 101
3
Set up relays
2.5 Setting Up Relays on page 32
4
Set up global policy settings
2.7 Setting Up Global Policy Settings on page 87
5
Set up the Updates
2.6 Setting Up Anti-virus and Anti-spam on page 80
6
Set up the Queues
3.2 Setting Up Message Queues on page 116
7
Set up Personal Quarantine Manager
3.7 Using Personal Quarantine Manager on page 142
8
Set up the Dynamic Anti-spam Service
7.2 Dynamic Anti-spam Service Overview on page 332
9
Set up the Event Log
4.1 Setting Up Email Firewall Event Logging on page 186
10
Set up the Directory
10.2 Setting Up LDAP Directory Imports on page 534
11
Set up Security
9.1 Setting Up Email Firewall Security on page 430
12
Set up Policies
6.1 Introduction to Policy Building on page 256
13
Setup Product Updates
2.9.9 Setting Up Proxy Servers on page 109
Chapter 2: Setting Up Email Firewall Administration
2.2
Administrative Security There are three components of Email Firewall Web Administration security: • • •
Authentication - the process of verifying the identity of the user. Authorization - the process of determining whether the user is permitted to view a specific function or perform a specific action within the system. Auditing - the process of tracking changes and attempted changes to the system.
The Email Firewall program allows the first two components to be defined when setting up administrative roles and accounts. Audit logs provide data for the third. These features provide enterprise-wide administrative control in a multiple-server, multiple-administrator environment. Instructions for setting up administrator roles and accounts can be found in 2.4 Setting Up Admin Roles and Accounts on page 21, and also in the Email Firewall Help.
2.2.1
Web Administration Access Controls Email Firewall provides multiple levels of administration. This design allows you to define different administrative capabilities for different components and allows the Email Firewall Web Admin environment to be partitioned so that multiple people in the organization can manage different subsets of the system. Administrative access is defined by Admin Roles and Admin Accounts. Admin Roles grant access to the capabilities defined by that role. An Admin Account can be granted only one Admin Role. Based on the capabilities assigned to an Admin Role, an administrator can view/modify only the subset of the Email Firewall system allowed by the role’s capabilities. An administrator can perform only the subset of the administrative tasks allowed by the role’s capabilities. At least one administrator must be assigned all capabilities in order to have an administrator who can manage the whole system, including creating additional Admin Roles and Accounts. Instructions for setting up Admin Roles and Admin
2.2 Administrative Security
9
Accounts can be found in 2.4 Setting Up Admin Roles and Accounts on page 21, and also in the Email Firewall Help. For the remainder of this chapter, functions are described assuming the administrator has full administrative privileges unless otherwise noted.
2.2.2
Logging In During Email Firewall installation, an administrator account consisting of name and password is set up. This default admin account with SuperAdmin role is automatically granted the necessary privileges to set up additional administrator accounts and to administer Email Firewall. For instructions on creating additional admin accounts, see 2.4.3 Creating New Administrator Accounts on page 29. To administer Email Firewall you must login to Email Firewall Web Admin. To access the login page, open your browser and type one of the following URLs in the browser address field: The Email Firewall Web Admin component requires the use of JavaScript. When using Internet Explorer, the Active Scripting Option must be enabled. See the Email Firewall 6.2 Installation and Upgrade Guide for instructions. Pop-up dialogs are also used, and must not be blocked.
To login to Email Firewall on a secure server (using a secure server is recommended): https:///emfadmin
To login to Email Firewall on a non-secure server: http:///emfadmin
Setting Up Secure Login To setup Web Admin so that SSL (https) is required:
10
1.
Right-click My Computer and Select Manage.
2.
Click Services and Applications and expand it.
Chapter 2: Setting Up Email Firewall Administration
3.
Click Internet Information Services and expand it.
4.
Right-click the Default Web Site and select Properties.
5.
Select the Directory Security tab.
6.
In the Secure communications group box, click Edit.
7.
Mark the Require secure channel (SSL) checkbox.
8.
Optionally mark the Require 128-bit encryption checkbox.
9.
Click Save.
Figure 2.1: Login Page EMF
When the login page opens, see Figure 2.1, type your Username and Password in the fields and click Login. While logged in you can customize your account preferences, including identity, password, and how many lines are displayed in your browser pages. For instructions, see 2.4.4 Preferences on page 31. Using multiple browser sessions is supported. However, you should start a new instance of the browser to do so. Do not attempt to open multiple browser windows using the same Web Administration session. For security reasons the Web Administration component has a time-out feature. After 60 minutes of inactivity, you are automatically logged out and must log in again to continue.
2.2 Administrative Security
11
2.2.3
Main Menu When you are logged into Web Administration, you will see the name of the SQL server on which Web Administration database resides. This server name displays on the top left of the page under the product name. Under the server name is the main menu. Each main menu item is the name of a major component or administrative tool. See Figure 2.2.
12
Chapter 2: Setting Up Email Firewall Administration
Figure 2.2: Main Menu Overview
Click any menu item to open its main page.
The sections in this chapter: • describe the Email Firewall page accessed by the menu item. • describe the functions available from that page. • when appropriate, refer you to other sections of this guide for more detailed information. The title bar at the top of every page shows the navigation path used to reach the open page. Each underlined page name is a link to that page. The last item is the name of the page you are viewing. To return to a previous page, click its underlined name in the path.
Note: The browser Back, Forward, and Refresh buttons should not be used in Email Firewall Web Admin. Use the main menu and links in the pages to navigate.
2.2 Administrative Security
13
2.3
System Status The System Status page is displayed on login. This page contains the Info and and Email Firewall Services tabs. A review of the information on these tabs alerts you to the current Email Firewall operating status. Alerts, Message Queues
While working with Email Firewall, click Status to return to the Status page.
Underlined headings and text in the Email Firewall Web Admin pages are links to the described page.
2.3.1
Info and Alerts Status This tab contains the Product version and its build number, and if installed, the version information for all Dynamic Anti-spam Service (DAS) Filter and Virus Pattern along with date and time of the lastest update. If installed, this tab also contains the version and build number for either Secure Messenger or Secure Redirect depending on which secure email component is installed. If you need to contact your Tumbleweed Global Support representative you will be requested to provide this information. See Figure 2.3.
14
Chapter 2: Setting Up Email Firewall Administration
Figure 2.3: Info and Alerts Status
The Email Firewall Service Update heading provides a link to a page that provides all available Email Firewall updates (versions, patches or hot fixes) for this system. The Email Firewall Knowledge Base heading provides a link to the Tumbleweed Knowledge Portal where you access Tumbleweed Knowledge Base articles. This page requires a user name and password. To obtain a user name and password, click the New users click here to register for access link. The Email Firewall Services heading provides a quick reference to the status of the services and a convenient link to the Email Firewall Services tab. The Errors & Warnings heading lists the number of errors and warnings generated during the last 24 hours. Click the link after Errors or Warnings to open the Event Log to view, filter and sort these events. The Event Log can be filtered so that only those warning and error events you select are shown in the Event Log. For more information on creating and configuring Event Log filters, see 4.2 Searching the Event Log on page 190.
2.3 System Status
15
Alerts
•
•
•
are displayed for the following conditions:
All Outbound Mail Currently Stopped This alert is displayed when: • the Stop All Outbound Mail checkbox is marked on the Setup > Relay General Settings page. • the value for Maximum Outbound Connections is set to 0 on the Setup > Relay General Settings page. All Inbound Mail Currently Stopped This alert is displayed when: • the Reject All Inbound Connections checkbox is marked on the Setup > Relay General Settings page. • the value for Maximum Inbound Connections is set to 0 on the Setup > Relay General Settings page. • if the Dynamic Anti-spam Service is not installed: the Stop the SMTP relay from accepting incoming messages checkbox is marked (in the Inbound queue setup page) and the Inbound queue threshold is triggered. (The Triggered status is displayed on the Message Queues tab when the queue grows to or exceeds the specified number of messages.) • if the Dynamic Anti-spam Service is installed: the Stop the SMTP relay from accepting incoming messages checkbox is marked (in the Spam Analysis queue setup page) and the Spam Analysis queue threshold is triggered. (The Triggered status is displayed on the Message Queues tab when the queue grows to or exceeds the specified number of messages.) Mail Not Being Routed through Policy Engine This alert is displayed when the Route messages through policy engine (and spam analysis engine if installed and running) checkbox is unmarked on the Setup > Relay General Settings page.
To resolve these alerts, check the settings as applicable. •
16
Expiration of Evaluation License This alert is displayed when: • The Email Firewall evaluation license is about to expire. After expiration, Email Firewall stops all content, spam and virus filtering of incoming and outgoing mail. Email Firewall will continue to act as a relay for the delivery of mail only.
Chapter 2: Setting Up Email Firewall Administration
• •
2.3.2
• The Dynamic Anti-spam Service evaluation license is about to expire. After expiration, the Spam Analysis Engine stops analyzing and tagging messages with DAS message properties or X-headers. Policies that depend on the DAS tagging will not work. To resolve these alerts, obtain a full license from your Global Support Representative. When the anti-virus patterns files are more than 7 days old. When the anti-spam filter files are more than 7 days old.
Message Queues Status The Message Queues tab displays the number of messages currently in the Email Firewall mail queues. See Figure 2.4. Figure 2.4: System Status Message Queues Tab
2.3 System Status
17
The Queue Counts tab displays either the Redirect link or the Secure Messenger link depending on whether you have installed Tumbleweed’s IME server or Secure Messenger to securely deliver your outbound email messages. Figure 2.4 shows the Redirect link.
The queues contain messages that are inbound to or outbound from Email Firewall, messages awaiting preprocessing by the Dynamic Anti-spam Service (if installed), awaiting redirection to a secure Tumbleweed IME server (if installed), awaiting preprocessing by the Secure Messenger (if installed), awaiting retry, and messages that were quarantined, detained, deferred, archived, returned or could not be delivered. The Partition queue contains messages requiring delivery to multiple recipients. For more detailed information on the queues, including how to set them up, see 3.2 Setting Up Message Queues on page 116 and the Email Firewall Help. For a more detailed description of each queue, see Table 3.1 on page 116. Email Firewall is an active system and the Message Count displayed shows the number of messages in the queues when the System Status page was last accessed. The current message count may differ from the number displayed. Use Refresh to update the page to show the most current message count. From the Message Queues tab you can click an underlined queue name to access that queue’s main page and view the messages in that queue. Although the Return, Archive and Partition queues are not configurable, it is useful to occasionally note the number of messages in those queues. An excessive number of messages in those queues could indicate a processing problem that should be investigated. If you notice a large number of messages in the Quarantine Queues, see 3.5.3 Checking the Quarantine Queue for Inbound Messages on page 135 for troubleshooting information.
18
Chapter 2: Setting Up Email Firewall Administration
2.3.3
Email Firewall Services Status The Email Firewall Services tab lists the services that are currently running and those that were running at some point in the past when Web Administration was running. This tab shows the current or past operating status of each service, the host name each service is running on (if applicable), and if available, its IP address. If a service is not currently running or has been uninstalled, a Remove button appears in its Action column. Clicking Remove deletes that service from the Email Firewall Services tab list. However, Remove does not delete or uninstall the service from Email Firewall; it only removes its row from the list on the Email Firewall Services tab. Use the Remove button if you do not want to view the Email Firewall services that are not currently running or that have been uninstalled. Figure 2.5 shows an example of the Email Firewall Services tab. Figure 2.5 shows services as they would appear if installed on the same host. In complex environments it is expected that some of these services will be deployed on different hosts. For the services related to the secure delivery of email messages, either the Email Firewall Secure Redirect service or the Email Firewall Secure Messenger service displays within the Email Firewall Services tab depending on which component is installed, if at all.
2.3 System Status
19
Click Refresh to update the information displayed on the tab. Figure 2.5: System Status Email Firewall Services Tab
If you have installed the Email Firewall SMTP Relay service Inbound partition only, you may not see the SMTP Relay Service status displayed on the Email Firewall Services tab until after the Inbound relay has received messages. This is because the relay does not establish a connection with the database until after the Inbound relay is in use. If you have installed the Secure Messenger with Email Firewall, the Email Firewall Secure Messenger service displays on the Email Firewall Services tab instead of the Email Firewall Secure Redirect service, which is currently shown in Figure 2.5.
20
Chapter 2: Setting Up Email Firewall Administration
Automatic Email Firewall Services Restarts The Email Firewall installer configures the operating system to automatically restart any Email Firewall service that fails unexpectedly. However, if the Policy Engine fails, it is restarted by the Email Firewall Monitor service. If for any reason you disable the automatic restart of services feature, you must be sure to manually restart a service that has stopped.
2.4
Setting Up Admin Roles and Accounts Email Firewall provides multiple levels of administration. The level of administrative authority is determined by the role granted to an administrator account. A role defines what areas of Email Firewall an account can view and what tasks that account can perform. An account can be assigned any role, but only one role can be assigned to any one account. A role is defined by its Access and Capabilities. There are two levels of access and capabilities: High Security and Standard. High security functions include creating additional administrator roles and accounts, and the ability to delete audit events. A role that allows creating additional administrator accounts has complete access to the Email Firewall database. This role should only be assigned to administrator accounts that need this level of access. The most powerful SuperAdmin role provides complete authority to administer Email Firewall operation. This role includes all High Security access and
2.4 Setting Up Admin Roles and Accounts
21
capabilities, and all Standard access and capabilities. Other roles have only the specific capabilities granted by the role. Figure 2.6: Administrator Roles Main Page
One admin account with the SuperAdmin role assigned, and two administrator roles, SuperAdmin and GeneralAdmin, are installed by default. Additional roles and accounts can be created by any account that is assigned the SuperAdmin role. Admin roles should be created first, because an admin account must be assigned a role when it is created. See 2.4.2 Assigning and Creating Admin Roles on page 27 for instructions. While an admin account can be created with no role, the account when logged on has no capabilities to manage Email Firewall. Once an admin account is created, that account cannot change its own role.
22
Chapter 2: Setting Up Email Firewall Administration
2.4.1
Admin Roles Access and Capabilities When an administrator logs onto Email Firewall, the account's role defines the privileges available to that administrator. In the Web Admin UI, options are hidden if the admin’s role does not grant privileges to access those options. Admin roles consist of two levels of access: High Security and Standard. There are two High Security access functions: •
Full Access
•
Delete Audit Events
Only administrators who are specifically granted the high security Full Access privilege can create, edit and delete roles and accounts. The Full Access privilege also has the capability of setting up Centralized Event Logging and Reporting. Only administrators who are specifically granted the high security Delete Audit Events can modify the audit log retention time that automatically deletes audit events.
SQL Server Access Requirements for SuperAdmin The SQL Server fixed server role sysadmin is given to any Email Firewall Admin Account with the Full Access capability.This role can be downgraded or upgraded only by using Enterprise Manager or a SQL script. Once the sysadmin role is removed from an Admin Account, the account will not be able to create other Admin Accounts, even though the Web Admin might show this Account has the capability. This Admin will however be able to perform other operations in Web Admin. If you want this Admin Account to be able to create other Admin Accounts, you must give the sysadmin role back to the Admin Account. To remove the sysadmin Fixed Server Role, follow this procedure: 1.
Open Enterprise Manager.
2.
Select the Security folder for the SQL Server in the tree view.
3.
Select Logins.
4.
Select Properties for the login account to be edited.
5.
Select the Server Roles tab.
6.
Unmark System Administrators to downgrade privileges.
7.
Click OK.
2.4 Setting Up Admin Roles and Accounts
23
To downgrade privileges using T-SQL in Query Analyzer or another SQL tool: sp_dropsrvrolemember 'admin', 'sysadmin'
To add back the sysadmin Fixed Server Role, follow this procedure: 1.
Open Enterprise Manager.
2.
Select the Security folder for the SQL Server in the tree view.
3.
Select Logins.
4.
Select Properties for the login account to be edited.
5.
Select the Server Roles tab.
6.
Mark System Administrators to upgrade privileges.
7.
Click OK.
To upgrade privileges using T-SQL in Query Analyzer or another SQL tool: sp_addsrvrolemember 'myAdminAccount', 'sysadmin'
Standard Access Categories, Access and Capabilities There are six Standard access categories. These categories are further defined by the specific access and capabilities of each category. For example, some capabilities allow access to modify the configuration options, while other capabilities allow read-only access. Standard access and capabilities categories include: • • • • • •
Queues Policies Policy Modules Directory Logs and Reports Setup and Configuration
The standard access and capabilities categories are described in the following sections.
24
Chapter 2: Setting Up Email Firewall Administration
Queues Queues are where messages are stored. Queues access is granted to allow access to: • • •
All queues All Quarantine queues Queue filters
Queue capabilities allow the role to perform the following actions on the queues it can access: • • •
View message text Take action on messages Modify queue filters
Policies Policies define which messages are caught, excluded and acted upon by the Email Firewall. Policy access is granted to allow access to all policies. Policy capabilities are granted to allow either policy-modify or read-only capabilities.
Policy Modules Policy modules are the building blocks for creating policies. Policy module access is granted to allow access to: • • • • • • •
All Word Lists All Address Lists All Attachment Lists All Tags All Annotations All Notifications All Custom Events
Policy module capabilities allow the role to modify or read-only the specified policy modules.
2.4 Setting Up Admin Roles and Accounts
25
Directory The directory contains all of the Email Firewall folders, user records and domain records. Directory access is granted to allow access to all records. Directory capabilities are granted to allow modification of security settings on the directory records.
Logs and Reports Logs and reports contain information about how Email Firewall is operating in your environment. Logs and Reports access is granted to allow access to the Audit Log and/or to all reports. Logs and Reports capabilities allow the role to view the Audit Log and/or to create reports.
Setup and Configuration Setup and configuration tasks define how Email Firewall should operate in your environment. Setup and configuration access is granted to allow access to: •
Setup Relays
•
Setup Secure Redirect (if installed)
•
Setup Secure Messenger (if installed)
• • • • • • • •
Setup Queues Setup Policies Setup Directory Setup Event Log Setup Anti-Virus and Anti-Spam Setup Security Setup Licenses Setup PQM Service
Setup and configuration capabilities allow modification or read-only access to the specified setup and configuration areas.
26
Chapter 2: Setting Up Email Firewall Administration
The Setup and Configuration list will include either the Setup Secure Redirect checkbox or the Setup Secure Messenger checkbox depending on which secure email component you have installed to work with the Email Firewall.
2.4.2
Assigning and Creating Admin Roles An administrator account with the SuperAdmin role can create and modify other admin roles and accounts, and specify the audit log retention time, in addition to managing all other areas of Email Firewall. The GeneralAdmin role provides lesser capabilities and access. When assigning roles to administrator accounts, you can use the predefined roles to grant access to the specified capabilities defined by that role, or you can create new roles. A sample of some of the types of roles that could be created are shown in Figure 2.7.
2.4 Setting Up Admin Roles and Accounts
27
Figure 2.7: Admin Roles
To create a new Admin Role:
28
1.
In the Email Firewall main menu, click Accounts.
2.
In the Set Up > Admin Accounts page, click Admin Roles.
3.
In the Admin Roles field, type a name for the new role and click Create.
4.
In the Accounts > Admin Roles > Edit Role page, selectively mark the radio buttons and checkboxes to add only those access rights and capabilities the new role should have. Figure 2.8 shows a partial page granting standard capabilities and access to all queues but no access to High Security options.
Chapter 2: Setting Up Email Firewall Administration
Figure 2.8: Creating Administrator Roles Options
2.4.3
Creating New Administrator Accounts To create a new administrator account: 1.
In the Email Firewall main menu, click Accounts.
2.
In the Set Up > Admin Accounts page, type a name for the new account and click Create.
3.
In the Set Up > Admin Accounts > Edit Account page, see Figure 2.9, complete the fields.
2.4 Setting Up Admin Roles and Accounts
29
4.
Use the Role drop-down list to select a role.
5.
Click Save to commit the new account to the database.
Figure 2.9: Setting Up New Administrator Accounts
Once an admin account is created, that account cannot change its assigned role.
30
Chapter 2: Setting Up Email Firewall Administration
2.4.4
Preferences Each admin account can set preferences that define the account’s identity, password, and the number of lines and content displayed on selected pages. See Figure 2.10. Figure 2.10: Email Firewall Administrator Preferences
2.4 Setting Up Admin Roles and Accounts
31
To set personal administrator preferences:
2.5
1.
Select Preferences from the left menu to open the Preferences page.
2.
Complete the Identity tab fields for email address and display name.
3.
Complete the Password tab fields to change your password.
4.
To set browser Preferences, edit the General, Queue and Event Log Preferences fields to define the number of items shown number of lines displayed on your browser for these tables. You can enter any number up to 1000. For queue preferences, use the drop-down list to select Standard, Expanded or MIME Format.
Setting Up Relays The basic Email Firewall SMTP Relay settings are defined when Email Firewall is installed. For information on configuring the SMTP Relay during installation, see the Email Firewall 6.2 Installation and Upgrade Guide. After installation, if the basic SMTP Relay settings need to be changed, or to add additional SMTP Relay settings, click Set Up in the main menu to open the Set Up page. Then click the links under the Relays heading to open the relay setup pages. The configuration pages include: • • • •
Relay Settings Network Connections Routing Rules Address Rewriting
Setting Up Relay Centers topics include the following: 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.7 2.5.8 2.5.9 2.5.10 2.5.11 2.5.12 2.5.13 2.5.14 2.5.15 32
Relay Settings Configuration ................................................... 33 Global Relay Settings............................................................... 34 Limit Settings ........................................................................... 36 Identity Settings........................................................................ 38 Specifying the DNS Servers ..................................................... 41 Exceptions to Mail Delivery..................................................... 43 Miscellaneous Relay Settings ................................................... 45 Network Connections Concepts ............................................... 49 Domain-Based Authentication Protocols ................................. 51 Setting Up Network Connections ............................................. 54 Mail Routing Rules Overview .................................................. 57 Setting Up Mail Routing Rules ................................................ 60 Address Rewriting Concepts .................................................... 67 Setting Up Address Rewriting .................................................. 71
Chapter 2: Setting Up Email Firewall Administration
2.5.16 Testing Address Rewriting ........................................................ 75 2.5.17 SMTP Relay and Message Retry Configuration....................... 76 2.5.18 Troubleshooting the SMTP Relay Service ................................ 76 For general conceptual information about SMTP and the Email Firewall SMTP Relay service, see the Email Firewall 6.2 Installation and Upgrade Guide. The Partition relay must be installed at all times. If the relay is installed in a distributed setup, the partition relay must be installed on at least one machine, normally on the same machine as the Outbound relay.
2.5.1
Relay Settings Configuration Before making any modifications to the SMTP Relay settings it is strongly recommended that you review the SMTP conceptual and overview information in the Email Firewall 6.2 Installation and Upgrade Guide.
The Relay Settings options include: •
• •
• • • •
Global settings: stop all outbound mail, reject all inbound connections, and route messages through Policy Engine (and spam analysis engine if installed). Limit settings: set limits on number of connections, message size and number of recipients. Identification settings: SMTP port on which the Relay Service listens for inbound mail, relay host name for common identification of all relay hosts, SMTP welcome message for all relay hosts, reveal or hide product version information in message headers, Postmaster mailbox reply address and domain for undeliverable messages or other messages that require notification to the sender, and local MX hosts. DNS Server identification: addresses and the order in which the DNS servers are used. DNSBL Settings: set up to three DNSBL hosts. Exceptions: illegal mailbox characters, mailbox only recipients, and bounced notifications behavior. Miscellaneous settings: Delivery Status Notifications (DSNs), alternate “A” record lookups, load balancing, DNSBL domain name and message acceptance, and received header display for external networks.
2.5 Setting Up Relays
33
2.5.2
Global Relay Settings These setting affect whether Email Firewall will accept or process messages at all. They include: • • •
Stop All Outbound Mail: When enabled, holds all mail in the Outbound queue; no mail is sent out of the system. Reject All Inbound Connections: When enabled, causes the Relay service to reject all SMTP client connection requests. Route messages through policy engine (and spam analysis engine if installed): When disabled, passes mail without any scanning or filtering.
Stopping Inbound or Outbound Mail Marking the Stop All Outbound Mail option temporarily stops all outbound mail. When enabled, mail is held in the Outbound queue on the Email Firewall server. Although outbound mail is stopped, the SMTP Relay service continues to run, as do all the other currently running Email Firewall services. Email Firewall will continue to accept new messages during this time. While outbound mail is temporarily stopped, no messages will be expired. Instead, Email Firewall will attempt to deliver every message at least once after the outbound mail is released. Marking the Reject All Inbound Connections option causes the inbound SMTP Relay service to reject all SMTP client connection requests. No further messages will be accepted over inbound SMTP connections that have already been established unless this option is subsequently disabled. Depending on the client implementation, inbound connections may remain open for some time after this option is enabled since Email Firewall does not asynchronously drop the connection.
34
Chapter 2: Setting Up Email Firewall Administration
To temporarily stop outbound mail: While the Stop Outbound Mail checkbox is marked, all outbound mail is held in the Outbound queue. Depending on your mail volume, this queue may grow quite large during this time. 1.
In the Set Up > Relay Centers page, mark the Stop all Outbound Mail checkbox.
2.
Click Save.
To resume outbound mail flow, unmark the Stop all Outbound Mail checkbox. To temporarily stop inbound mail connections: 1.
In the Set Up > Relay Centers page, mark the Reject All Inbound checkbox.
Connections
2.
Click Save.
To resume inbound connections and mail flow, unmark the Reject All Inbound Connections checkbox.
Enabling and Disabling Preprocessing and Policy Engine The Route messages through policy engine (and spam analysis engine if installed) setting controls whether mail accepted by the Email Firewall SMTP Relay is routed through the Policy Engine. If the Dynamic Anti-spam Service (DAS) is installed, this setting also controls whether mail is routed to the Spam Analysis Engine (SAE) for preprocessing. By default, this setting is enabled. It is recommended that you do not disable routing through the Policy Engine unless instructed to do so by your Tumbleweed Global Support representative.
To enable processing by the Policy Engine and SAE (if DAS is installed): 1.
Verify that the checkbox beside the Route messages... option is marked. The checkbox is marked by default. If you have not installed the Dynamic Anti-spam Service, messages are not preprocessed by the SAE before being sent to the Policy Engine.
2.
Click Save to commit any changes.
2.5 Setting Up Relays
35
To disable processing by the Policy Engine and SAE (if DAS is installed):
2.5.3
1.
Unmark the checkbox beside the Route messages... option.
2.
Click Save to commit the changes.
Limit Settings The configuration parameters for these settings assist with performance tuning and help the system to resist certain spamming attacks. They include: • • •
Network Connections:
limiting the number of connections can enhance Relay performance. Message Size: limiting total message size can help to reduce vulnerability to denial of service attacks. Recipients: limiting the number of recipients that are allowed on any one message can help to reduce vulnerability to denial of service attacks.
Maximum Connections and Delay Settings • Maximum Inbound Connections: Limiting the maximum number of inbound connections ensures that the server will not accept more than the configured number of connections at one time. Too many inbound connections may impact the Inbound Relay performance and may also cause client time-out failures. Setting the Maximum Inbound Connections to 0 will have the effect of Email Firewall not receiving inbound mail. However, it is recommended that you use the procedure described in Stopping Inbound or Outbound Mail on page 34 to accomplish this.
•
•
•
36
Maximum Inbound Connections per host: Limiting the maximum number of inbound connections per host ensures that one host does not cause a drain on connection resources. Maximum Outbound Connections: Limiting the maximum number of outbound connections ensures that the server will not attempt to connect to more than the configured number of relays at one time. Too many outbound connections may impact the Outbound Relay performance. Maximum Outbound Connections Per Host: Limiting the maximum number of outbound connections per host ensures that one host does not cause a drain on connection resources.
Chapter 2: Setting Up Email Firewall Administration
•
Setting the outbound connection delay allows an existing connection to be reused if more outbound mail arrives for that host. Delay Closing Outbound Connection for X seconds after last send:
Network Connections and Replication Environments On the Limits tab, when you make changes to the number of Relay connections allowed, you must restart the SMTP Relay service. If you are using Email Firewall with replication, you must restart the SMTP Relay service on all machines on which replication is enabled. These settings include: • • •
Maximum Inbound Connections Maximum Outbound Connections Maximum Outbound Connections per Host
You must also restart the SMTP Relay service if you change the SMTP Port setting on the Identity tab. For more information about using Email Firewall with replication, see the Tumbleweed Email Firewall Best Practices Guide.
Message Size and Recipient Limits In addition to the maximum inbound connections setting, the following SMTP Relay limit settings can also help to reduce your vulnerability to denial of service attacks. These settings should not be set higher than they need to be for your organization: • •
Maximum message size: sets absolute limits on total message size that will be accepted by the Relay (maximum total message size is currently 7MB) Maximum recipients per message: sets absolute limits on the number of SMTP recipients per message that are allowed to be accepted by the Email Firewall Relay.
To set absolute limits on total message size: 1.
In the Message Size heading, type an integer representing MB or KB.
2.
Use the drop-down arrow to select MB or KB.
3.
Click Save.
When setting the recipient limit, be aware that Email Firewall will not reject the entire message, it will simply stop accepting more recipients onto that message when the number of recipients exceeds the configured limit.
2.5 Setting Up Relays
37
To set a limit on the number of recipients allowed on an individual message:
2.5.4
1.
In the Recipients heading, type an integer in the field to specify the number of recipients allowed. Once the specified number is reached, the relay will not accept any more recipients on that message.
2.
Click Save.
Identity Settings These settings specify where Email Firewall listens for SMTP traffic and how it identifies itself to others. They include: • • • • •
•
SMTP Port:
the port on which the Email Firewall Relay Service listens for inbound mail. Relay Host Name: the name given to SMTP clients that attempt to connect to any Email Firewall SMTP Relay. Session Welcome Message: the message given to SMTP clients that attempt to connect to an Email Firewall SMTP relay. Message Headers: determines whether received headers include the Email Firewall product name and version number. Postmaster: the sender address given for all nondelivery or delay notifications, or any notification required to be generated by the Email Firewall SMTP Relay. Local MX Hosts: when multiple relays are deployed, allows identification of local MX hosts to avoid routing loops.
Setting the SMTP Port The SMTP port is set during installation. If you need to change the port: 1.
Complete the SMTP Port field to specify the port on which the Email Firewall Relay Service listens for inbound mail (the default port is 25).
2.
Click Save to commit the changes.
3.
Restart the SMTP Relay service. If you are using Email Firewall with replication, if you change the SMTP Port, you must restart the SMTP Relay service on all machines that are enabled for replication.
38
Chapter 2: Setting Up Email Firewall Administration
Specifying the Relay Host Name The Relay Host Name is the name given to SMTP clients that attempt to connect to any Email Firewall SMTP Relay, regardless of the local host’s actual name. In distributed environments where there may be more than one instance of the Email Firewall Relay service installed, configuring the hostname of all Email Firewall relay machines accessing the Email Firewall database means that the hostname is consistent for all connection messages. If this feature is not enabled, each SMTP Relay Host is identified by its local hostname. If more than one SMTP Relay service is installed and all hosts should identify themselves by a common name: 1.
Mark the Relay Host Name checkbox.
2.
Type the Host Name in the field.
3.
Click Save to commit the changes.
Specifying the SMTP Greeting and Postmaster Information The Session Welcome Message is the message given to SMTP clients that attempt to connect to an Email Firewall SMTP relay. This text is also used in the Received header that Email Firewall inserts into all accepted Inbound messages. The Postmaster Mailbox and Postmaster Domain information is used whenever there is a nondelivery or delay notification required, or any time a notification is required to be generated by the Email Firewall SMTP Relay. This information is sent to the sender of the problem message. By default, the Email Firewall SMTP relay mailer-daemon and the local host are identified as the reply address on the notification.
2.5 Setting Up Relays
39
To modify the Email Firewall SMTP Relay Session Welcome and Postmaster information:
You must only use ASCII 7 characters in the Session Welcome and Postmaster information fields.
1.
To allow the SMTP Relay to identify itself using a different greeting than the default greeting, in the Session Welcome Message field, type the message connecting relays should see.
2.
To allow the SMTP Relay to identify itself differently from the default settings, type the information in the Postmaster Mailbox and Postmaster Domain fields. It may be useful to use the address of a postmaster mailbox or distribution list here.
3.
Click Save to commit the new information to the database.
Hiding Email Firewall Version Number in Message Headers The Email Firewall Relay always adds a Received header to each new message when processing messages into the Email Firewall system. By default, this header includes the Email Firewall product name and version number. The following example illustrates what is added: Received: from 10.11.60.100 by baseball.tumbleweed.com with SMTP (Tumbleweed Email Firewall SMTP Relay (Email Firewall v6.2)); Fri, 22 Apr 2005 15:20:14-0700
Some organizations prefer not to have their SMTP relay product version information exposed in the Received header, for security or other reasons. The product version number in message headers can be hidden by unmarking the Include Email Firewall version information in message Received headers
checkbox. When this option is enabled (by unmarking the checkbox), the product version is not included in the Received header. The following example illustrates the hiding option: Received: from 10.11.60.100 by baseball.tumbleweed.com with SMTP (Tumbleweed Email Firewall SMTP Relay); Fri, 26 Sep 2003 13:45:50 -0700
40
Chapter 2: Setting Up Email Firewall Administration
Local MX Hosts Configuration The purpose of configuring the Local MX Hosts field is to make sure that the outbound SMTP Relay service never attempts to deliver mail to another relay that is using the same Email Firewall database (resulting in a routing loop). It is not necessary to enter any data in this field if there is only a single Email Firewall SMTP Relay service referencing your Email Firewall database. In this case, the Relay service would not route mail back to itself. Use this option only if your Email Firewall system meets all of these criteria: • • •
DNS is used for routing outbound mail to some domains. The hosts that are running the inbound Email Firewall SMTP Relay services are listed in the DNS as MX hosts for at least one such domain. More than one SMTP Relay service is referencing the Email Firewall database.
If this option needs to be configured based on the above, the Local MX Hosts field should contain the fully qualified domain names or the IP addresses of all hosts that are running the inbound Email Firewall SMTP Relay service and are referencing the same Email Firewall database. Click Save to commit the changes.
2.5.5
Specifying the DNS Servers Each IP address specified here identifies the host machine where the DNS software resides. Domain name servers translate domain names to IP addresses. The machine(s) identified here accept requests from programs to convert domain names into IP addresses and accept requests from other name servers to convert domain names into IP addresses. The DNS Server IP Address field allows adding additional DNS Server IP addresses. The Up and Down buttons allow you to define the order in which the DNS servers are used. To add an alternate DNS server: 1. 2.
Type the new server IP Address in the DNS Server IP Address field and click Add. Verify the new server address appears at the bottom of the DNS Server IP column.
Address
2.5 Setting Up Relays
41
3.
To prioritize the new DNS server, mark the checkbox beside that server and use the Up and Down buttons to re-order the list.
4.
Click Save.
To change a DNS server: 1.
In the row beside the DNS address, click Edit to make any changes. Or, click Remove to take the information out of the database.
2.
Click Save to commit the changes.
For information on how Email Firewall interacts with the DNS configuration, see the Email Firewall 6.2 Installation and Upgrade Guide.
2.5.6
Specifying DNSBL Settings DNS-based Black Hole Lists (DNSBLs) are lists of IP addresses published by an DNSBL provider for the purpose of advising their subscribers of the hosts that are either known sources of spam, known open relays, or known hosts that have other specific properties of interest. The contents of an DNSBL are published and queried using the DNS protocol. To perform a DNSBL: 1.
In the DNSBL Source Domain fields, enter up to three DNSBL hosts. For the DNSBL Source Domain, you can specify an IP address or a host name, such as blackholes.mail-abuse.org. However, you must subscribe to the DNSBL hosts to use this feature. One such DNSBL host is Mail Abuse Prevention System (MAPS) at www.mailabuse.org; The DNSBL hosts are checked in order of appearance with the top being checked first. If the IP address is found, the DSNBL hosts below are skipped
2.
For each DNSBL source domain you enter, indicate how the EMF relay will handle connections from any IP address that appears on the specified DNSBLs. For the Response to client, select one of the three options: • If you select Refuse connection with a permanent error response, messages from this connection are not accepted with the permanent negative completion reply (5xy), and the senders are discouraged from repeating the exact connection. • If you select Refuse connection with a transient error response, messages from this connection are not accepted with the transient negative completion reply (4xy). However, the error condition is temporary and the connection may be requested again.
42
Chapter 2: Setting Up Email Firewall Administration
• If you select Accept connection. Any accepted messages will be marked, all messages from this connection are accepted but tagged for further processing in the Policy Engine. If a client is on a DNSBL and the connection is accepted, a header will be placed on all messages received from that client, such as, "X-Client-On-DNSBL: (DNBSL domain name)".
2.5.7
Exceptions to Mail Delivery When a message is presented to the relay, certain characteristics of the message may signal a problem with the message. These special cases can be globally and automatically handled by the relay by specifying these exception options: •
•
•
Illegal Mailbox Characters: when these illegal address characters are defined, messages containing these characters are automatically rejected by the SMTP Relay. Mailbox Only Recipients: by default, when an SMTP client sends a message with a recipient address that includes a mailbox but no domain name, the message is dropped. This option allows the mailbox to be appended with a domain name for attempted delivery to the recipient mailbox at the domain specified. Bounced Notifications: when enabled, the relay automatically deletes any undeliverable messages with a null SMTP sender address. If this option is not enabled, such messages are placed in the Dead Letter queue.
Specifying Illegal Characters in Email Address Formats Recommended characters include @!%. However, care should be taken when defining these illegal characters. For example, % may be a valid character in a Lotus Notes environment.
2.5 Setting Up Relays
43
To specify illegal characters in address formats: 1.
In the Illegal Mailbox Characters text field, type the characters that you want to define as illegal if found in the recipient address of messages passing through your server. When typing the characters, there should be no delimiter between characters.
2.
Click Save.
Dropping Mailbox-Only Recipients Normally, an email client sends a full address on the RCPT command, including both a mailbox and a domain name, such as . But sometimes, a client may send a message to a recipient like and it expects the SMTP Relay to append the default local domain automatically. The Mailbox Only Recipients option affects how the inbound SMTP Relay handles the case where the SMTP client sends a recipient address with a mailbox and no domain name. The default option is to drop the mail. The option to accept the mail and append a domain name is provided for environments where some internal users are connecting to the Email Firewall relay directly with a desktop SMTP client application, and using it to send SMTP mail. In this case, mail senders may be expecting the SMTP server to append the local domain when one is not explicitly specified for some of the recipients on a message. To enable accepting the mail and appending a domain name automatically: 1.
In the Mailbox Only Recipients heading, mark the accept mail and append the domain radio button and type the default local domain name in the text field.
2.
Click Save.
Deleting Bounced Notifications This option allows automatic deletion of any undeliverable messages with a null SMTP sender address. Enabling this option may help to reduce the number of messages that need to be stored in the database. For example, if your domain has been the victim of a spam attack, there may have been occasions where large numbers of delivery status notifications (DSNs) were placed in the Dead Letter queue. For example, assume that a large number of spam messages are accepted by Email Firewall and the recipient addresses are non-existent mailboxes in your domain. The spam messages are not deliverable, so the mail system generates a DSN addressed to the original 44
Chapter 2: Setting Up Email Firewall Administration
SMTP sender indicating that the message cannot be delivered. The DSN will always have a null SMTP sender address. If the original SMTP sender address was invalid, the DSN is undeliverable and it will be moved to the Dead Letter queue. While Email Firewall provides the ability to automatically delete messages from the Dead Letter queue that have been there beyond a configurable time limit, the bounced notifications option allows you to eliminate these messages instead of sending them to the Dead Letter queue. To enable the relay to drop undeliverable mail with a null SMTP sender address: 1.
In the Bounced Notifications heading, mark the Drop undeliverable mail with a null SMTP sender address checkbox.
2.
Click Save. If this option is not enabled, undeliverable mail with a null SMTP sender address is placed in the Dead Letter queue.
2.5.8
Miscellaneous Relay Settings These settings provide additional relay options that help manage SMTP traffic. •
•
•
•
Delivery Status Notifications:
Determines whether the relay will send success Delivery Status Notifications (DSNs) when requested by an SMTP sender. Alternate Lookup: Directs the relay to search for an “A” record (maps hostnames to IP addresses) when no “MX” records (map mail domains to hosts that accept mail for that domain) are found. Load Balancing: Enables randomized order of equal MX hosts when Email Firewall is using a DNS server that would otherwise return MX hosts in the same order every time. Received header: Enables the relay to add an external network’s EHLO source host to messages that it processes.
2.5 Setting Up Relays
45
Delivery Status Notifications The default SMTP Relay behavior for Delivery Status Notifications (DSNs) is to deliver a notification to the message sender if delivery of their message has been delayed or has failed completely. This option is set up in the Retry queue configuration. See 3.2.4 Setting Retry Queue Retry Intervals on page 123. The notifications sent are described in SMTP Relay Delay and Non-Delivery Notifications Sent on page 48 and in Table 2.2. Most email clients also allow for a “delivery receipt,” which is a request for a notification of successful relay of a message, which Email Firewall will typically provide. However, many organizations prefer that the relay not deliver non-failure (success) DSNs. The Delivery Status Notifications: Generate Success Notifications configuration parameter provides this option. The default behavior is to deliver non-failure (success) DSNs. When this checkbox is unmarked, the Email Firewall SMTP Relay will not generate success (relayed) delivery status notifications, even when requested to do so by an SMTP client. Be sure to click Save if you make any changes. There is also a DSN Return Notification option in the EngineConfigValues table that is not exposed in the Web Admin but that can be configured using the Configuration Editor. The option takes the values 0 and 1. These values determine whether the “Return” action generates a standard DSN or a plaintext DSN. The current version of Email Firewall uses the standard DSN while previous Email Firewall versions use the plaintext version. The default value is 1, to use the standard DSN. This new option is provided to ensure backward compatibility with previous versions. For more information about using the configuration Editor, see 10.11 Using the Configuration Editor on page 609.
Alternate Lookups SMTP relays use the Domain Name Service (DNS) to help with message routing. DNS uses the components listed below to help route messages from one email server to another. • •
46
A records map hostnames to IP addresses: NT01 to 192.9.200.201 MX records map mail domains to hosts that accept mail for that domain: tumbleweed1.com to NT01
Chapter 2: Setting Up Email Firewall Administration
Mark the Search for an 'A' record when no 'MX' records are found checkbox if you want the relay to use A records when the usual MX records are not found. Be sure to click Save if you make any changes.
Load Balancing by Randomizing Order of MX Hosts When using either the DNS or MX for Domain options for Outbound mail routing, Email Firewall sorts the MX (Mail eXchange) records in preference order to determine where mail should be relayed. By default Email Firewall will always attempt delivery to the MX hosts of equal preference value in the order that the MX records appeared in the DNS query response. This results in reasonable load balancing when the DNS server is using a round-robin algorithm on MX query responses. When the Randomize option is enabled, the Email Firewall SMTP Relay randomizes the order of MX records with equal preference values. This helps load balancing SMTP traffic when Email Firewall is using a DNS server that returns MX hosts in the same order every time. Mark the Randomize order of equal MX hosts checkbox for load balancing if you are using a DNS server that returns MX hosts in the same order every time. Be sure to click Save if you make any changes.
Received Headers Content This option enables compliance with a non-mandatory standard for relay behavior. According to RFC2821: 4.4 Trace Information When an SMTP server receives a message for delivery or further processing, it MUST insert trace (“time stamp” or “Received”) information at the beginning of the message content, as discussed in section 4.1.1.4. This line MUST be structured as follows: The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection. The received headers option allows the relay to comply with the “SHOULD” clause in the last paragraph above, by adding the external networks’ EHLO source host to messages. To enable this option, in the Received header heading, mark the Add EHLO source host for external networks checkbox. Be sure to click Save if you make any changes. 2.5 Setting Up Relays
47
SMTP Relay Delay and Non-Delivery Notifications Sent All delay and non-delivery notifications sent by the SMTP Relay include the information that a message has been delayed, a summary of the apparent reason for the message delivery failure or delay, and the recipients to whom the delay applies. Following is the text of the delay notification: Your message has been delayed. The server will continue trying to forward the message. You do not need to re-send the message.
The notification regarding recipients whose messages are affected states: “The delay affects the following recipients:” followed by the address of the affected recipients. The apparent cause of delivery failure included in the delivery notification, and the reason that specific notification was sent, is listed in Table 2.2. Table 2.2: SMTP Relay Delay and Non-Delivery Notifications Apparent cause of delivery failure
Reason sent
Attempts to connect to the remote server have failed
Network or remote host is down
The remote server is temporarily refusing to accept mail
Error response to MAIL command or error code in remote server greeting
An SMTP protocol error occurred while send- Unexpected event during ing this message SMTP transaction The remote server is temporarily refusing to accept connections
Error response to HELO or EHLO command
The remote server is temporarily refusing to accept mail for the recipient
Error response to RCPT command
The remote server is temporarily unable to accept this message
Error response to DATA command
For a more general overview of SMTP and the Email Firewall SMTP Relay Service, see the Email Firewall 6.2 Installation and Upgrade Guide.
48
Chapter 2: Setting Up Email Firewall Administration
2.5.9
Network Connections Concepts The Network Connections configuration enables the designation of IP address ranges as either internal or external networks. This designation is extremely important to proper functioning of SMTP relay messaging and it is strongly recommended that this configuration information be kept up to date. Accuracy here is critical to ensuring that the Email Firewall system is not used as an open relay. It is also critical to the correct functioning of the Tumbleweed Dynamic Anti-spam Service Spam Analysis Engine, if this service is installed. The Network Connections configuration also defines whether certain security or authentication protocols should be used. These include Transport Layer Security (TLS), Sender Policy Framework (SPF), and Caller ID for Email. The TLS extension is a newer version of the SSL protocol. It enables secure communication (SSL) with other SMTP servers, on a per-domain basis. The Network Connections settings specify whether TLS is used at all, is used if possible, or is required when other networks attempt to connect to the Email Firewall relay. For more information about TLS, see 8.4 Email Firewall Security using TLS on page 373. The two domain-based authentication protocols implemented within Email Firewall are the Sender Policy Framework (SPF) and Microsoft’s Caller ID for Email. These proposed standards attempt to validate that the host sending an email message is authorized to send on behalf of the sender’s domain. Two additional settings, DNSBL and RDNS, allow the relay to perform additional network checking before accepting messages from the connecting network. DNS-based Black Hole Lists (DNSBLs) are lists of IP addresses published by an DNSBL provider for the purpose of advising their subscribers of the hosts that are either known sources of spam, known open relays, or known hosts that have other specific properties of interest. The contents of an DNSBL are published and queried using the DNS protocol. A reverse domain name system (RDNS) query can be used to find a host name associated with an IP address. If the RDNS query option is enabled, the query result will be included in the Received message header that is inserted into each message received by Email Firewall. However, unless you have a need for this information or unless you are using the sender domain checking options, it is recommended that you do not enable the RDNS query option because of its impact on performance. DNS servers typically do not respond to reverse (PTR typed) queries very rapidly.
2.5 Setting Up Relays
49
Understanding Internal vs. External Networks The designation of a network as internal does not necessarily correspond to where the network is located. Here are the two rules to apply to determine whether a host should be designated as internal: •
•
If a host/network is allowed to submit SMTP mail to Email Firewall with recipients outside of your enterprise, that host should be designated as internal. If a host/network is allowed to submit SMTP mail to Email Firewall and that mail might have originated outside of your enterprise, that host must be designated as external. (You should not list a machine that receives email from the Internet as internal). The Network Connections configuration does not require that you explicitly designate a network as external. A network is considered to be external unless you select the option to designate it as internal.
If you have a network where both of the above rules apply, you should see if you can identify the specific hosts within that network can be designated as internal or external. If you have an individual host for which both rules apply, this indicates a problem that requires a change to the way SMTP mail is routed into or out of your organization. A single host cannot be designated as both internal and external. These rules must be applied correctly to prevent your Email Firewall system from being used as an open relay. An open relay is a host on the Internet that can accept SMTP mail and relay it to any other domain. Spammers seek out such hosts in order to relay their spam messages using the open relay's network identity instead of the originator's network identity. See Configuring Email Firewall To Prevent Open Relaying on page 59 for more information.
Rejecting Connections From Malicious Clients The Network Connections configuration provides the ability to reject all inbound mail from a host or network of hosts. This can be very useful when your mail systems are receiving significant quantities of unwanted mail from a particular network. Frequently, it is faster and easier to block SMTP connections using the Network Connections table than it is to update your firewall to do the same thing. But you should consider whether it makes sense to update your firewall configuration as well.
50
Chapter 2: Setting Up Email Firewall Administration
Before doing this, you may need to confirm that no legitimate mail needs to be sent to your organization from that network. For example, there may be large quantities of spam coming from an open relay running at an enterprise with which you need to communicate. It could be unacceptable to block all mail from that host. Because the Email Firewall SMTP Relay will refuse inbound connections from clients in that network, the senders of legitimate email in that network should eventually be notified that their mail did not get delivered. However, it could take several hours or days before the sender receives that notification. If there are multiple MX records published in the DNS for your domains, you will need to make sure that all of those mail exchanger hosts reject mail from the networks that you have designated as malicious. Otherwise, mail that is rejected by one MX host might still be accepted by one of the alternates.
2.5.10 Domain-Based Authentication Protocols The deluge of spam and concerns about authenticity of email have engendered both enhanced and new protocols for verifying that the purported sender of an email message is the actual sender of the mail. Email Firewall Network Connections provides these additional tools to address these concerns. Both the Sender Policy Framework (SPF) and Microsoft’s Caller ID for Email are domain-based authentication protocols. They encourage email domain administrators to publish information about their outbound mail servers in the DNS. Doing so enables inbound mail servers to determine whether the sending host is authorized to send mail on behalf of the domain name appearing in the sender’s email address. If the host is not authorized, the sender address may be “spoofed” and the message can be rejected. Use of these protocols may help to eliminate large quantities of spam on the Internet, since spammers frequently use spoofed sender addresses. Support for both SPF and Caller ID are integrated into the Inbound SMTP Relay Service. When testing is enabled, the SMTP Relay will reject messages that fail the test. All messages that have been tested and accepted are marked with message properties so that downstream components can distinguish messages that successfully passed the test from the messages not tested at all. By default, SPF and Caller ID checking are not to be performed. The administrator must explicitly enable this feature. The SPF and Caller ID authentication techniques are primarily intended for SMTP Inbound “gateway” machines that are receiving mail directly from the Internet. Email Firewall supports SPF and Caller ID testing only when the 2.5 Setting Up Relays
51
Inbound SMTP Relay is deployed such that inbound mail from external domains is received directly. If Email Firewall is deployed such that a non-Email Firewall SMTP relay receives the inbound mail in the DMZ and then relays the mail to Email Firewall, SPF and Caller ID cannot be enabled. If enabled in this environment, messages will be incorrectly rejected because they will appear to have failed the authentication test. The Caller ID specification describes how a sender could be authenticated with a Caller ID test when the message is on a system that is not the one that received the message from the purported sender’s domain. However, this type of support for Caller ID is not supported in this release.
Sender Policy Framework The Sender Policy Framework provides one way to address the problem of domain name forgery. Malicious entities often falsify envelope and header addresses to conceal the identity of the true source of a message. When the forged addresses correspond to legitimate addresses, the victims of the forgery suffer the cost. SPF is designed to fight this type of email address forgery. It does this by establishing a policy framework and an authentication scheme. SPF defines a simple language that domains can use to describe the mail they send. SMTP receivers can then use these descriptions to evaluate messages. In an SPF sender authentication scheme, a domain owner asserts that legitimate messages from that domain must meet a certain description. Messages which do not meet that description are not legitimate. These assertions are made in machine-readable form. The SPF specific sender authentication scheme is based on the designated sender model. A domain identifies certain hosts as designated senders and mail from those hosts is considered legitimate while mail from other hosts is not. The SPF publishes policy data in the DNS. DNS resolvers can then cache the SPF data to reduce lookup traffic. Although SPF appears to function very similarly to RDNs lookups, the two are different. The main difference between SPF and RDNS is that in the SPF case, the sending domain is given the opportunity to publish in the DNS a “policy statement” that declares what are the hosts on the Internet that may legitimately send email on behalf of that domain. If the sending domain publishes that information, then a receiving server that supports SPF may use it to make a decision about whether to accept or reject an inbound message. (Note that when
52
Chapter 2: Setting Up Email Firewall Administration
SPF becomes widely deployed, spam filters like DAS can also cast more doubt on mail received from domains that publish no SPF information.) In the case of RDNS, receiving SMTP servers are simply making an educated guess about whether the mail is coming from a host that should be authorized to send on behalf of the sending domain. This guess is prone to errors because mail could be routed through service providers' machines and because the reverseDNS names of outbound SMTP relays are sometimes not in the DNS at all. Additional information about SPF can be found at http://spf.pobox.com/spf-draft20040209.txt.
Microsoft’s Caller ID Caller ID for E-Mail is the Microsoft draft specification to address the problem of domain spoofing and email forgery. Caller ID verifies that each message originates from the Internet domain it claims to come from. Caller ID checking is based on addresses found in the message headers, not the SMTP envelope. The Caller ID mechanism is achieved by having administrators of domains publish the Internet addresses of their outgoing email servers in the Domain Name System (DNS) in addition to the incoming email servers that they list there today. When email is transmitted from one organization to another, the computers of the sending organization need to determine which computer the receiving organization has designated as the one that handles its incoming mail. With the information listing outgoing mail servers in place, software that receives an incoming message can now verify that the computer used to send the message was in fact under the control of the domain from which the message purports to have originated. Additional information about Microsoft’s Caller ID specification can be found at http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx.
2.5 Setting Up Relays
53
2.5.11 Setting Up Network Connections For each network, you can specify the following options: • • •
Network Address:
Mail Client IP address and IP mask. Internal: Whether the network is internal. If not specifically designated as internal, it is assumed to be external. Allow Network Connections: • Inbound: Whether to allow inbound connections from certain networks, and if so, whether to require or permit use of TLS. When enabled, the Relay advertises STARTTLS. Optionally, require that the client authenticate itself with a trusted certificate. Use of TLS for inbound connections can be further defined at the domain level within the Routing Rules setup. All TLS configurations for outbound routing is done through the Routing Rules table. See 2.5.13 Setting Up Mail Routing Rules on page 60.
• • •
•
• Outbound: Whether the host is allowed to connect. SPF: Whether to enable use of the Sender Policy Framework (SPF). Caller ID: Whether to enable use of Microsoft’s Caller ID for Email. DNSBL: Whether to perform a DNS-based Blackhole List (DNSBL) lookup when that host connects, to determine whether the host is on the DNSBL list of known problem hosts. RDNS: Whether to perform a Reverse DNS (RDNS) lookup to determine which host sent the message from that IP address. If located, the hostname will be added to the Received header inserted into any accepted inbound messages. Because the RDNS lookup uses a significant amount of network resources, it is recommended that RDNS only be enabled to correct a specific problem or for troubleshooting.
Before making changes to these settings, you should review the conceptual information in 2.5.9 Network Connections Concepts on page 49.
54
Chapter 2: Setting Up Email Firewall Administration
To set up Network Connections: 1.
If you plan to use TLS then it must be set up first. Click the TLS Setup link and complete TLS setup before proceeding, then return to this page. See 9.4 Setting Up Certificates for TLS on page 445 for more information.
2.
During installation, at least one IP address was specified that was designated as internal. To add additional hosts, type the IP address in the field and use the Mask field to designate a range of IP addresses. To set as a range enter a properly formatted Client IP and an IP Mask ending in 0. For example, Mail Client IP 10.15.76.2 and Mask 255.255.255.0 will allow 10.15.76.1 through 10.15.76.255. On the other hand, a Client IP of 10.15.76.2 and Mask of 255.255.255.255 will only allow the Client IP 10.15.76.2 and no other.
3.
If appropriate, mark the Internal checkbox to indicate that this address is Internal. Email Firewall will consider this an internal connection. See Understanding Internal vs. External Networks on page 50 for more information.
4.
For messages Inbound to Email Firewall, under the Inbound column, mark the Allow checkbox to allow inbound mail connections. Remember: These Allow settings apply to Network Connections only. Any messages that are routed through Email Firewall are inbound and all messages that Email Firewall sends are outbound. This is true regardless of whether an internal user is the sender or recipient. A message from an internal or external machine is inbound. Messages that Email Firewall sends are outbound.
5.
If you marked the Allow checkbox in the previous step, optionally, use the drop-down list to select a Transport Layer Security (TLS) setting for inbound connections. (The default setting is to not use TLS.) TLS security is based on the domain name that is contained within a TLS certificate. If the DNS is configured so that the MX record has only an IP address, then there is no way for Email Firewall to obtain a valid domain name with which to validate a TLS certificate. While this is not a normal DNS configuration, if the DNS server returns an IP address instead of hostname for a domain and TLS is required as specified above, the message will be placed in the Retry queue because Email Firewall is unable to validate the authenticity of the peer TLS certificate.
2.5 Setting Up Relays
55
In order to configure TLS, a valid TLS certificate must first be imported and selected on the Setup TLS page. Until that has been done, the TLS options on this page are disabled. See 9.4 Setting Up Certificates for TLS on page 445 for more information
Legend for TLS selections: • • • • •
No TLS:
Do not allow TLS TLS OK: Permit TLS TLS OK*: Permit TLS with client authentication Req TLS: Require TLS Req TLS*: Require TLS with client authentication
6.
For messages outbound from Email Firewall, under the Outbound column, mark the Allow checkbox to allow outbound mail connections.
7.
Optionally, mark the SPF checkbox to enable SPF. See Sender Policy Framework on page 52 for more information.
8.
Optionally, mark the Caller ID checkbox to enable Caller ID checking. See Microsoft’s Caller ID on page 53 for more information.
9.
Optionally, mark the DNSBL checkbox to enable DNS-enabled Blackhole List checking. If you choose to perform a DNSBL lookup, you can specify the DNSBL Domain Name for Email Firewall to use for the lookup in the Relay Settings page. See2.5.6 Specifying DNSBL Settings on page 42.
10. Optionally, mark the RDNS checkbox to require reverse DNS checking. 11. Click Add. 12. In the Network Connections table, verify the new network appears with the
correct settings. To modify a network connection entry:
56
1.
In the network’s row, click Edit.
2.
Make the desired changes.
3.
Click Save.
4.
Verify the network appears with the correct modified settings.
Chapter 2: Setting Up Email Firewall Administration
To remove a network connection: 1.
In the network’s row, click Delete.
2.
Verify the network no longer appears in the Network Connections page.
Editing Network Connections To edit an existing network connection, click Edit in the network’s row and make desired changes in the fields. See the procedures discussed in 2.5.11 Setting Up Network Connections on page 54 for more information.
2.5.12 Mail Routing Rules Overview Setting up appropriate mail routing rules that define what senders and recipients will be accepted under what conditions can help to combat spam and other unwanted mail, both in your own system and in SMTP relaying in general. When you setup the SMTP Relay, IP addresses and ranges are designated as internal or external networks. Using these designations, Email Firewall can then identify any SMTP client connection as originating from either an internal or an external host. Each host can be configured with defined acceptance rules. Acceptance rules may be defined for any of the following: • • •
a fully qualified email address to match a single, specific address. a domain name to match all addresses within a specific domain. a “wildcard” address to match all addresses that do not match on a more specific rule.
Each Routing Rule includes the following configuration options: • •
The name of the rule. If no Routing Rule name is specified, the first domain in the list will be used as the name. The Inbound Acceptance rules, which specify: • Whether mail sent from this address will be accepted or rejected if the client is an internal host and the mail address or domain is the sender or recipient. • Whether mail sent from this address will be accepted or rejected if the client is an external host and the mail address or domain is the sender or recipient. • What to do with bounced messages, if the message is rejected by Email Firewall.
2.5 Setting Up Relays
57
•
• When there is a reverse-DNS requirement specified in the Network Connections configuration, the number of address components that are required to match when the sender is an internal sender or an external sender. The Outbound delivery rule, which specifies to route outbound mail using: • the outbound delivery routing method of the default routing rule. • DNS. • a combination of DNS plus a specified relay sequence if DNS is unavailable. • a specific relay or a sequence of relays. Outbound delivery rules also allow you to specify whether to allow or disallow external-to-external mail routing, as described in Configuring Email Firewall To Prevent Open Relaying on page 59.
•
The TLS settings, which are optional, and which include: • Whether TLS must be used for Email Firewall to accept inbound mail from that domain/address. • Whether TLS should be used for Email Firewall to send outbound mail, and if it should, then whether it should use TLS only if is available and otherwise send it anyway, or whether it must be used and if not available refuse to send the mail. Whenever outbound TLS is used, the server must present a trusted certificate during the TLS handshake. • When TLS is required to be used for either inbound mail acceptance or outbound mail delivery, the authentication requirements of the remote host’s certificate. When configuring routing rules for TLS, keep in mind that only the envelope address is considered.
Servers, Routing Rules and TLS By default, Email Firewall expects the name in the remote host’s TLS certificate to match the “expected” host name. The expected name is the remote relay host’s name.This name comes from • • 58
the routing rule when routing to an explicit relay host. the DNS when using an MX lookup.
Chapter 2: Setting Up Email Firewall Administration
The default algorithm can be overridden to tell Email Firewall exactly what name to expect in the certificate. This “designated domain” may be set on a per routing rule basis, but not on a per relay host basis. This option must be set if outbound relay hosts are specified with an IP address rather than a host name. Setting this option provides an added security feature by guarding against DNS attacks that attempt to replace the address of a MX host.
Configuring Email Firewall To Prevent Open Relaying If your Email Firewall system will be handling mail that originated outside of your organization, you will want to make sure that Email Firewall is not used as an open relay. The steps listed here will configure the inbound SMTP Relay to reject recipient addresses outside of your organization when the mail originates from outside of your organization. 1.
Ensure that the Network Connections table is configured accurately according to the rules described in Understanding Internal vs. External Networks on page 50.
2.
In the Mail Routing Rules table, ensure that the Default entry is configured to not accept mail from external clients when the address is a recipient. The same thing may also need to be done for address or domain name in this table that is external to your organization. The Default domain (*) Inbound Mail Acceptance rule must be configured to not accept Inbound Mail From External Clients when Address is a Recipient. This is the Email Firewall default setting for the default domain. To retain this configuration if editing the default domain, in the Set Up > Routing Rules > Inbound Acceptance page, under the Accept Mail From External Clients heading, do not mark the When Mail Address or Domain is a Recipient checkbox. When this checkbox is not marked, external-to-external routing is blocked.
2.5 Setting Up Relays
59
2.5.13 Setting Up Mail Routing Rules The options in the Routing Rules pages allow you to specify a mail domain, its inbound mail acceptance rules, outbound mail delivery rules, and optional TLS settings. For additional information on using the mail routing rules to prevent spam, see the Tumbleweed Email Firewall Anti-spam Best Practices Guide. To configure a mail routing rule: 1.
In the main menu, click Set Up.
2.
Under the Relays heading, click Routing Rules.
3.
In the Set Up > Relay centers page, Mail Routing Rules tab, click Add.
4.
In the Routing Rule name field, type a name for the rule. The name should be logically related to the rule you are planning to build. If no name is specified, the first domain in the list will be used as the name.
5.
Add routing addresses using either the Option 1 or Option 2 tab. 5a. For Option 1, type the addresses in the field. Separate multiple
addresses by a space, comma, semicolon or return. 5b. For option 2, click Browse to select a pre-existing plain text file containing addresses. 5c. Click Next. 6.
60
Configure the rule’s Inbound Mail Acceptance rules. See Figure 2.11. Specify acceptance rules for when mail is From Internal Clients, Senders and Recipients, and From External Clients, Senders and Recipients, by marking the appropriate checkboxes.
Chapter 2: Setting Up Email Firewall Administration
To prevent open relaying, do not accept mail from external clients when mail address or domain is a recipient, for addresses and domains external to your organization. Figure 2.11: Mail Routing Rules Details: Inbound Mail Acceptance Rules
7.
Use the Bounce Action drop-down list to select what to do when Email Firewall is returning a message that had been previously accepted by Email Firewall. See Figure 2.12.
Figure 2.12: Mail Routing Rules Details: Inbound Mail Bounce Actions
2.5 Setting Up Relays
61
The Bounce Action setting applies only to messages that must be returned by the SMTP Relay. If a policy action specifies that the Policy Engine should return a message in its entirety, the policy action overrides the SMTP Relay Bounce Action setting. 8.
Optionally, configure the RDNS Addresses Components Required to Match, see Figure 2.13. In the fields, specify how many components of an email address must match the sender’s DNS or domain name before the SMTP Relay is allowed to accept the mail. For example, you may want to use this feature to allow mail only from a particular company user that is sent from that company’s domains. If you use the RDNS matching requirements, keep in mind that this could block otherwise acceptable email sent from senders using ISP providers. Also, RDNS lookup may affect SMTP Relay performance.
Figure 2.13: Mail Routing Rules Details: RDNS Address Matching
For example, suppose you set the External Senders match requirement to 2, and the sender’s email address was
[email protected]. If the RDNS lookup revealed mail was sent from mail.example.com there would be a match of the two right-most components, and the mail would be accepted by the Email Firewall SMTP Relay. However, if the machine’s RDNS host is something other than example.com, for example, alternate.com, there is no match and the mail would be rejected by the Email Firewall SMTP Relay. 9.
Click Next.
10. Configure the rule’s Outbound Mail delivery options. See Figure 2.14.
Mark the appropriate radio button to use the Same as Default, DNS, DNS +
62
Chapter 2: Setting Up Email Firewall Administration
Relays,
or define a series of Relays. See2.5.13 Setting Up Mail Routing Rules on page 60 for more information.
Figure 2.14: Mail Routing Rules Details: Outbound Mail Delivery
10a. If you marked the either of the options to use relays, under the Enter the Relays in the order of priority heading, use the Relay Type drop-down list to select whether relay is a static Relay Host or MX for Domain. 10b.Complete the Relay Host or Domain Name field, and the port it connects on. 10c. Click Add to add it to the list. Repeat this process for additional relays to use. 10d.If there are multiple relays specified, mark the checkbox and use the Up and Down buttons to prioritize them.
11. Click Next. 12. Specify the TLS routing rules.
In order to configure TLS, a valid TLS certificate must first be imported and selected on the Setup TLS page. Until that has been done, the TLS options on this page are disabled. See 9.4 Setting Up Certificates for TLS on page 445 for more information.
2.5 Setting Up Relays
63
12a. If you have not yet set up TLS, click the TLS Setup link and
complete TLS setup, then return to the Set Up Routing Rules page and continue here. See 9.4 Setting Up Certificates for TLS on page 445 for more information. 12b.For Inbound TLS settings, if TLS is required, mark the Require TLS for Inbound Acceptance checkbox. If client authentication is required, mark the Client Authentication for Inbound Acceptance checkbox. This means that the certificate presented by the remote host for TLS authentication must be associated with either the domain of the remote host or a specified domain, as specified under the TLS Authentication heading. 12c. For Outbound TLS Settings, mark the appropriate radio button to specify whether Email Firewall should never use, attempt to use, or is required to use TLS for this rule. 12d.If TLS with client authentication is required for inbound acceptance, or if TLS is required for outbound delivery, mark the radio button to specify whether the certificate presented by the remote host should be associated with the domain of the remote host, or a specified domain. If the certificate must be associated with a specified domain, enter the domain name in the field. It is only necessary to specify a specific domain if mail from/to domains in this Routing Rule will be relayed by a host whose certificate is for a different domain (e.g. a service provider). If authentication is not required select encryption Only - No Authentication Required. With this option, the mail from/to domains and the domain certificate are not compared and the result of the validation of the certificate itself is ignored. Using the encryption Only - No Authentication Required option is a security risk because it allows for "man in the middle" (MITM) attacks. The security risk is that an outsider is able to read, insert and modify the messages that are exchanged between two parties without either party knowing that a compromise of their communication link has occurred. If the encryption Only - No Authentication Required option is enabled, there is no guarantee of the other party’s identity due to the lack of authentication.
64
Chapter 2: Setting Up Email Firewall Administration
13. When you have completed all the routing rules selections, click Save.
Unless you click Save in this page, none of the Outbound Delivery Routing Rules settings are saved to the database.
Setting Up Exact Matching for a Domain In some cases you may want to have one rule for a domain and a different rule for that domain’s subdomains. You can accomplish this by configuring one mail routing rule for Example.com and a different mail routing rule for *.Example.com. The Email Firewall SMTP Relay uses a “best match” algorithm (see Best Match Algorithm and Wildcards on page 66), so an email address like
[email protected] will match the first rule, while an email address like
[email protected] will match the second rule. This configuration allows you to have specific routing rules for a domain without matching on subdomains of that domain. To set up exact matching for a domain: 1.
In the main menu, click Set Up.
2.
Under the Relays heading, click Routing Rules and then click Add.
3.
Create a rule for the domain for which you want to do an exact match. 3a. Name the rule and make the appropriate selections. Follow the
steps in 2.5.13 Setting Up Mail Routing Rules on page 60. 3b. Specify the relay to use. 3c. Click Save. 4.
Create a second rule for all subdomains of that domain: 4a. Click Add. 4b. Name the rule and add the appropriate subdomains for which you
want the rule to apply (or use the * to apply to all subdomains). 4c. Specify to use DNS. 4d. Click Save.
For example: Example.com = 10.10.10.10 *.Example.com = DNS
The entry for Example.com is now an exact match.
2.5 Setting Up Relays
65
Best Match Algorithm and Wildcards The best match algorithm works as follows. Note the use and placement of the wildcard character (*) in the domain descriptions. If the Relay is considering the address , it will search for a matching rule in the following order: 1.
[email protected]
2.
host.domain.com
3.
user@*.host.domain.com
4.
*.host.domain.com
5.
user@*.domain.com
6.
*.domain.com
7.
domain.com
8.
user@*.com
9.
*.com
10. com 11. user@* 12. * (the default rule)
Editing Routing Rules To edit an existing mail routing rule:
66
1.
In the Mail Routing Rules page, click the routing rule name to open the rule.
2.
To change the name of the rule, enter the new name in the field. Then click Save.
3.
To change the inbound mail acceptance rules, click the Inbound Acceptance link to open the Edit Routing Inbound Rule page and make the desired changes. Then click Save.
4.
To change the outbound mail delivery rules, click the Outbound Delivery link to open the Edit Outbound Rule page and make the desired changes. Then click Save.
5.
To change the TLS requirements, click the TLS Settings link to open the Edit Routing TLS Rule page and make the desired changes. Then click Save.
Chapter 2: Setting Up Email Firewall Administration
See 2.5.13 Setting Up Mail Routing Rules on page 60 for more information about making these selections.
2.5.14 Address Rewriting Concepts The address rewriting rules in the Email Firewall SMTP Relay affect only the SMTP envelope addresses on a message. These are sometimes called the “routing addresses” or the “821 addresses” in reference to the SMTP protocol specifications RFC 821 and RFC 2821. The Email Firewall SMTP Relay will never modify any address that appears on any message content headers, including the TO and CC headers. (However, policies applied in the Policy Engine may modify these headers.) In this section, the term “address” refers to an SMTP envelope address unless otherwise noted. Address rewriting rules can be applied either during inbound message processing or during outbound message partitioning. Inbound SMTP address rewriting is performed by the Inbound SMTP relay, before the message is given to the Spam Analysis Engine or the Policy Engine. Outbound SMTP address rewriting is performed by the Partitioning SMTP Relay, before the message is processed by the Outbound SMTP Relay. Before configuring the rules, you need to carefully consider which of these places is more appropriate for your environment. In particular, you must consider the potential interactions with any Email Firewall policies that may be applied by the Policy Engine. This is especially true for the security and SPN policies. Following are a few points to consider. •
•
•
•
The Policy Engine performs the Email Firewall Directory search to see which policies apply to a recipient based on the envelope address. If you will be rewriting recipient addresses during inbound SMTP message processing, you may need to alter your Email Firewall directory or policy definitions accordingly. The Policy Engine takes the sender address from the message content, so sender policies are not affected by SMTP address rewriting, unless there is no FROM header in the message. For S/MIME encrypted or signed messages, changing the recipient or sender address could affect the ability to decrypt or verify the message when it is received. The Policy Engine may change the SMTP envelope address for individual users if the user record specifies a delivery address.
With these concepts firmly in mind, proceed.
2.5 Setting Up Relays
67
Address Rewriting Rules The SMTP Relay service will apply a designated set of address rewriting rules to the sender and to each recipient. A rule set is a set of address rewriting rules to be considered together. Rule sets must be uniquely named with a (Unicode) string that may be up to 50 characters. The SMTP Relay service must be told the name of the starting rule set for each of the following: • • • •
inbound message senders inbound message recipients outbound message senders outbound message recipients
Inbound address rewriting occurs after the sender and recipient acceptance rules have been applied. The acceptance rules are configured in the Web Admin on the Relay setup Routing Rules page. Outbound address rewriting occurs before partitioning. This is necessary since the rewriting process may change the domain(s) to which the message will be sent. Each rule in a rule set consists of a match string (required), a rewrite action, and a branch specifier. The rewrite specifier and the branch specifier may be empty, although at least one of these must be specified for the rule to be meaningful. The concept here is that given an address and a current rule set, the Relay searches for a rule within the rule set whose match string best matches the address. If no match is found, no change is made to the address and the process terminates. If a match is found, the rewrite action for that rule, if present, is applied to the address. Then, if the branch specifier is empty, the process is complete. If it is not empty, the rule set identified by the branch specifier becomes the current rule set and the process repeats itself. This iterative process creates the possibility of infinite address rewriting loops. To prevent this from happening, you may also configure a maximum number of rule sets that may be considered for any one address. If the maximum is exceeded, the process will terminate and the initial address is changed to the modified address as of the time that the process terminated.
Match Specifiers A rewrite rule match specifier is a US-ASCII string literal that may include the wildcard characters. (US-ASCII strings are used because legal SMTP addresses are limited to this character set.) The wildcard characters are the asterisk (*), which will match one or more characters, and the question mark('?), which will match exactly one character. All matching is performed case-insensitively.
68
Chapter 2: Setting Up Email Firewall Administration
The following escape sequences may be used in match specifiers: • • •
Use the sequence =s to match the asterisk * Use the sequence =q to match the question mark ? Use the sequence == to match the equal sign =
In general, addresses are compared against the match specifiers using a “best match” approach. An exact match is always preferred over a wildcard match. The algorithm considers the address and the match patterns starting from the right side of the address string and then moving back towards the left. As the characters of the string are considered against the list of match specifiers, a wildcard match followed by an exact match to the right is preferred over an exact match of the left characters followed by a wildcard match. This is best illustrated with an example. Consider the following set of match specifiers. 1.
*
2.
*@example.com
3.
*@*.com
4.
user@*.com
5.
user@example.*
6.
user@*.*
7.
*@*
8.
*@*.*
Any of these specifiers by themselves would match the address string
[email protected]. However, when considered together within the same rule set, the best match is specifier 2, because there is an exact match on the suffix @example.com. Specifier 3 would be the best mach for the string
[email protected]. Specifier 8 would be the best mach for
[email protected]. Using this same list of match specifiers, consider the address
[email protected]. Look at rules 3 and 4. Either of these rules could match this address. But specifier 4 is used in this case because the exact match is preferred over the wildcard in specifier 3.
Rewrite Actions A rewrite action is a US-ASCII string literal that specifies how an address that matches the match specifier should be rewritten. Within the rewrite action string, substitutions may be made by specifying the percent sign (%) followed by a number. The number represents the character or characters that matched the corresponding wildcard in the match specifier. (Two consecutive percent signs 2.5 Setting Up Relays
69
may be used to escape the percent sign character.) The examples in the next section illustrate how matching and substitution work.
Matching and Substitution Examples Assume that the rules in Table 2.3, rule set “Sample,” are contained in a single rule set. Table 2.3: Rule Set “Sample” Match Specifier
Rewrite Action
Branch Specifier
*@*.example.com
%1@%2.widget.com
*@example.com
%
[email protected]
Table 2.4 shows how some sample addresses would be modified by the “Sample” rule set. Table 2.4: How The “Sample” Rule Set Affects An Address Before
After
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
A Complete Example In this example, suppose that we would like to configure the SMTP Relay to do the following transformations on any SMTP messages received.
70
1.
Change any messages sent to any host within the domain abc.com to be changed so the domain name is simply xyz.com.
2.
For any address sent to a specific host within the domain xyz.com, remove the hostname so that the domain specifier is simply xyz.com.
3.
For any addresses sent to domain xyz.com with an underscore in the mailbox name, replace the underscore with a period.
Chapter 2: Setting Up Email Firewall Administration
The following table shows two rule sets that work together to accomplish these goals. The rule set named “Start” must be designated as the inbound recipient start rule. Table 2.5: Rule Set Transformations Rule Set Name
Match Specifier
Rewrite Action
Branch Specifier
Start
*@*.abc.com
%
[email protected]
XYZ Mailbox
Start
*@abc.com
%
[email protected]
XYZ Mailbox
Start
*@*.xyz.com
%
[email protected]
XYZ Mailbox
Start
*@xyz.com
XYZ Mailbox
XYZ Mailbox
*_*@xyz.com
%1.%
[email protected]
2.5.15 Setting Up Address Rewriting There are three types of rules that can be created: • • •
Replace Domain:
Replaces all instances of the specified domain with a different specified domain. Optionally, also removes subdomains. Remove Subdomains: Removes all subdomains from addresses with a specified domain. Custom: Allows you to define your own rule based on match specifiers and rewrite actions. Also allows branching to another rule.
To create a Replace Domain rule: 1.
In the Set Up > Relay Centers > Address Rewriting page, type a name for the rule in the Rule Name field and click Create.
2.
In the Create Rule page, see Figure 2.15, mark the Replace Domain radio button and type the domain to be replaced in the first field and the domain it should be replaced with in the next field.
3.
Optionally, mark the Remove subdomains checkbox.
4.
Click Save.
2.5 Setting Up Relays
71
. Figure 2.15: Address Rewriting Rule Creation Options
5.
72
Verify the new rule appears in the Rule Name column and that the type of rule is correct. See Figure 2.16.
Chapter 2: Setting Up Email Firewall Administration
Click Edit if you need to make any changes, make the changes, then click Save. Figure 2.16: Address Rewriting Replace Domain Rule Created
To create a Remove Subdomains rule: 1.
In the Set Up > Relay Centers > Address Rewriting page, type a name for the rule in the Rule Name field and click Create.
2.
In the Create Rule page, mark the Remove Subdomains radio button and in the adjacent field, type the domain from which subdomains should be removed.
2.5 Setting Up Relays
73
3.
Click Save.
4.
Verify the new rule appears in the Rule Name column and that the type of rule is correct. Click Edit if you need to make any changes, make the changes, then click Save.
Creating Custom Address Rewriting Rules The SMTP Relay service will apply the designated set of address rewriting rules to the sender and to each recipient. A rule set is a set of address rewriting rules to be considered together. Rule sets must be uniquely named with a (Unicode) string that may be up to 50 characters. The Email Firewall SMTP Relay service must be told the name of the starting rule for each of the following: • • • •
inbound message senders inbound message recipients outbound message senders outbound message recipients
Inbound address rewriting occurs after the sender and recipient acceptance rules have been applied. The acceptance rules are configured in the Web Admin on the Set Up > Relays > Routing Rules page. Outbound address rewriting occurs before partitioning. This is necessary because the rewriting process may change the domain(s) to which the message will be sent. To create a Custom rule:
74
1.
In the Set Up > Address Rewriting page, type a name for the rule in the Rule Name field and click Create.
2.
In the Create Rule page, mark the Custom radio button.
3.
Type a match specifier in the field. See Match Specifiers on page 68 for more information.
4.
Type a rewrite action in the field. See Rewrite Actions on page 69 for more information.
5.
Optionally, use the drop-down list to select a Branch to rule.
6.
Click Add.
7.
Optionally, repeat steps 2-5 to add additional rules.
8.
Click Save.
Chapter 2: Setting Up Email Firewall Administration
After creating address rewriting rules, use these options to select them for the Inbound and Outbound rules. 1.
Use the drop-down list to select an Inbound Sender Address Starting Rule and type the maximum number of branches in the field.
2.
Use the drop-down list to select an Inbound Recipient Address Starting Rule and type the maximum number of branches in the field.
3.
Use the drop-down list to select an Outbound Sender Address Starting Rule and type the maximum number of branches in the field.
4.
Use the drop-down list to select an Outbound Recipient Address Starting Rule and type the maximum number of branches in the field. If no rule is selected, no rewriting will be performed for addresses in that context.
5.
Click Save.
2.5.16 Testing Address Rewriting Assuming the queries seem to be working as expected, set the event logging level for the Email Firewall SMTP Relay to Trace. Restart the Email Firewall SMTP Relay service. (Restarting the service should not be necessary, but it is a good idea to do it just to be absolutely sure that all modified settings are being picked up correctly by the Relay service.) Then, send a sample message through Email Firewall. Look in the event log for the address rewriting events logged by the STMP Relay service to see if rewriting is happening as expected. The event description will show the address string both before and after the rewriting. • • • •
Event 1036 is used for inbound sender rewriting Event 1040 is used for inbound recipient rewriting Event 1056 is used for outbound sender rewriting Event 1057 is used for outbound recipient rewriting
Warning events are logged at level Normal whenever an attempt to rewrite an address fails for any reason, including misconfigured rewriting rules. The event IDs for these warnings are 1084, 1085, 1086, and 1087.
2.5 Setting Up Relays
75
2.5.17 SMTP Relay and Message Retry Configuration When a message cannot be delivered immediately, the SMTP Relay can be configured to: • • •
wait a configurable amount of time before trying to send the message again. try to send the message a configurable number of times before declaring the message undeliverable. send a notification to the sender when the message is delayed.
The SMTP Outbound Message Retry Intervals are configured using the settings in the Retry queue. See 3.2.4 Setting Retry Queue Retry Intervals on page 123. If the number of delayed messages waiting in the Retry queue exceeds a configurable number, settings in the Retry queue setup Action tab allow a notification to be sent informing the administrator that the Retry queue message volume has been reached or exceeded. See 3.2.2 Setting Up Queue Actions on page 120.
2.5.18 Troubleshooting the SMTP Relay Service This section describes some common SMTP Relay service issues and troubleshooting procedures.
SMTP Relay Service Not Accepting Messages Full SQL Server file groups can cause the Email Firewall SMTP Relay service to stop accepting messages. The available space in seven file groups configured for the Email Firewall database affect inbound message acceptance. These are: MMSBodyChunk MMSBodyChunkStatic MMSEventData MMSMessageData MMSMessageDataStatic MMSMessageDataPropertiesStatic MMSTransactionLog
If the used space of any of these file groups is greater than 80%, the SMTP Relay service will temporarily stop accepting incoming messages until the used
76
Chapter 2: Setting Up Email Firewall Administration
space goes below 75%. A warning will be logged with the list of file groups and the percentage of space used. This full file group problem can be solved by increasing the file size of the file group. Before doing so, you need to determine which file group size needs to be increased. When you have determined this, increase the file group size. Procedures for doing so are described in3.6.1 Troubleshooting Inbound Queue Backups -- Full File Groups on page 139.
Email Firewall Relay Not Identifying Itself Properly The SMTP Host Name configuration parameter for the Email Firewall Relay service affects all of the following: •
The message returned in response to new inbound connections: Example: 220 server1.example.com SMTP Relay Service ready
• • • •
The message returned in response to the EHLO command. The message returned in response to a QUIT command. The Received: header inserted into all messages received by the inbound SMTP Relay. The HELO and EHLO commands generated by the outbound SMTP Relay: Example: HELO server1.tumbleweed.com
• •
The Message-Id: header generated for new notifications created by the Email Firewall SMTP Relay. The Reporting-MTA: header in delivery status notifications (DSNs).
In some circumstances, Email Firewall may not identify itself with a fully qualified host name. This is because Email Firewall gets the hostname it uses to identify itself from the host machine operating system's TCP/IP properties. If this information is not configured properly, the connection may be rejected. If your server does not identify itself using its fully qualified host name, some connecting hosts or destination domains may reject your messages with an error message similar to the following: Unexpected recipient failure - 504 server1: HELO command rejected: need fully-qualified hostname
To adjust the host name identification, you may need to adjust the TCP/IP properties. In particular, Email Firewall looks for the Windows Registry values named Hostname and Domain under the following key: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
2.5 Setting Up Relays
77
If the Domain value is missing, Email Firewall will try to use the value of DhcpDomain. Although Windows stores these values in the registry, they are usually edited from the Network Control Panel, TCP/IP Properties. To adjust the hostname identification, you can adjust the operating system's TCP/IP properties. To adjust the TCP/IP properties in Windows 2000: 1.
In My Computer, select Properties.
2.
In the Network Identification tab, click Properties.
3.
In the Identification Changes dialog box, click More.
4.
Type the Primary DNS suffix of this computer information: For example, for server1.example.com, the server name is server1 and the Primary DNS suffix is example.com.
5.
Click OK, then OK, and then OK to close the open dialogs.
Alternatively, you may want to override the host machine’s TCP/IP properties by specifying the value as described in Specifying the Relay Host Name on page 39.
Troubleshooting Outbound Message Backlogs If outbound SMTP performance seems to be below expectations, there are two relay parameters, Message Backlog Per Host Percent and Max Message Backlog, that may be investigated. Under normal circumstances these parameters should not need to be edited. Following is a description and explanation of how the SMTP Relay parameters Message Backlog Per Host Percent and Max Message Backlog are used. As each outbound SMTP Relay service processes a message from the outbound queue: after initiating a database transaction on that message, the next step is for the Relay to use the appropriate routing rule to determine the ordered sequence of relay hosts to which that message may be routed. This may or may not involve DNS queries, depending on the routing rule. Once the Relay has decided that it is going to attempt to relay a message to a specific host, it checks to see if it already has any connections open to that host. If so, the SMTP Relay may decide to keep the database transaction open and put the message into a cache of pending messages to be sent over these existing connections. This cache is where that the backlog configuration parameters come into play. 78
Chapter 2: Setting Up Email Firewall Administration
It is important to keep in mind that the backlog cache is a per-Relay service data structure. It is not a common cache that is shared by all outbound SMTP Relay services referencing the same Email Firewall database. The Max Message Backlog parameter indicates the maximum number of messages that are permitted to be in the backlog cache for any one SMTP Relay. In other words, the Max Message Backlog value is a limit on the number of database transactions that may be kept alive by an outbound SMTP Relay in the background while it is actively working on outbound message transactions. The Email Firewall SMTP Relay imposes a limit on the number of messages in the backlog cache that will be routed to any one host (IP address). By default, no more than 20 percent of the messages in the backlog cache can be cached for the same relay host. The Message Backlog Per Host Percent parameter allows this percentage limit to be modified. The default value for Max Message Backlog is 10, but it is recommended that you increase this value to 20 if there will be only one outbound SMTP Relay service actively referencing an Email Firewall database. It is recommended that you do not set the value higher than this because of the risk of consuming too many SQL Server database locks. Since the default value for Message Backlog Per Host Percent is 20, Email Firewall will allow only 2 messages in the backlog cache at one time that need to be routed to the same host (because 2 is 20 percent of 10). If you have increased the Max Message Backlog to 20, there may be up to 4 messages in the backlog cache for one host (4 is 20 percent of 20). It may improve outbound mail performance to increase the Message Backlog Per Host Percent if all mail is routed to a very small number of relay hosts. For example, if all internal mail is routed to an internal mail server and all external mail is routed to another relay host in the DMZ, it would make sense to increase this parameter to 50. When determining the settings for these two parameters, you should also take into consideration the maximum connections per host value that has been set on the Setup > Relays page. For example, if you have configured the maximum connections per host to 3, you might want to make sure that the backlog cache is configured to allow at least 3 messages to be routed to the same host for best performance. To make changes to these parameters, use the Configuration Editor in Email Firewall Web Admin. See 10.11 Using the Configuration Editor on page 609.
2.5 Setting Up Relays
79
Troubleshooting TLS • The TLS certificate domain name match must be exact. The designated domain can be used to override this in some situations. • MX records should specify a host name. MX records that specify an IP address instead of a host name will cause problems for TLS. • Root certificates must be trusted for TLS purposes. Use Web Admin to set this option on root certificates that are being used by remote domains’ certificates. • Inconsistencies between Mail Routing Rules and Network Connections can cause problems. For example, the Routing Rule may require TLS, but the client connection comes from a host for which TLS has not been enabled. • If the Network Connections option is set to request a certificate, that certificate must be trusted for TLS to work. • If Email Firewall event logging is insufficient to diagnose problems, use the EMF Debug Log Capture tool. Forward the results to Tumbleweed Global Support for assistance if needed.
2.6
Setting Up Anti-virus and Anti-spam The Email Firewall Download Service is responsible for downloading the virus pattern files and anti-spam filter data. Email Firewall uses the McAfee Olympus anti-virus scanning engine and virus pattern files from Network Associates to protect your email from receiving or propagating viruses. The anti-spam filters are provided by the Tumbleweed Message Protection Lab. The frequency of the updates is configurable. For more information about the Message Protection Lab, see 7.9 The Tumbleweed Message Protection Lab on page 355. Both settings are accessed from the Setup page Anti-virus and Anti-spam heading Updates link. When the Email Firewall server is located behind a firewall there may be issues with virus pattern file downloads and anti-spam filter updates. A Use Passive Mode option for updates is available for this case. Enabling passive mode may allow the anti-virus downloads and anti-spam updates to work for Email Firewall without having to request that changes be made to the local firewall configuration. Occasionally, virus outbreaks occur extremely rapidly. In these cases the virus scanner may require extra pattern files, called extra.dat files. An extra.dat
80
Chapter 2: Setting Up Email Firewall Administration
file supplements the normal .dat files and can find, and usually clean, a new virus or number of viruses. However, keep in mind that although extra pattern files include the most recent virus signatures, they are still in beta testing. If the option to check for extra.dat files is selected, Email Firewall will look for, download and use an extra.dat file if one is available. Checking for extra.dat files occurs concurrently with checking for regular pattern files. The Email Firewall Download service uses FTP to automatically retrieve the latest virus pattern file and anti-spam filter updates. If required by your environment, Email Firewall can be configured to use authenticated access to the FTP Proxy Server. The Dynamic Anti-spam Service settings determine which messages are processed by the service, and whether the service is enabled or disabled. These settings are accessed from the Setup page age Anti-virus and Anti-spam heading Dynamic Anti-Spam Service (DAS) Settings link.
2.6 Setting Up Anti-virus and Anti-spam
81
2.6.1
Setting Up Anti-virus and Anti-spam Downloads To setup anti-virus update options: 1.
On the Email Firewall main menu, click Set Up to open the Set Up page.
2.
In the Set Up page, Anti-virus and Anti-spam heading, click Updates to open the Set Up > Anti-Virus and Anti-Spam Updates page.
3.
The Anti-virus Updates tab shows the current virus scanning engine version, with its last update date, and the virus pattern version and the date it was last updated. See Figure 2.17. The virus scanning engine must be updated manually.
Figure 2.17: Setting Up Virus Scanning Options
3a. If the FTP server should use passive mode, mark the Use Passive Mode
checkbox.
3b. To manually start a virus scanning engine update, click Update Scan Engine Now.
82
Chapter 2: Setting Up Email Firewall Administration
4.
It is recommended that you keep the virus pattern version automatic update configuration enabled. By default, virus pattern file updates are checked hourly. 4a. To change the frequency of virus pattern version automatic
4b. 4c. 4d. 4e.
downloads, use the text field and drop-down list to select Hours, Days, Weeks or Minutes. Optionally, mark the Check for extra pattern files checkbox to check for extra pattern files. If the FTP server should use passive mode, mark the Use Passive Mode checkbox. To manually start an update, click Update Pattern File Now. Click Save.
To setup anti-spam filter update options: 1.
On the Email Firewall main menu, click Set Up to open the Set Up page.
2.
In the Set Up page, Anti-virus and Anti-spam heading, click Updates to open the Set Up > Anti-Virus and Anti-Spam Updates page.
3.
The Anti-spam Updates tab shows the current anti-spam filter version and its last update date. See Figure 2.18. It is recommended that you keep the anti-spam filter version automatic update configuration enabled. By default, anti-spam filter updates are checked hourly.
4.
Click Save.
5.
The anti-spam filter data can be updated manually. Click Update Anti-spam to start an update.
Filter Now
Figure 2.18: Setting Up Anti-spam Updates
2.6 Setting Up Anti-virus and Anti-spam
83
To set up the FTP proxy server options: 1.
On the Email Firewall main menu, click Set Up to open the Set Up page.
2.
In the Set Up page, click Proxy Servers to open the Proxy Servers page.
3.
On the FTP Proxy tab, specify the TCP/IP proxy Address and Port Email Firewall will use to access and download virus and anti-spam updates. The default port is 80.
4.
If you use Authenticated Access to connect to your FTP proxy server, enter the User Name and Password.
5.
If the FTP server should use passive mode, mark the Use Passive Mode checkbox.
6.
Click Save.
Virus Scanning Heuristics Email Firewall enables the heuristics functionality of the Olympus Virus Engine by default. There in no option within Email Firewall to disable this functionality. These advanced heuristic technologies, called ViruLogic, seek out previously undiscovered viruses. ViruLogic has the intelligence to know what characteristics viruses do and do not exhibit, providing exceptional virus detection with the fewest possible false alarms. When a new virus is confirmed, the cure is generated and distributed to infected systems. VirusScan employs Virtran, a virus-specific scripting language that creates detectors and cleaners in seconds; a quicker fix for the most ferocious new viruses.
2.6.2
Setting Up Dynamic Anti-spam Service Settings When the Dynamic Anti-spam Service is enabled, messages are processed by the Spam Analysis Engine before being placed in the Inbound queue. When disabled, they are not processed by the Spam Analysis Engine but are sent immediately to the Inbound queue. For additional information about setting up the Dynamic Anti-spam Service, see Chapter 7, Dynamic Anti-Spam Service. To enable or disable processing by the Spam Analysis Engine: 1.
On the Email Firewall main menu, click Set Up to open the Set Up page.
2.
In the Set Up page, Anti-virus and Anti-spam heading, click Dynamic AntiSpam Service (DAS) Settings to open the Set Up > Dynamic Anti-spam Service Settings page.
84
Chapter 2: Setting Up Email Firewall Administration
3.
On the DAS Status tab, to enable the Dynamic Anti-spam Service when disabled, click Enable. This means that messages will be processed by the Spam Analysis Engine before being placed in the Inbound queue. To disable the Dynamic Anti-spam Service when enabled, click Disable. This means that messages will not be processed by the Spam Analysis Engine.
The following sections provide information and instructions for the options on the Set Up > Dynamic Anti-spam Service Settings page, DAS Settings tab: • • •
Add spam categories as X-Headers to scanned messages Do not scan messages received from internal networks Do not scan messages larger than 200 KB in size
Adding Spam Categories to Scanned Messages The Spam Analysis Engine categorizes potential spam messages so that each dubious message is initially analyzed to determine whether there is high or moderate confidence that the message is spam. If so, then the message is further assessed to determine whether the message contains certain kinds of spam content, defined by category. These spam content value categories include adult content, scam content, and broadcast content. Whenever the Spam Analysis Engine determines that a dubious message is spam, by default, Tumbleweed-specific message properties are inserted into the message before it is moved to the Email Firewall Inbound queue. Using the names of these properties and the expected values they might contain, you can create Email Firewall policies to check for the presence of those properties or to compare the value of the properties against one or more string constants. The Add spam categories as X-Headers to scanned messages option adds Tumbleweed-specific X-headers to messages that are identified as containing spam content. These X-headers identify spam in the same way that the messages properties do. So, in the same way that you can create policies that check for the names of the message properties and the expected values they might contain, you can create Email Firewall policies to check for the presence of these headers. See 6.11.2 What a DAS Policy Should Look For on page 316 for more information. • •
To enable the Spam Analysis Engine to add the spam categories as Xheaders, mark the checkbox. To disable the Spam Analysis Engine from adding the spam categories as X-headers, unmark the checkbox.
2.6 Setting Up Anti-virus and Anti-spam
85
Do Not Scan Messages Received From Internal Networks The determination whether a network is internal or external is made in the Setup > Relays > Network Connections page. The SMTP Relay service places a message property on each message to indicate whether the message was received from an internal or an external SMTP client. The Spam Analysis Engine uses this property to bypass messages originating from within the organization. This internal message bypass is an optimization which assumes no spam messages will originate from within an organization, and no Email Firewall policies will be defined to look for spam properties on messages where the sender address is in an internal domain. If either of these assumptions are not valid for your organization, this option can be enabled so that all messages will be scanned regardless of the SMTP client location. • •
To enable the Spam Analysis Engine to scan messages received from internal networks, mark the checkbox. To disable the Spam Analysis Engine from scanning messages received from internal networks, unmark the checkbox.
Do Not Scan Messages Larger Than 200 KB In Size By default, messages that are larger than 100KB are not analyzed by the Spam Analysis Engine. This large message bypass is an optimization which assumes that most spam messages are relatively small in size, and research by the Message Protection Lab supports this assumption. If this assumption is not valid for your organization, or if you want the message analysis performed for all messages regardless of size, this option and limit value are configurable. •
•
86
To prevent the Spam Analysis Engine from scanning messages larger than 100KB, mark the checkbox. To prevent the Spam Analysis Engine from scanning messages larger or smaller than 100KB, type an integer in the field and mark the checkbox. To allow the Spam Analysis Engine to scan all messages regardless of size, unmark the checkbox.
Chapter 2: Setting Up Email Firewall Administration
2.7
Setting Up Global Policy Settings The global policy settings for Peak Time, Archive, and other Options define global policy actions that apply to all Email Firewall policies that use any of these policy actions. Individual Email Firewall policies are viewed, created, modified and deleted in the Policies page. To work with the global policy options, click Set Up in the left menu, then under the Policies heading click General Settings to open the global policy settings page. The global options are available on the Peak Time, Archive, and Options tabs. There are also global policy-based routing settings that apply to all Email Firewall policies that select this option. This option allows you to route messages that trigger a policy that specifies policy-based routing as a policy action to a specified domain. To work with the global policy-based routing options, click Set Up in the left menu, then under the Policies heading click Policy-based Routing to open the policy-based routing page.
2.7.1
Setting Up Peak Time for Policy Actions The global Peak Time setting allows you to defer messages to low traffic hours. When Peak Time is enabled, you can create policies with Peak Time restrictions. For example, you may want to create a number of different policies, each of which defers delivery of the messages triggering those policies to offpeak hours. Examples include policies to defer very large files or files containing certain types of media content. Figure 2.19 shows the peak time settings. Note that separate peak times can be defined for weekdays, Saturdays, and Sundays. To enable peak time restrictions, mark the checkbox beside each option. To remove peak time restrictions, unmark the checkbox. See Chapter 6, Creating and Editing Policies for more information on using Peak Time as a policy action.
2.7 Setting Up Global Policy Settings
87
Figure 2.19: Peak Time Configurable Settings
2.7.2
Setting Up Archive for Policy Actions The global Archive setting allows you to back up some or all of the messages that flow through your organization. When archiving is enabled, you can select Archive as a policy action when creating a policy. The global archive action options are shown in Figure 2.20 and include: • • • • •
Forwarding archived messages to an email address. Writing archived messages to a file for later viewing. Digitally signing the archived messages automatically, to verify authenticity. Archiving messages that were not delivered. Options for handling messages that originally contained a virus.
For example, you may want to create a policy that archives all messages that trigger a confidentiality policy. The global settings on the Archive tab determine the action Email Firewall performs on a message that triggers the policy when Archive is selected as a policy action. When the archive file size reaches a configurable limit, the global File Archive option can be set to: 88
Chapter 2: Setting Up Email Firewall Administration
• •
Stop the service. Stop accepting messages.
If archiving messages is critical to your organization, you should choose to stop the service altogether when the file size reaches that limit. Figure 2.20: Setting Up Archiving
If you need to keep copies of all messages sent regardless of delivery status, you can enable the option to archive messages even if they were not delivered. However, there is a special consideration to be aware of when configuring the Do not archive undelivered messages option. When the option to archive undelivered messages is enabled (i.e., when the checkbox is not marked), if an archiving policy is set to archive the original or decomposed message and the message gets quarantined or detained, on release from the quarantine or detention queue the message is archived “as sent” and not original/decomposed as specified in the archiving policy. When the option to archive undelivered messages is enabled (i.e., when the checkbox is not marked), Email Firewall archives messages “as per policy,” which means that if the archive policy action was set to archive the original or decomposed message, an infected message is archived if the original message has a virus.
2.7 Setting Up Global Policy Settings
89
Archiving Options for Virus-Infected Messages You can specify how to handle archiving of messages when the original message is infected with a virus. See Figure 2.21. One option is to archive messages according to the policy settings, which means that if the archive policy action is set to archive the original or decomposed message, an infected message is archived if the original message had a virus. This option should only be used with full understanding of this possible result. A second option is to override the policy settings and always archive the infected message “as sent” by Email Firewall. This option ensures that a clean copy of the message is archived. However, this feature may also result in archiving of multiple copies of the message if the Policy Engine partitioned the message, e.g., if different policies were applied to different recipients. There is also an option to not archive an infected message at all. Figure 2.21: Archiving Options for Virus-Infected Messages
90
Chapter 2: Setting Up Email Firewall Administration
To specify archiving options for infected messages: 1.
Mark the radio button to select one of the archiving options: • Do not Archive • Override policy settings and always archive the message as sent by Email Firewall
• Archive messages according to policy settings Selecting the option to Archive messages according to the policy settings will result in archiving an infected message.
2.
2.7.3
Click Save.
Setting Up Other Global Policy Options Email Firewall provides global message scanning options to help detect problem files. These options are shown in Figure 2.22 and include: • • • • •
Scanning all bytes of non-text attachments for text strings. Marking message text parts using unsupported character sets as decomposition failures. Marking messages with invalid MIME structure as decomposition failures. Isolating each BCC recipient on a separate copy of the message. Quarantining all messages that grow to exceed a configurable size during decomposition.
2.7 Setting Up Global Policy Settings
91
•
Quarantining deeply nested MIME messages.
Figure 2.22: Global File Scanning Policy Options
92
Chapter 2: Setting Up Email Firewall Administration
Scanning Bytes of Non-Text Attachments Email Firewall can perform enhanced content scanning on text strings in nontext file attachments. This feature is primarily intended to help catch the inadvertent leaking of confidential material in the slack space of structured documents, such Microsoft Office documents, for example. This enhanced content scanning is performed by physically scanning the entire attachment file and then, prior to scanning for text, removing sequences of non-printable characters. This decomposition and scanning is in addition to the normal decomposition of documents. When this feature is enabled, the physical text extraction process can be performed on all attachments that are determined to be non-text attachments. So, for example, this process is applied to a document extracted from a .zip archive, but would not be applied to a plain text file. This enhanced scanning option is available as a global feature. If your security needs are such that the inclusion of slack-space text in a document could compromise your organization’s security, then enable this option. However, because of the additional processing that must be performed on every attachment, enabling this option will affect Email Firewall performance. Therefore it is recommended that you leave this option disabled unless you are concerned about hidden text that may be inadvertently transferred in the byte stream of binary attachments. For additional information about Email Firewall file scanning, see Appendix A, File Types Scanned.
Limitations in Scanning Non-Text Attachments • When this feature is enabled, Email Firewall assumes characters are in the local code-page of the Policy Engine machine. This means any Unicode or multi-byte characters are not recognized, nor is any other encoding. • Enabling this feature may cause double counting of some words or phrases found in attachments. For this reason, if your organization will enable this feature it is recommended that you not use weighted word lists in your Email Firewall policies.
2.7 Setting Up Global Policy Settings
93
To enable physical file scanning: 1.
In the left menu, click Setup.
2.
In the Setup page, Policies heading, click General Settings and navigate to the Options tab.
3.
In the Options tab, strings checkbox.
4.
Click Save.
mark the Scan all bytes of non-text attachments for text
Marking Text Parts That Use Unsupported Character Sets Email Firewall can perform content scanning on text/plain parts. If there is no character set specifier, Email Firewall assumes that the text is ASCII, as per the RFCs. But if there are any non-ASCII characters found, the part will be marked as having caused a decomposition failure. Email Firewall will also mark any text parts where a character set is specified and it is not one that can be mapped to Unicode (i.e., it is an unsupported character set). To enable marking of text parts using unsupported character sets: 1.
In the left menu, click Setup.
2.
In the Setup page, Policies heading, click General Settings and navigate to the Options tab.
3.
In the Options tab, mark the Mark message text parts using unsupported character sets as decomposition failures checkbox.
4.
Click Save.
5.
Create a Decomposition errors policy to catch messages that cause decomposition failures and specify the action Email Firewall should take when it encounters this type of message.
Marking Messages With Invalid MIME Structure or Illegal Character Encoding as Decomposition Failures The Mark message with invalid MIME structure or illegal character encoding as decomposition failures option is similar to the Mark message text parts using unsupported character sets as decomposition failures option. Email Firewall attempts to translate all messages from their designated character set to Unicode so that the Email Firewall Policy Engine can accurately scan the message. If Email Firewall is unable to translate the message because it contains illegal characters or encoding sequences, then it will be marked as a decomposition error if this option is enabled.
94
Chapter 2: Setting Up Email Firewall Administration
This option should remain enabled if you have security concerns about messages that cannot be successfully evaluated by Email Firewall text scanning policies and have deployed a policy that catches messages that experience decomposition errors. Some examples of invalid or corrupted MIME structures include: • •
invalid boundary string, e.g., high ASCII characters, 53_92_9.EEAP×I\", 10B.8CD.6DDl4üP48þP4& missing inner MIME subparts, e.g., given Content-Type multipart/alternative and boundary, but inner MIME parts are not presented
With this option enabled, you should create a Decomposition errors policy to block messages that cause decomposition failures and specify the action Email Firewall should take when it encounters this type of message.
Isolating BCC recipients on Separate Copies of the Message This option allows enabling and disabling of the Policy Engine’s BCC partitioning function. To enable isolating BCC recipients on separate copies of the message: 1.
In the left menu, click Setup.
2.
In the Setup page, Policies heading, click General Settings and navigate to the Options tab.
3.
In the Options tab, mark the Quarantine all messages that grow to exceed 100 MB in size during decomposition checkbox and optionally change the MB size.
4.
Click Save.
2.7 Setting Up Global Policy Settings
95
Quarantining Messages That Grow to Excessive Size This option allows you to specify the maximum message decomposition size. When this option is enabled, Email Firewall will quarantine messages that grow to exceed the specified size during decomposition. Messages quarantined by this global policy option are tagged with the Decomposition Size Limit tag. This option is useful in combatting Denial of Service (DoS) attacks. To enable quarantining of messages that grow to excessive size: 1.
In the left menu, click Setup.
2.
In the Setup page, Policies heading, click General Settings and navigate to the Options tab.
3.
In the Options tab, mark the Quarantine all messages that grow to exceed 100 MB in size during decomposition checkbox and optionally change the MB size.
4.
Click Save.
Quarantining Deeply Nested MIME Messages Deeply nested MIME messages are those with attachments inside attachments, recursively. When this option is enabled Email Firewall will quarantine messages with a nesting depth that exceeds a specified number during decomposition. Messages quarantined by this global policy option are tagged with the Decomposition Depth Limit tag. This feature helps you to prevent Denial Of Service attacks or message looping that results from deeply nested MIME messages. The configurable parameter specifies the number of nesting levels after which decomposition should stop and the message be passed to the Default quarantine queue, tagged with the Decomposition Depth Limit tag. To enable quarantining of deeply nested MIME messages:
96
1.
In the left menu, click Setup.
2.
In the Setup page, Policies heading, click General Settings and navigate to the Options tab.
3.
In the Options tab, mark the Quarantine messages that have a MIME nesting depth of more than [200] levels checkbox and optionally change the number of levels.
4.
Click Save.
Chapter 2: Setting Up Email Firewall Administration
2.7.4
Setting Up Policy-based Routing Policy-based Routing (PBR) allows you to route outbound mail using a domain specified by a policy. This policy-based route overrides any rule that otherwise would have been applied based on the recipient's address. This domain or address is used by the SMTP relay as the mail routing rule. The domains specified on this page can be selected during policy creation, as a sub-selection of the Deliver Normally, Defer or Detain policy dispositions. When a message triggers a policy that specifies policy-based routing as a policy action, the message will be routed according to the closest matching Relay Routing Rule associated with the domain selected. For more information on routing rules, see 2.5.12 Mail Routing Rules Overview on page 57. One of the primary applications of PBR is distributed redirection. In this deployment environment, it is expected that there would be multiple Email Firewall servers handling mail and routing it to a co-hosted Email Firewall/IME or Secure Messenger pair for redirection. In this case it is important to set up only the required redirect policies on the co-hosted Email Firewall server. See Avoiding Infinite Message Looping on page 99 for additional cautions in PBR setup.
2.7 Setting Up Global Policy Settings
97
To add domains used for policy-based routing: 1.
In the Setup page, Policies heading, click Policy-based Routing.
2.
In the Policy-based Routing page, type the name of the domain in the Domain field. See Figure 2.23: Setting Up Global Policy-based Routing Domains on page 98.
Figure 2.23: Setting Up Global Policy-based Routing Domains
3.
In the Preference field, type an integer representing the preference order in which the domain should be selected.
4.
Optionally, mark the No Outbound Security checkbox. Selecting this option will cause the Policy Engine to ignore any matching outbound security settings (such as SPN settings or Proxy Encrypt policy settings) for all policies that route messages to the given domain using Policy-based Routing.
5.
Click Add.
After a domain is added, to view which policies use the domain for policy-based routing, in its row, click Show Where Used. To edit an existing domain for policy-based routing:
98
1.
In the domain’s row, click Edit and make any changes.
2.
Click Save.
Chapter 2: Setting Up Email Firewall Administration
To remove a domain from being used in policy-based routing: 1.
Click Show Where Used to verify that the domain is not currently used as a routing action in any policy. If a policy uses this domain for policy-based routing, the domain cannot be removed. If a policy references this domain for a routing action, the policy must be either modified so that the domain is not used in the policy as a routing policy action, or the policy must be deleted. Before editing or removing a policy, view the policy and click Show Where Used to be sure that editing or deleting the policy will not have unintended effects.
1a. To modify the policy, click Edit and proceed to edit the policy,
then click Save. 1b. To remove the policy, click Policies in the main menu, then click Remove.
2.
In the domain’s row, click Remove.
Avoiding Infinite Message Looping One issue to consider when setting up policy-based routing is the interaction of policy actions when more than one Email Firewall system is in use and more than one policy action is triggered by a message. In particular, when using Redirect as a policy action while also using policy-based routing, a message could get caught in an infinite loop. The following example illustrates this scenario. Assume there are two Email Firewall machines, A and B. Assume that machine has a PBR policy which routes messages to machine B. Assume further that machine B has a Redirect policy: A
• •
If a message sent from machine A triggers the PBR policy, the message will be routed to machine B and then redirected by machine B. Machine B will send a Secure Messenger/IME receipt to back the sender.
There are two conditions that must be satisfied to create the infinite routing loop: 1.
The IME Receipt message must be routed back to machine B.
2.
The IME Receipt message must trigger the policy with PBR on machine A.
2.7 Setting Up Global Policy Settings
99
In this case, the IME Receipt message will be routed back to machine B, which causes the loop. This scenario is not limited to a Redirect policy action. An infinite loop could occur in any case where a message is sent from machine B to machine A that triggers the PBR policy on machine A. To avoid this situation, the PBR policy must be properly configured so that it will not route message from machine B back to machine B. In the case of the Redirect/PBR policies, one way to avoid this situation would be to select a policy exception condition so that the policy does not trigger when the sender is in an internal domain. Presumably, the IME/Secure Messenger Receipt message has an address in the internal domain. When the Personal Quarantine Manager (PQM) is installed and enabled, message recipients are able to see a summary of their quarantined messages and release a copy of each message they want to receive. For more information about the Personal Quarantine Manager, see 3.7 Using Personal Quarantine Manager on page 142.
2.8
Setting Up Event Logging The Event Log is the Email Firewall component that stores and displays events logged by Email Firewall. An event is any significant occurrence in Email Firewall, such as initialization of services, process failure, or defined policy events. Use the event logging options to configure how Email Firewall will record events. The Event Logging page also provides the capability of logging event logs in real time from satellite Email Firewall systems within a distributed environment to a designated centralized Email Firewall database server for consolidated reporting. All event logs from all of the satellite Email Firewall systems are consolidated into one designated database server. With Centralized Event Logging and Reporting enabled, reports can be generated using the Reports page of the central Email Firewall’s Web admin.
100
Chapter 2: Setting Up Email Firewall Administration
2.8.1
Setting Up Event Logging For detailed information on setting up the Event Log and creating Event Log filters, see Chapter 4, Working With the Event Log.
2.8.2
Setting Up Centralized Event Logging and Reporting The Centralized Event Logging and Reporting tab within the Event Logging page provides the administrator an efficient and time-saving method of monitoring event logs in real time. When the Centralized Event Logging and Reporting is enabled, an administrator administering the satellite Email Firewall systems within a distributed environment is able to view all events from the satellites and the central system. The administrator needs only to login into the central Email Firewall database server to generate reports based on all of the event logs from all of the satellite Email Firewall systems instead of having to login into each satellite Email Firewall system. Troubleshooting problems is made easier with the use of the Centralized Event Logging and Reporting feature.
Prerequisites to Enabling Centralized Event Logging and Reporting for Email Firewall Systems in a Domain This section covers the prerequisites that must be in place prior to enabling Centralized Event Logging and Reporting that are only applicable to Email Firewall systems installed within a Windows domain environment. For the prerequisites that are applicable for Email Firewall systems installed in a workgroup environment, see the section Prerequisites to Enabling Centralized Event Logging and Reporting for Email Firewall Systems in Workgroups below for more information. A prerequisite that must be in place before Centralized Event Logging and Reporting can work in a domain environment is that the Email Firewall Services on the satellite Email Firewall database servers must run under a domain account that has access to the designated central database server. Enabling Microsoft (MS) Network Distributed Transaction Coordinator (DTC) access and enabling MS DTC are other prerequisites that must be in place before enabling Centralized Event Logging and Reporting. The steps to enable MS Network DTC access and MS DTC are provided in this section. After enabling MS DTC access and MS DTC, you must restart the database server for the configuration to take effect. Once the server is restarted, proceed with enabling 2.8 Setting Up Event Logging
101
and setting up Centralized Event Logging and Reporting from the Centralized See the section Enabling and Setting Up Centralized Event Logging and Reporting below for more information on this setup.
Event Logging and Reporting tab.
To enable Network DTC Access: 1.
Starting from your Windows Desktop, go to Control Panel.
2.
Double-click Add/Remove Programs.
3.
Click Add/Remove Windows Components.
4.
Select Application Server, then click Details. Mark the Enable network DTC access checkbox. Click Next. Click Finish.
5. 6. 7.
To enable MS DTC: 1.
Starting from your Windows Desktop, click Start and then click Run.
2.
In the Run dialog box, type dcomcnfg.exe, and then click OK.
3.
In the Component Services window, expand Component Services, expand Computers, and then expand My Computer.
4.
Right-click My Computer, and then click Properties.
5.
In the My Computer Properties dialog box, select the MSDTC tab and then click Security Configuration.
6.
Within the Security Settings area of the Security Configuration dialog box, mark the Network DTC Access and Network Transactions checkboxes to select these options. The Network DTC Access option allows DTC transactions over a network and the Network Transactions option allows distributed transactions over a network.
Prerequisites to Enabling Centralized Event Logging and Reporting for Email Firewall Systems in Workgroups The prerequisites that must be in place prior to enabling Centralized Event Logging and Reporting on Email Firewall systems installed in a workgroup environment are provided in the Tumbleweed Knowledge Base article 2766, Setting Up Centralized Event Logging in a Workgroup Environment. Refer to this article for more information by going to https://kb1.tumbleweed.com. Login is required to access this article and other Knowledge Base articles. 102
Chapter 2: Setting Up Email Firewall Administration
Enabling and Setting Up Centralized Event Logging and Reporting 7.
After you have enabled MS Network DTC access and MS DTC, and performed the other prerequisite steps described in either the section Prerequisites to Enabling Centralized Event Logging and Reporting for Email Firewall Systems in a Domain above or the Tumbleweed Knowledge Base article 2766, Setting Up Centralized Event Logging in a Workgroup Environment, proceed with enabling and setting up Centralized Event Logging and Reporting on each satellite Email Firewall system from which logged events will be logged to the central Email Firewall database server. There is no need to setup and enable Centralized Event Logging and Reporting on the designated central Email Firewall system although you are required to create an Email Firewall administrator's account with Full Access capability or SuperAdmin role on the this central system. After you enable this feature on each of the satellite Email Firewall systems and restart the given system’s Email Firewall Services for the changes to take effect, events will begin to be logged to the central Email Firewall database server in real time. After restarting the machine hosting the central Email Firewall Database server, the Status page on its Web Admin initially displays the status of the services of all of the satellite machines to be down. This is the expected behavior. A given satellite’s service status changes from being down to “running” only after an event occurs on the machine that triggers a service to start and this event is communicated to the central EMF database server. For example, when a message is processed in a satellite machine, the status of the EMF Spam Analysis Engine (SAE), EMF Policy Engine, and EMF SMTP Relay (Inbound, Partition, Return, Outbound) services are updated on the central EMF database server.
Figure 2.24 shows the Centralized Event Log and Reporting tab within the Event Logging page.
2.8 Setting Up Event Logging
103
Figure 2.24: Centralized Event Log and Reporting
To set up Centralized Event Log and Reporting: 1.
On the central Email Firewall database server, create an Email Firewall administrator's account with Full Access capability or SuperAdmin role. For more information about creating an Email Firewall administrator's account with Full Access capability or SuperAdmin role, see section 2.4 Setting Up Admin Roles and Accounts on page 21.
104
2.
On the Satellite Email Firewall server, click Event Logging in the Setup page.
3.
Navigate to the Centralized Event Log and Reporting tab.
4.
Mark the Enable centralized Event Log and Reporting checkbox.
5.
In the Database Server Name field, type the name of the database server that is designated as the central database server.
6.
In the Catalog Name field, type the name of the catalog to which to save the logged events.
7.
In the User Name field, type the name of the Email Firewall account created during Step 1.
8.
In the Password field, type the password of the Email Firewall account created during Step 1.
Chapter 2: Setting Up Email Firewall Administration
After you have setup and enabled Centralized Event Logging and Reporting on a satellite server, restart this system’s Email Firewall Services for the changes to take effect.
2.9
Other Setup Tasks The remaining chapters in this book describe other areas of Email Firewall to set up, administer and monitor. The following sections describe these areas in brief detail.
2.9.1
Setting Up Message Queues Email Firewall uses message queues to hold email messages. Some queues are temporary repositories for messages in transit through the Email Firewall SMTP relay, while others provide more permanent storage for messages that must be processed manually. The queues and their functions are described in detail in Chapter 3, Working With Queues. Messages held in the configurable queues can be filtered, viewed, changed, sent, returned, reprocessed or deleted. Each queue has a configurable threshold that, when reached, can trigger a notification or log an event. The configurable Email Firewall message queues include: • • • • • • • • • •
Quarantine (Default) Detention Retry Dead Letter Defer Redirect Secure Messenger Spam Analysis Inbound Outbound
In addition to the Default Quarantine queue, custom quarantine queues can be created, allowing more granular storage of quarantined messages. There are also non-configurable queues: Partition, Return and Archive. Message count for these queues is displayed on the Status page.
2.9 Other Setup Tasks
105
What is the Personal Quarantine Manager? The Personal Quarantine Manager (PQM) eliminates the need for administrators to quickly review the Quarantine queues for potential false positives. When this feature is installed and enabled, message recipients are able to see a summary of their quarantined messages and release a copy of each message they want to receive. The message itself remains in the Quarantine queue until automatically purged by an aging action or until acted upon by an administrator. For more information about the PQM and how to set it up, see 3.7 Using Personal Quarantine Manager on page 142.
2.9.2
Setting Up Reporting The Email Firewall reporting tool creates email-usage reports that show how Email Firewall is operating in your environment. These reports are based on events logged to the Email Firewall Event Log. The reports show, in summary detail, message volume passing through Email Firewall, which policies are violated most often, which domains send and receive the highest number of messages, and which user sends the greatest number of virus-infected messages. These reports also show attachment and message volume for specific email users identified by email address, policy violations for individual senders and recipients, and viruses caught in messages from individual users. Audit reports show the actions performed in the Email Firewall Directory, and identifies the administrator who performed those actions. Chapter 11, Email Firewall Reports describes these reports and provides instructions for setting them up.
2.9.3
Setting Up Policies Policies provide the message content filtering and security measures available to Email Firewall after a message has been accepted by the Email Firewall SMTP Relay. Chapter 5, Understanding Policies explains how Email Firewall policies are structured. Chapter 6, Creating and Editing Policies provides instructions and examples for creating policies. Chapter 9, Security Configuration provides information and instructions for setting up securityrelated policies.
106
Chapter 2: Setting Up Email Firewall Administration
2.9.4
Setting Up the Directory Email Firewall policies must be applied to directory objects to be effective. A default directory structure is set up during installation. Section 5.3 Email Firewall Directory on page 220 describes this default structure and how to augment it. Tools to more effectively manage the directory are described in 10.1 Email Firewall Directory Tools on page 532 and 10.2 Setting Up LDAP Directory Imports on page 534, and sections following.
2.9.5
Setting Up Security Email Firewall can encrypt, decrypt, digitally sign, and verify incoming and outgoing messages using policies and security integration features. Chapter 8, Email Encryption and Authentication Overview describes the concepts behind the Email Firewall security features and implementation. Chapter 9, Security Configuration provides instructions for setting up Email Firewall security features.
2.9.6
What is the Dynamic Anti-spam Service? When your organization has purchased a license for the Tumbleweed Dynamic Anti-spam Service (DAS) and installed and configured the service, the Spam Analysis Engine preprocesses each message. This preprocessing, together with Email Firewall policies, allows you to reduce the number of spam messages entering your organization. The Dynamic Anti-spam Service works by processing email messages after they have been accepted by the inbound Email Firewall SMTP Relay service, but before they are processed by the Email Firewall Policy Engine. The product adds the Spam Analysis Engine service to the Email Firewall list of services. The Tumbleweed Message Protection Lab™ provides data for the Email Firewall Dynamic Anti-spam filter updates. The Spam Analysis Engine uses this filter data in message analysis. The Spam Analysis Engine uses multiple heuristics to generate a multidimensional categorization for each message processed, and applies these heuristics and statistical analyses to identify and categorize spam. The Spam Analysis Engine is extensible over time using the Dynamic Anti-spam filter updates, as new techniques and categorizations are created. This process
2.9 Other Setup Tasks
107
ensures that the system maintains a high capture rate and low false positive rate, even as spam tactics evolve. For more information about the Dynamic Anti-spam Service, see Chapter 7, Dynamic Anti-Spam Service.
2.9.7
What is Secure Redirect? When your organization has access to a Tumbleweed IME Server and installs and configures the Secure Redirect component, Email Firewall can automatically redirect selected Internet (SMTP) messages to the IME server for subsequent delivery. The IME server provides secure, traceable delivery to the recipients. In the Setup page, Secure Redirect is used when you have access to a Tumbleweed IME Server and have installed the Secure Redirect Service component. You create Redirect Profiles to use when specifying Redirect as a policy action. For detailed information about setting up and using the Redirect component and for information on creating Secure Redirect package profiles, see the Tumbleweed Secure Redirect 6.2 Administrator’s Guide.
2.9.8
What is Secure Messenger? Tumbleweed Secure Messenger is an enterprise secure email software solution. If installed, it works with the Email Firewall to inspect outbound email at the network gateway and automatically redirect messages that contain sensitive content to a secure, encrypted channel. Secure Messenger is an alternative to the Secure Redirect component. Organizations use one or the other with the Email Firewall to secure their enterprise outbound email. If Secure Messenger is installed, the Setup page displays the Secure Messenger links from which you can set up and manage Secure Messenger. For detailed information about setting up and using the Secure Messenger, see the Tumbleweed Secure Messenger 6.2 Administrator’s Guide.
108
Chapter 2: Setting Up Email Firewall Administration
2.9.9
Setting Up Proxy Servers The Setup Proxy Servers page allows you to set up and configure the Email Firewall HTTP and FTP proxy servers. See Figure 2.25. The Email Firewall HTTP proxy server is used to do the following for Email Firewall: • •
•
download Certificate Revocation Lists (CRLs). retrieve the latest Email Firewall service updates, which is a service provided by the Email Firewall Update Service. The Email Firewall Update Service link "Check for E-Mail Firewall updates" is available on the Email Firewall System Status page. allow Recurrent Pattern Detection (RPD) connectivity.
The Email Firewall Download Service uses the FTP proxy server to automatically download the latest anti-virus and anti-spam filters.
2.9 Other Setup Tasks
109
Figure 2.25: Proxy Servers
110
Chapter 2: Setting Up Email Firewall Administration
Setting up HTTP Proxy Server To set up the HTTP Proxy server to obtain the Email Firewall Update Service updates: 1.
In the Set Up > Proxy Servers page, mark the Use HTTP Proxy Server checkbox.
2.
In the Address field, enter the hostname of the HTTP proxy the Email Firewall will use.
3.
In the Port field, enter the port number of the HTTP proxy the Email Firewall will use. The default port number is 80.
4.
If required by your environment, mark the Use Authenticated Access to HTTP Proxy Server checkbox, and then enter your user name and password.
5.
Click Save to save changes.
Setting up FTP Proxy Server To set up the FTP Proxy server: 1.
In the Set Up > Proxy Servers page, mark the Use FTP Proxy Server checkbox.
2.
In the Address field, enter the hostname of the FTP proxy the Email Firewall will use.
3.
In the Port field, enter the port number of the FTP proxy server. The default port number is 80.
4.
If required by your environment, mark the Use Authenticated Access to FTP checkbox, and then enter your user name and password.
Proxy Server
5.
If required by your environment, mark the Use Passive Mode checkbox. Enabling passive mode may allow the anti-spam updates to work for Email Firewall without having to request that changes be made to the local firewall configuration. Mark this checkbox if your Email Firewall server is behind a firewall and you are having difficulty with anti-spam updates.
6.
Click Save to save changes.
2.9 Other Setup Tasks
111
112
Chapter 2: Setting Up Email Firewall Administration
3
Working With Queues
This chapter describes the features and tools used in setting up and managing the message queues. It also describes how to configure the Personal Quarantine Manager (PQM) feature that allows message recipients to access copies of their quarantined messages. This chapter contains the following sections: 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11
Message Queues Status .......................................................... 114 Setting Up Message Queues ................................................... 116 Setting Up Queue Searches .................................................... 126 Working With Messages in the Queues................................... 131 Quarantine Queue Management............................................. 133 Troubleshooting Inbound and Outbound Queues ................... 138 Using Personal Quarantine Manager .................................... 142 PQM Reports Sent to Users ................................................... 161 Using Policies with PQM ....................................................... 171 Personal Quarantine Manager Maintenance ......................... 175 Troubleshooting the PQM....................................................... 181
113
3.1
Message Queues Status The Message Queues tab on the Status page displays the number of messages currently in the Email Firewall mail queues. See Figure 3.1. The queues contain messages that are inbound to or outbound from Email Firewall, messages awaiting preprocessing by the Dynamic Anti-spam Service (if installed), awaiting redirection to a secure Tumbleweed IME server (if installed), awaiting preprocessing by the Secure Messenger (if installed), awaiting retry, and messages that were quarantined, detained, deferred, archived, returned or could not be delivered. The Partition queue contains messages that require delivery to multiple recipients. Figure 3.1: Email Firewall System Status Message Queues Tab
Queues listed under the Processing Queues heading contain messages that are in transit through Email Firewall. Queues listed under the Static Queues heading contain messages that Email Firewall has finished processing. Messages in the static queues will remain there until acted on by an administrator or are 114
Chapter 3: Working With Queues
automatically deleted by a queue aging action. For more information about managing messages in the queues, see 3.5 Quarantine Queue Management on page 133. For more information about queue aging actions, see 3.2.3 Setting Up Queue Aging on page 122. Email Firewall is an active system and the number listed beside each queue shows the number of messages in the queue when the page was last accessed. The current message count may differ from the number displayed. Click Refresh to update the page to show the most current message count. Click the underlined queue name link to access that queue’s main page and view the messages in that queue. Although messages in the Return, Archive and Partition queues are not accessible, it is useful to occasionally note the number of messages in those queues. An excessive number of messages in those queues could indicate a processing problem that should be investigated. If you notice an unusually large number of messages in the Quarantine queues, see 3.5.3 Checking the Quarantine Queue for Inbound Messages on page 135 for troubleshooting information. Set queue thresholds to send a notification when the size of a Quarantine or Dead Letter queue exceeds a certain limit, since a large number of messages in these queues often indicates a denial of service attack or a serious problem with the system.
Email Firewall services regularly poll the database for messages to work on. If there are no messages to work on, the polling process sleeps. This can lead to latency in transferring a single message, but when messages are arriving regularly, as is the case in most organizations, the process does not go to sleep. For more detailed information on the queues, including how to set them up, see 3.2 Setting Up Message Queues on page 116 and the Email Firewall Help. For a summary description of each queue, see Table 3.1 on page 116.
3.1 Message Queues Status
115
3.2
Setting Up Message Queues Email Firewall uses message queues to hold stored email messages. Some queues are temporary repositories for messages in transit through the Email Firewall SMTP relay, while others provide more permanent storage for messages that must be processed manually. The queues and their functions are listed in Table 3.1. Messages in the accessible queues can be filtered, viewed, changed, released, returned, reprocessed or deleted. (Not all queues allow all actions.) Each queue has a configurable threshold that, when reached, can trigger a notification or log an event. See 3.2.2 Setting Up Queue Actions on page 120. The configurable and accessible Email Firewall message queues include: • • • • • •
Inbound
• • •
Redirect Secure Messenger Dead Letter
•
Quarantine (Default
Outbound Spam Analysis Detention Retry Defer
and any custom queues)
There are also non-accessible queues: Return, Archive and Partition. Message count for these queues is displayed on the Status page. Table 3.1: The Email Firewall Message Queues Queue Name
Queue Description
Quarantine
The Quarantine queues contain messages that triggered a policy that checks for spam messages, potentially harmful messages, or nonsecure messages. These messages are set aside for the mail administrator to examine. For example, the default Virus scanning policies detect and quarantine all infected messages. Messages in this queue remain here until released or otherwise acted upon by an administrator, or until expired. The length of time messages remain here is defined in the Set Up > Quarantine Queue Configuration Aging tab. The Quarantine queue contains a Default queue that cannot be deleted, and up to ten quarantine custom queues can be created.
116
Chapter 3: Working With Queues
Table 3.1: The Email Firewall Message Queues Queue Name
Queue Description
Detention
The Detention queue contains messages that triggered a policy requiring administrative review prior to delivery. Messages are detained here temporarily, until the detention period (a configurable period) expires, or an administrator takes some other action first.
Retry
The Retry queue contains messages that the SMTP Relay cannot deliver immediately. Messages are stored in this queue while Email Firewall attempts to deliver them according to the retry interval. The retry interval and message expiration are specified in the Set Up > Retry Queue Configuration Retry tab.
Dead Letter
The Dead Letter queue contains messages that Email Firewall cannot deliver to its intended recipient and cannot return to the sender. For example, messages that the SMTP Relay receives that it has already attempted to return to the sender would be placed in this queue. The length of time messages remain here is defined in the Set Up > Dead Letter Queue Configuration Aging tab.
Defer
The Defer queue contains messages that are set aside until off-peak hours. For example, the default Inbound Size Deferral policy detects messages larger than 10MB and defers delivery until after peak time. Peak time is configured in the Set Up > Policies Peak Time tab.
Redirect
The Redirect queue contains messages that will be redirected to a secure Tumbleweed IME server, if this server is installed to process. These messages have triggered a policy that uses the Redirect delivery action. If you have not installed the Redirect component but have created a policy that uses the Redirect delivery action, messages sent to this queue will remain here unless manually removed by the administrator. Also, a message that is subject to both a defer action and a redirect action will be placed in the Redirect queue, and not the Defer queue, to wait during peak time.
Secure Messenger
The Secure Messenger queue contains messages that will be redirected to Secure Messenger, if this software is installed run with Email Firewall. These messages have triggered a policy that encrypts and delivers the message via Secure Messenger. If you have not installed the Secure Messenger component but have created a policy that uses the Redirect delivery action, messages sent to this queue will remain here unless manually removed by the administrator. Also, a message that is subject to both a defer action and a redirect action will be placed in the Secure Messenger queue, and not the Defer queue, to wait during peak time.
3.2 Setting Up Message Queues
117
Table 3.1: The Email Firewall Message Queues Queue Name
Queue Description
Spam Analysis
When the Dynamic Anti-spam Service (DAS) is installed, messages from both internal and external hosts that have been accepted by the SMTP Relay service are placed in this queue. These messages will be processed and tagged by the Spam Analysis Engine and then sent to the Inbound queue. For information about the Dynamic Anti-spam Service, see Chapter 7, Dynamic Anti-Spam Service.
Inbound
The Inbound queue contains messages that will be routed to the Email Firewall Policy Engine for processing. If the Dynamic Anti-spam Service is installed, messages arrive here after processing by the Spam Analysis Engine. If the Dynamic Anti-spam Service is not installed, messages from both internal and external hosts that have been accepted by the SMTP Relay service are placed in this queue. (Messages bypass the Spam Analysis queue if the Dynamic Anti-spam Service is not installed.)
Outbound
The Outbound queue contains messages from internal hosts that have been routed through the Email Firewall Policy Engine and are in the SMTP relay awaiting delivery to the next destination.
Return
Messages are placed in the Return queue by the Relay when it sends a Delay DSN to the sender. The Redirect service also places messages in the Return queue on failed redirect attempts. The Relay picks up messages from this queue and re-sends them.
Archive
The Archive Queue contains messages placed there by policies with a policy action to archive. The queue is read and processed by the Archive Service.
Partition
The Partition queue contains messages waiting to be copied and sent to different recipients to whom different outbound routing rules apply. The relay’s Partition function examines the recipient list and splits up the message as necessary based on the routing rule that needs to be applied for each recipient. If different recipients require different routing rules, then multiple partitions of the message are created and each partition is placed in the Outbound queue separately. Recipients for whom the same routing rule applies are kept together on the same partition of the message.
118
Chapter 3: Working With Queues
3.2.1
Queue Configuration Each queue is configured individually. There are two ways to access the queue configuration pages: •
•
In the left menu, click Queues. In the Queues page, Action tab, Setup Queue heading, use the drop-down list to select a queue and click Setup to access the queue’s configuration page. For the Quarantine queue, custom quarantine queues can also be created. Once created, their setup pages can also be accessed here. In the left menu, click Set Up to open the Set Up page. Under the Queues heading, click a queue name to open its configuration page.
Configurable settings for each queue appear on the Actions and Reset tabs. Queue Actions include: • • •
Specify the threshold number of messages required to trigger an action. Send a notification when the threshold is reached. Log an event when the threshold is reached.
See 3.2.2 Setting Up Queue Actions on page 120 for instructions. For the Inbound queue, you can also specify the following action: •
•
Stop the SMTP relay from accepting incoming messages. This is normally used only when there is a message backlog, or for troubleshooting. See 3.5.4 Stopping Inbound Message Acceptance on page 136. If the Dynamic Anti-spam Service is installed (whether enabled or disabled), rather than using the option in the Inbound queue, specify the Stop the SMTP relay from accepting incoming messages in the Spam Analysis queue setup.
The Reset tab feature allows the queue actions to be automatically reset when the queue shrinks to or falls below a configurable number of messages. See Resetting Queue Actions on page 121. In addition to the Actions and Reset tabs: •
the Quarantine and Dead Letter queues have an Aging tab for configuring how long to hold messages in the queue before they expire and are automatically deleted. Optionally, audit events can be logged when messages are deleted. See 3.2.3 Setting Up Queue Aging on page 122. Any Quarantine custom queues created also have this aging action option.
3.2 Setting Up Message Queues
119
•
The Retry queue has a Retry tab where messages that were not able to be sent on the first try are attempted to be sent again, at the intervals defined in this tab. See 3.2.4 Setting Retry Queue Retry Intervals on page 123.
See Chapter 6, Creating and Editing Policies for more information on using policy actions that send messages to the queues.
3.2.2
Setting Up Queue Actions Figure 3.2 shows the actions common to all configurable queues. Figure 3.2: Queue Configuration Actions
To set up queue actions: 1.
Access the selected Queue > Configuration page.
2.
On the queue Actions tab, type the threshold number of messages required to trigger an action.
3.
Mark the Send a notification checkbox if you want a notification to be sent when the queue grows to or exceeds the specified number of messages. If you marked the Send a Notification checkbox: 3a. Click Select Notification to open the Create Notification Message
page. 3b. Mark the Send To radio button to specify the recipient of the
notification.
120
Chapter 3: Working With Queues
3c. Type the notification Subject and Message. 3d. Click Update. 4.
Mark the Log an Event checkbox if you want Email Firewall to log an event when the queue grows to or exceeds the specified number of messages. If you marked the Log an Event checkbox: 4a. Click Select Log Event to open the Select Event to Log page. 4b. Mark an Event ID radio button and click Select Event.
Or, create a new Event ID. See 6.5 Using Events as Policy Actions on page 295 for information and instructions. Then select it. 5.
Click Save.
After the queue actions are performed, they can not be performed again until they are reset. Queue actions can be reset automatically or manually.
Resetting Queue Actions Queue actions must be reset after they have reached the threshold number of messages and performed any triggered actions. To reset Queue Actions automatically:
In the Setup > Specific Queue Configuration page Reset tab: 1.
Mark the Automatically reset the actions when the queue shrinks to or falls below X messages checkbox.
2.
Type in the threshold value for X in the field provided.
3.
Click Save.
To reset Queue Actions manually:
In the Setup > Specific Queue Configuration page Reset tab, click Reset Actions to manually reset the actions.
Now
3.2 Setting Up Message Queues
121
3.2.3
Setting Up Queue Aging The Quarantine and Dead Letter queues have an aging action in addition to notification and event log actions. As explained in 3.2 Setting Up Message Queues on page 116, a message is placed in the Quarantine queue when required by a policy action, and is stored in this queue for a configurable period of time while awaiting administrator review and action. A message is placed in the Dead Letter queue when Email Firewall cannot deliver it to the intended recipient and cannot return it to the sender. As with the Quarantine queue, the message is stored in this queue for a configurable period of time while awaiting administrator review and action. If the administrator takes no action on the messages in the queue during the specified period, the options selected on the Aging tab determine what Email Firewall should do with the message. options are specified in hours, days, weeks or months. You can specify whether an audit event should be logged when each message is deleted. Not requiring an audit event will improve queue aging performance. Figure 3.3 shows the configurable settings on the queue Aging tab.
Aging
Figure 3.3: Queue Setup Aging
To set up Quarantine and Dead Letter queue aging actions:
122
1.
Navigate to the appropriate Queue > Configuration page.
2.
On the Aging tab, mark the checkbox beside Delete and type a number and use the drop-down list to select hours, days, weeks or months that a message must be in the queue to trigger an action.
Chapter 3: Working With Queues
3.
Optionally, mark the Log an audit event for each deleted message checkbox if you want to log the event. Enabling this option will negatively impact the Queue Aging performance. When a message is put in the Quarantine queue, the Event associated with this action adds the date the message is scheduled to be removed from the Quarantine queue. With this information, you might not need the audit event for each deleted message as well.
4.
3.2.4
Click Save.
Setting Retry Queue Retry Intervals Messages are placed in the Retry queue when they cannot be delivered immediately. Such occasions may arise, for example, when the destination mail server is busy and not accepting new connections. They may also occur when a transient internal error interferes with message processing. Messages are stored in the Retry queue while Email Firewall attempts to deliver them according to the retry interval specified on the Retry Queue > Configuration Retry tab.
3.2 Setting Up Message Queues
123
The Retry queue has a retry action in addition to notification and event log actions. It also has an option that allows Email Firewall to notify the sender that the message has been delayed. Figure 3.4 shows the configurable parameters. Figure 3.4: Retry Queue Retry Parameters
To set up Retry queue retry parameters:
124
1.
Navigate to the Setup > Retry Queue Configuration page.
2.
On the Retry tab, specify the first retry interval: type a number and use the drop-down list to specify minutes, hours or days that a message must be in the queue before Email Firewall attempts to resend it after the first unsuccessful attempt to deliver the message.
3.
Specify the maximum wait time between retry attempts after each unsuccessful attempt to deliver the message. Email Firewall will double the wait time after each unsuccessful attempt until the maximum wait time is reached.
4.
Mark the checkbox if you want the sender to be notified that the message has been delayed, and specify when the sender should be notified. The notification will be sent following the first failed delivery attempt after the delay notification time period has passed.
5.
Specify the maximum period of time a message is allowed to stay in the retry queue.
6.
Click Save.
Chapter 3: Working With Queues
3.2.5
Creating Quarantine Custom Queues The Default Quarantine queue is installed by default and cannot be deleted or renamed. However, additional Quarantine custom queues can be created. This is useful because the number of messages in the Default Quarantine queue can become quite large. To assist with quarantined message review, up to ten custom Quarantine queues can be created to store quarantined messages more granularly. When creating Quarantine custom queues, keep in mind the following: • •
•
A custom queue name is limited to 30 characters. A custom queue cannot be deleted if the queue is still referenced by a policy. If an attempt to delete an in-use custom queue is made, an error message is displayed with the list of policies using the queue. A custom queue that is deleted will have all of its messages moved to the Default queue.
After the new custom queues are created, a policy using the Quarantine action can specify into which Quarantine custom queue messages meeting the policy catch conditions should be placed. To create a Quarantine custom queue: 1.
In the main menu, click Set Up.
2.
Under the Queues heading, click Quarantine.
3.
In the Queue Name field, type a name for the queue. The name should be logically related to the type of messages expected to be placed in the queue. For example, if you plan to quarantine messages tagged with a spam high confidence rating, you could name the queue Spam High Confidence.
4.
Click Create.
5.
In the new queue’s row, click Set Up.
6.
Complete the options on the Aging, Actions and Reset tabs. For more specific instructions on completing these options, see: • 3.2.2 Setting Up Queue Actions on page 120 • 3.2.3 Setting Up Queue Aging on page 122 • Resetting Queue Actions on page 121
7.
Click Save.
3.2 Setting Up Message Queues
125
3.3
Setting Up Queue Searches On the Queues main page, Queue Search is the link to the page that allows you to search any of the queues. You do not need to save a search in order to execute a search in the queues. However, if you search queues often for the same type of messages and message properties, saved queue searches can both simplify and speed up the search process. On the Queues main page, Saved Searches is the link to manage (create, update, delete) all the saved queue searches. The number of messages in the queues can become quite large. Saved queue searches help you sort and organize messages so that you can view only a subset of all messages. To search a queue, queue search parameters must first be created. Then, the search is used to search the specified queue for only those messages matching the search specifications. Queue searches can be created and used on-the-fly, or can be created and then saved for reuse. On the Queues main page: • • • •
3.3.1
opens the page where searches are configured and can be used on-the-fly or saved for reuse. Saved Searches shows the list of saved searches that can be reused. View Queue selections allow you to specify the queue(s) to search, and allow you to apply saved queue searches immediately. Setup Queue selections provides a quick link to the individual queues setup pages. Queue Search
Limitation on Queue Search Results For performance reasons, the number of messages that will be returned by a search is limited to 100,000. This limit can be modified by changing the variable Max Queue Display Size in the GlobalConfigValues table. Use Setup > Configuration Editor to access this table and variable. You must enter a positive Integer value. If the Integer value is set to 0, Email Firewall will default to 100,000. If there are more than 100,000 messages in a single queue, the proper counts are displayed in the queue counts but only 100,000 may be accessed at one time, unless this limit is changed using the Configuration Editor. After the result is returned by the search, Email Firewall considers the result (100,000) as final. This means that if you delete 1,000 messages, the new number of messages will
126
Chapter 3: Working With Queues
be 99,000. Changing the sorting order or re-running any kind of search will force a new search to be executed in the database and the new result set will return to 100,000 (or the value of “Max Queue Display Size” if it has been changed). See 10.11 Using the Configuration Editor on page 609 for instructions on using the Configuration Editor.
3.3.2
Creating a Queue Search Queues searches can be set up to filter for messages identified by the following: • • • • • • • • • •
When Received Message Subject Sender Recipient Message ID Tags applied Released from quarantine by one or more recipients Requested to be white listed Sent to a specified number of recipients Message Size (including attachments)
To create a new queue search: 1.
In the left menu, click Queues to open the main Queues page.
2.
In the Queues page, click Queue Search to open the queues search page.
3.
Beside the Search for messages in heading, use the drop-down list to select the queue(s) to search. The filter will apply to messages that meet all of the filter specifications. (To select an existing filter, use the Filter drop-down list to select it, then click Search).
4.
Select the search Date and Time parameters: • with no time restrictions • within the last specified minutes, hours, or days • between two specified dates
5.
Optionally, select the Message Properties Subject: 5a. Use the drop-down list to select begins with, contains the exact phrase, contains the words, or contains any words in the list. If you
3.3 Setting Up Queue Searches
127
select the option contains the words the filter will search for all of the words, and not for any of the words. Unlike when lists are used in Policy Engine processing, in queue filtering there is no regular expression processing or wild card expansion. All list entries are handled as a word/phrase to be matched exactly within the subject or address. However, the search is case insensitive. 5b. If you did not select a list, in the text field, type the search words. 5c. If you did select a list, click Select word list to open the Select
Word Lists pop-up page and either create a new word list, or select an existing list. For more information on creating word lists, see 6.2.2 Word Lists on page 258. 6.
Optionally, specify the Message Properties Sender to filter for messages sent by specified senders: 6a. Use one of the drop-down lists to select inclusively is any of the following or is any on the list, or to select exclusively is none of the following or is not on the list.
6b. If you did not select a list, in the text field, type the search words. 6c. If you did select a list, click Select address list to open the Select
Address Lists pop-up page and either create a new address list, or select an existing list. See 6.2.6 Address Lists on page 265 for more information on creating address lists. 7.
Optionally, specify the Message Properties Recipient: 7a. Use one of the drop-down lists to select inclusively is any of the following or is any on the list, or to select exclusively is none of the following or is not on the list.
7b. If you did not select a list, in the text field, type the search words. 7c. If you did select a list, click Select address list to open the Select
Address Lists pop-up page and either create a new address list, or select an existing list. See 6.2.6 Address Lists on page 265 for more information on creating address lists.
128
8.
Optionally, specify the Message Properties Message ID to filter for a specific message identified by message ID and enter the message ID in the field.
9.
Optionally, in the Tags section, use the Message includes drop-down list to search inclusively for any or all messages marked with specified tags. Use the does not include drop down list to exclude messages that are marked with specified tags.
Chapter 3: Working With Queues
9a. Click Select to open the Select tags pop-up page. 9b. Select one or more existing tags, or create a new tag. See 6.2.12
Creating a New Tag Example on page 275 for more information on creating tags. 10. Optionally, search with Advanced Options: 10a. If the Personal Quarantine Manager is installed and enabled, mark
the Message released from quarantine... checkbox. This allows tracking of messages quarantined but released by the intended recipients). For additional information about the personal Quarantine manager, see 3.7 Using Personal Quarantine Manager on page 142. 10b.If the Personal Quarantine Manager is installed and enabled, mark the Message released for white listing ... checkbox. This allows you to view all the messages requested for white-listing and take action on those messages (e.g., add sender to list). 10c. Mark the Message Sent to checkbox and use the drop-down list to select more than, less than, or between and enter the number of recipients in the field(s). 10d.Mark the Message size is (including attachments) checkbox and use the drop-down list to select larger than, smaller than or in the range and enter the numeric value in the corresponding field (use the drop-down list to specify MB or KB).This option allows filtering for messages above, below or within the range of the specified size threshold. 11. Optionally, in the Save search as field, type a name for the saved search.
The name should be logically related to the search action you want to perform. 12. Beside the for use by Queue heading, leave the default to allow the saved
search to be used by with any queue search, or use the drop-down list to select which queue(s) the search may be used against. 13. To be able to reuse the search at a later time, click Save. 13a. In the Queue Search page Saved Search drop-down list, verify the
new search appears in the list. 14. To use the search on-the-fly but not save it, click Search.
3.3 Setting Up Queue Searches
129
3.3.3
Modifying Queue Searches Once you have created a queue search, you can fine-tune it as needed. To modify a queue search:
3.3.4
1.
In the left menu, click Queues to open the Queues main page.
2.
In the Queues main page, click Saved Searches to open the Saved Searches page.
3.
In the Saved Search column, Saved Search Name row, click Edit.
4.
In the Saved Searches > Edit Search page, make any changes and click Save. See 3.3.2 Creating a Queue Search on page 127 for information about the available options.
5.
In the Saved Searches page, verify the edited search appears in the list.
SQL Jobs and Deleting Messages in Queue Filters Two “trash queues” are provided to improve response time when using Web Admin to delete all messages in a queue filter. These queues are similar to the other queues but they are not exposed in the UI. One trash queue is for messages in the Processing queues and the other is for messages in the Static queues. Deleted messages in the Processing queues are moved to the Dynamic Trash queue. Deleted messages in the Static queues are moved to the Static Trash queue. The presence of these queues greatly reduces the time needed for multiple message delete, especially when there is a large number of messages in a filter. A batch file is used to physically delete the filtered messages from the regular queue and move them to a trash queue; when all messages are removed, an audit event about the deleted messages is logged. Once every hour a SQL job called “Trash Queues Cleanup” is automatically run. This job physically removes the messages properties from the database. A deleted message can remain in the database for up to an hour until being physically deleted by the SQL job. If an administrator is deleting messages using Web Admin in order to free up disk space on the system, this SQL job must be executed after manually deleting the messages in order to reclaim the space. Queue aging is not affected by this feature. Messages deleted by queue aging are not moved to the trash queues.
130
Chapter 3: Working With Queues
Administrators should monitor the SQL Trash Queues Cleanup job, to make sure that the job is running regularly.
3.4
Working With Messages in the Queues There are two ways to access and view a queue and the messages in the queue. In the left menu: • •
Click Status to open the Status page. In the Message Queues tab, click the underlined queue name link to access the queue. Click Queues to open the Queues page. In the Queue Counts tab, click the underlined queue name link to access the queue.
The messages in each queue can be manipulated in a variety of ways. In the queue’s main page you can: •
• • • • • • • • •
View the Subject, Sender, Recipients, Date of each message in the queue. In the Quarantine and Detention queues, you can also view the Tag applied. In the Outbound and Retry queues, view the Target Domain. Sort all the messages in the queue by subject, sender or date. Filter the messages in the queue to show only those you are interested in viewing, to further refine your view of the messages in the queue. Delete individual messages or all the messages in the current filter. Advanced Delete multiple messages by Subject or by Sender. Depending on the queue, Delete, Release, Return or Reprocess some or all of the messages in the queue or in the filtered queue. Add selected senders to a white list or black list. Save the message list to an external file. Use All to select or deselect all the messages displayed on that page. View any individual message in the queue by clicking the subject link.
3.4 Working With Messages in the Queues
131
3.4.1
Deleting Multiple Messages From the Queues The advanced delete options in the drop-down lists at the top and bottom of each queue allows bulk deletion of messages with the same senders or subjects. This allows rapid clearing of the queues. To access the Advanced Delete functions, use the drop-down list to select to delete messages with exactly the same sender or subject. Messages can also be acted on in bulk by using the Delete, Release, Return, and Reprocess options in the drop-down list at the top and bottom of each queue. Make the selection for the intended action, select the messages in filter option in the adjacent drop-down list, and click the adjacent button. To avoid unintended actions, the button changes name based on the action specified.
3.4.2
Viewing Individual Messages in the Queues While viewing a queue, you can open any message in the queue by clicking its link in the Subject column. For any individual message in a queue, you can: •
View the message and headers by the following View Options: • Standard • Expanded • MIME format
• •
Review the Explanation for why the message is in the queue. Perform the following actions (not all options are available in all queues): • View message events triggered by the message. • Add sender to list. • Edit SMTP Recipients of the message. • Save the message to a file. • Forward a copy to the Message Protection Lab as inaccurate Spam categorization when releasing message (when DAS is installed). • Delete the message. • Release the message to the Recipients. • Return the message to the sender. • Reprocess the message through the Policy Engine.
The tabs on the queue message page provide additional information and options: • 132
The Message Text tab shows the message content.
Chapter 3: Working With Queues
•
3.5
The Attached Files tab shows any files attached to the message, including the file name, type and size. You can also: • Open, Save or Delete attached files. • Add an Annotation to the message.
Quarantine Queue Management The Quarantine queue contains messages that triggered a policy that checks for potentially harmful or nonsecure messages, and messages in this queue remain here until released or otherwise acted upon by an administrator or are automatically expired. When the Personal Quarantine Manager is installed and enabled, recipients can opt to have a copy of a quarantined message sent to them, but the original message remains in the Quarantine queue. This queue can become very large. The most important recommendations for making queue management easier is to use quarantine tags effectively, and to create Quarantine custom queues in which to store these messages based on the tags used. This means that policies should be configured to tag messages in a way that makes the job of the queue reviewer as simple as possible. For example, if customized weighted word lists are being used for spam, quarantine tags could be set up that reflect the confidence level and the presence or absence of adult content. This will allow queue filters to be easily built that will show, for example, only the high confidence spam messages that also had adult content. A quarantine custom queue that is created to hold all these messages can be used to further refine message review. If the Personal Quarantine Manager is installed and enabled for recipient whitelisting requests, then consider creating a Saved Search showing only messages requested for white listing. See 3.8.4 User Requests for “White List” on page 168. For additional information about managing spam messages, see 3.7 Using Personal Quarantine Manager on page 142 and Chapter 7, Dynamic AntiSpam Service.
3.5 Quarantine Queue Management
133
3.5.1
Setting Up a Model Spam Review Process Some Email Firewall administrators have successfully used the following general approach to reviewing spam candidates. To set up an effective spam review process: 1.
To begin with, create Quarantine custom queues to sort messages by quarantine tag type.
2.
Create queue filters to reduce the quarantine queues to the set of messages that have various combinations of the spam-related quarantine tags. See 3.3 Setting Up Queue Searches on page 126 for instructions on creating filters. The review process starts by selecting the quarantine queue and quarantine filter that results in the set of messages that are most likely to be false positives.
3.5.2
3.
Apply the filter. Sort the result set by time so that you are viewing the oldest messages first.
4.
Release the messages that are false positive and delete the remaining spam messages in the filter.
5.
Select the next queue filter most likely to contain false positives.
6.
Repeat the process until you have used all of your spam-related queue filters.
Additional Queue Management Tips Use Bulk Actions on Messages Filtered messages with the same sender or subject can be deleted in bulk from the queue. See 3.4.1 Deleting Multiple Messages From the Queues on page 132. Selected messages can also be identified by marking the checkbox beside the message and then using the options to Delete, Release, Return or Reprocess all the selected messages, or all the messages in the filter.
134
Chapter 3: Working With Queues
Use Quarantine Queue Threshold Actions Email Firewall can be configured to log an event or send an email notification when the quarantine queue reaches a certain size. See 3.2.2 Setting Up Queue Actions on page 120. It may be helpful to enable this feature so the queue reviewers are notified when there are a large number of messages needing review.
Use Quarantine Queue Aging It is recommended that you enable queue aging to automatically delete messages that have been in the quarantine queue for a specified period of time. See 3.2.3 Setting Up Queue Aging on page 122 for instructions. Select a time limit that you are comfortable with and which takes into account holiday periods when there may be no regular queue reviews.
Create Quarantine Queue Custom Queues Setting up additional Quarantine queues allows you to place messages into the custom queues based on the policy the message triggered or the tag applied to the message. This allows for more efficient screening of quarantined messages.
3.5.3
Checking the Quarantine Queue for Inbound Messages If there is a problem with the database server that causes an internal processing error, or in a cluster environment during a failover, inbound messages and messages being processed by the Policy Engine may be diverted to the Quarantine queue. This diversion does not occur immediately; the Policy Engine will return messages to the Inbound queue following an internal error. This allows the same (or another) Policy Engine service to attempt to process the message again, in case the initial error was transient in nature. If the same message is processed by a Policy Engine service for the third time, then the message is automatically moved to the Quarantine queue. Messages automatically diverted to the Quarantine queue due to these internal errors are identifiable by the tag Internal Error. This message diversion can occur until the open connections to the nonresponding database are refreshed and the Policy Engine is informed that the connection to the database has been lost.
3.5 Quarantine Queue Management
135
While no messages are lost due to this event, the administrator should review the Quarantine queue to determine whether any inbound messages were diverted while the database was unavailable. The Event Log information can also help to determine whether this occurred, and indicate the time period that should be reviewed. When this expected behavior occurs, the administrator must manually release the messages from the Quarantine queue. The messages can be released back to the Policy Engine, or directly to the recipient. For information on how releasing messages affects reporting statistics, see 11.1 Setting Up Email Firewall Reports on page 612.
3.5.4
Stopping Inbound Message Acceptance The normal method of stopping inbound message acceptance is in the Relay Setup, described in Stopping Inbound or Outbound Mail on page 34. There is another method of stopping inbound mail when the Inbound queue or Spam Analysis queue reaches a configurable limit. This option is located in the Setup > Inbound Queue Configuration and Set Up > Spam Analysis Queue Configuration page. When the Dynamic Anti-spam Service is installed, the Spam Analysis queue setup option should be used. The task checking the number of messages in the Inbound/Spam Analysis queue checks every 60 seconds. It is possible that the number of messages set for the stop action may be exceeded before the stop action occurs, if more than that number of messages enters the Inbound queue during the 60 seconds between checks. Because this option stops messages from being received by Email Firewall, this option is normally used only when there is a message backlog or for troubleshooting. To stop inbound message acceptance:
136
1.
In the left menu, click Setup.
2.
In the Setup page, Queues heading, click Inbound (or Spam Analysis if the Dynamic Anti-spam Service is installed).
3.
In the Set up > Queue Configuration page, Actions tab, enter a low number of messages in the When the queue grows to or exceeds field and mark the Stop the SMTP relay from accepting incoming messages checkbox.
Chapter 3: Working With Queues
4.
Optionally, mark the checkbox to Send a notification to alert you that the threshold has been reached and message acceptance has been stopped.
5.
Optionally, mark the checkbox to Log an Event to alert you that the threshold has been reached and message acceptance has been stopped
6.
Click Save.
To re-enable inbound message acceptance:
3.5.5
1.
In the Set up > Inbound/Spam Analysis Queue Configuration page, Actions tab, enter a higher number of messages in the When the queue grows to or exceeds field and unmark the Stop the SMTP relay from accepting incoming messages checkbox.
2.
Click Save.
3.
In the Reset tab, click Reset Actions Now if the actions need to be reset.
4.
Click Save.
Getting Rid of Undeliverable Bounced Messages One headache caused by the spam problem is due to spam messages being sent from an invalid sender to invalid addresses in your internal domains. The SMTP email system generates a delivery status notification (DSN) for such messages indicating that the message could not be delivered. The recipient of the DSN is the sender of the spam message. Because the sender may not be a valid address, these DSN messages may consume Email Firewall SMTP Relay time and take up resources in the Outbound, Retry, or Dead Letter queues. The recommended best practice for this situation is to maintain a list of invalid domains that appear to include recipient addresses on the DSN messages that you find in the Dead Letter queue. You can then use the Email Firewall Policy Engine to drop messages sent to those addresses. For example, you could create a subfolder in the External folder and call it Within this folder, you should create a user record or domain record for each undeliverable address or domain that seems to be used on undeliverable spam messages. Undeliverable.
Apply to the Undeliverable folder a recipient-based policy that will drop all messages sent that user. Alternatively, if you don't want to drop all mail sent to users or domain in the Undeliverable folder, you could create the policy so that the mail is only dropped if it appears to be a delivery status notification (i.e., check for an attachment whose MIME type is message/delivery-status.)
3.5 Quarantine Queue Management
137
The Email Firewall Policy Engine does not use the message/deliverystatus MIME type in the notifications that are generated when a policy takes the return-to-sender action. Two ways to identify policy-generated return notifications are to match the Email Firewall notifier as the sender address and to look for the phrase “this message could not be delivered to the following recipients” in the body of the message.
3.6
Troubleshooting Inbound and Outbound Queues Stopping the SMTP Relay From Accepting More Messages The SMTP Relay has an option that allows you to stop the relay from accepting inbound messages. See Stopping Inbound or Outbound Mail on page 34. The Inbound queue also has a setup option that allows you to stop the SMTP Relay from accepting incoming message when the message count reaches a specified threshold. See 3.5.4 Stopping Inbound Message Acceptance on page 136. The Spam Analysis queue also has a setup option that allows you to stop the SMTP Relay from accepting incoming message when the message count reaches a specified threshold. When the Dynamic Anti-spam Service is installed, the Spam Analysis queue setup option is the one that should be used to stop inbound messages. Stopping inbound messages can be useful for troubleshooting or when performing maintenance on your SMTP server.
138
Chapter 3: Working With Queues
3.6.1
Troubleshooting Inbound Queue Backups -- Full File Groups Full SQL Server file groups can cause the Policy Engine to stop processing messages from the queues. The Policy Engine service checks for available space in the following file groups configured for the Email Firewall database. These file groups are: MMSBodyChunk MMSBodyChunkStatic MMSEventData MMSMessageData MMSMessageDataStatic MMSMessageDataPropertiesStatic MMSTransactionLog
If the Policy Engine service detects that the used space of any of these file groups is greater than 90%, the Policy Engine service will temporarily stop processing messages from any of the message queues until the used space goes below 85%. A warning will be logged with the list of file groups and the percentage of space used. This problem can be solved by increasing the file size of the file group. Before doing so, you need to determine which file group size needs to be increased. You can use SQL Server Enterprise Manager to find which file group size needs to be increased. To determine the file group size that needs to be increased: 1.
Launch SQL Server Enterprise Manager.
2.
Expand the Microsoft SQL Server branch.
3.
Expand the SQL Server Group branch.
4.
Expand the Server name.
5.
Expand the Database branch.
6.
Click the EMFMail database (or the database you used for Email Firewall if you changed the default name).
7.
Right click the EMFMail database and select View > Taskpad. (Do this step only if you are using SQL Server 2000.)
8.
Go to the Space Allocated section.
3.6 Troubleshooting Inbound and Outbound Queues
139
9.
Inspect the file groups: MMSBodyChunk MMSBodyChunkStatic MMSEventData MMSMessageData MMSMessageDataStatic MMSMessageDataPropertiesStatic MMSTransactionLog
and determine which one is close to full. To increase the size of the file group: 1.
Stop the Inbound SMTP Relay service so that no messages will be accepted. This will avoid having the filegroup fill up again immediately.
2.
Right-click the EMFMail database and select Properties.
3.
In the EMFMail Properties dialog (assuming the database name is EMFMail), select the file group that needs to be increased.
4.
Select the Data Files tab to open the dialog on which the file group space can be modified.
5.
Increase the size specified in the Space allocated (MB) field. For example, if the number was 2000MB, change it to 2500MB or more.
6.
Click OK when done. The Policy Engine service will now process the messages from the Inbound queue.
140
7.
Go to the Email Firewall Web Administration System Status page to check the status of the message queues.
8.
When the number shown in the Inbound queue gets low, re-start the Inbound Email Firewall SMTP Relay service.
Chapter 3: Working With Queues
3.6.2
Troubleshooting Outbound Queue Backups When messages are stuck in the Outbound queue and the Email Firewall SMTP Relay service is running, the backup is often the result of an external influence. This can happen, for example, when an internal email user sends an exceptionally large message to a large number of external addresses. In one case in which this problem was seen, a >3MB message was sent to over 200 external addresses. Because of a network configuration, only 254 KBPS was allowed for outgoing SMTP messages. In this situation, Email Firewall was using every available socket connection and hanging them up while trying to send the mail, because of the bandwidth throttle. The result was no apparent mail flow and a large buildup of messages in the Outbound queue. One way to determine whether messages are actually moving out of the Outbound queue is to use Network Monitor to see whether messages are in fact leaving the Outbound queue. With Network Monitor, you can see when messages are just trickling out. When messages are moving very slowly, initial investigation would be to ask what stands between Email Firewall and the Internet, and start looking at bandwidth.
3.6 Troubleshooting Inbound and Outbound Queues
141
3.7
Using Personal Quarantine Manager The Personal Quarantine Manager (PQM) eliminates the need for administrators to quickly review the Quarantine queues for potential false positives. Using this feature recipients are able to see a summary of their quarantined messages and release a copy of each message they want to receive. The message itself remains in the Quarantine queue until automatically purged by an aging action or until acted upon by an administrator. The PQM is comprised of two components: the Quarantine Notification service and the PQM Server. The Quarantine Notification service generates Quarantine Summary Notification (QSN) emails that alert recipients to messages addressed to them that are held in the Quarantine queue. The PQM Server handles requests from the QSN email. A QSN is sent to internal recipients when they have at least one new email quarantined and tagged for notification. Administrators control the QSN format and delivery schedule for the QSNs sent to users. See 3.7.5 Setting Up the QSN Format and Schedule on page 151. To assure that only acceptable messages are released, the PQM provides policybased control over which quarantined messages are included in the QSN emails. Administrators control which messages appear in the QSNs by specifying “include” and “exclude” Quarantine queue tags. These tags are added to messages by policies that catch, tag and quarantine certain messages. Only quarantined messages with no “exclude” tags are included in the QSNs. If no tags are specified, by default, no QSNs are created. This default setting can be changed to allow access to all quarantined messages, or tags can be specified to allow access only to messages with the specified tags. See 3.7.6 Setting Up QSN Access Restrictions on page 156. The PQM setup allows administrators to specify a set of approved QSN user domains. Only users in the approved domains (and their subdomains) are notified about their quarantined messages. If no user domains are specified, no QSNs are created. User domains must be specified after installing the PQM components in order for Email Firewall to begin generating the QSNs. See 3.7.4 Specifying User Domains To Receive QSNs on page 149. For information about installing the PQM services, see 3.7 Using Personal Quarantine Manager on page 142.
142
Chapter 3: Working With Queues
3.7.1
Personal Quarantine Manager Server The PQM Server handles requests from the QSN email sent to internal recipients. The actions available in the QSN for accessing the PQM Server are to: • •
release a quarantined message to the recipient. request a new QSN.
When a QSN recipient clicks Release (a Private URL button, or PURL) in the HTML-formatted QSN, or clicks the PURL in the text-formatted QSN, the response from the PQM Server is a simple message indicating that a copy of the message has been sent, that the message is no longer available on the server, that there are no blocked messages, etc. An email user cannot issue a request to release (or browse) all of their quarantined messages. If the recipient’s email client does not provide active links, the PURL can be copied and pasted into the browser to access the messages. If there are multiple recipients on a message in the Quarantine queue, the message is sent only to the recipient associated with that QSN PURL. The message is not deleted from the Quarantine queue following a request from a recipient, both because there may be other recipients who need to access the message, and because an administrator may still want to review the Quarantine queue to analyze why policies are resulting in false positives. Also, if the Dynamic Anti-spam Service (DAS) is installed, an administrator might want to review the Quarantine queue to forward the false positives to the Message Protection Lab. To access a message, no authentication beyond the PURL is required. Anyone with a valid PURL can release the message to the recipient that the PURL is generated for. Like the Email Firewall Web Administration service, the PQM Server can be configured for HTTP or HTTPS. However, if it is configured for HTTPS, this protocol must match the protocol settings in IIS.
3.7 Using Personal Quarantine Manager
143
3.7.2
Quarantine Summary Notification Messages The QSNs allow recipients to release a copy of their quarantined message by clicking a Release button in the QSN HTML-format email, or by clicking a Private URL (PURL) in a text-format QSN. In this way the PQM provides recipients with access to their quarantined messages without Email Firewall administrator intervention. Only quarantined messages that meet the include/exclude tags criteria configured by the administrator are accessible in the QSNs. Tags can be set up so that recipients are prevented from accessing messages that are virus-infected or contain other dangerous material. See 3.7.6 Setting Up QSN Access Restrictions on page 156 for more information. Each QSN message sent to a recipient shows a summary of each message available in the quarantine queue for that recipient. The summary contains sender name, sender address, subject, message date and message size of the quarantined message. Only messages not included in a previous QSN are included in a scheduled QSN. This is different from the case when a user requests an on-demand QSN, as described in the next section. User-requested QSNs include all messages in the quarantine queue that were not already released by the user. In HTML notifications, a Release button is an active link to a Private URL (PURL) displayed for each message. Clicking Release triggers forwarding a copy of the message to the recipient. In plain text notifications, the PURL is included as a Release Link and can be clicked as an active link if highlighted. If the Release Link is not highlighted, the PURL (Web address) can be pasted into a Web browser to trigger forwarding the message. The reply address in the QSN FROM header is the Email Firewall notifier name and address configured in Email Firewall Web Admin Notifications global settings. See 6.4.1 Global Notification Settings on page 288.
QSNs and Quarantine Queue Aging When using PQM it is recommended that the Quarantine queue automatic aging feature be enabled to prevent the Quarantine queues from growing too large. See 3.2.3 Setting Up Queue Aging on page 122. In an Email Firewall upgrade environment, or if Quarantine queue aging was already enabled before beginning to use the PQM, it is recommended that Quarantine queue aging not be increased dramatically because a sudden large increase in the number of messages in the queues may affect performance. If the
144
Chapter 3: Working With Queues
current aging duration needs to be increased, it should be done incrementally, while keeping an eye on performance.
User Requests for Access to Quarantined Messages User access to quarantined messages is normally provided by delivering QSNs to them on a specified delivery schedule. However, users can also be allowed to request on-demand access by enabling the feature that allows a user to request a QSN with links to all of their currently quarantined messages. When this feature is not enabled, users can access quarantined messages only when they have been included in a scheduled QSN. Users may find this on-demand feature useful when they want to find a Release button for a message that was sent in the past and might still be in quarantine, but they do not want to search through their old QSNs, or they cannot search through their old QSNs because they were deleted. This feature is also useful when users want to see what new messages have arrived in Quarantine since their last QSN was received, and they do not want to wait for the next scheduled QSN to arrive. When a user requests a new QSN, the new QSN will include all messages currently in Quarantine for that recipient, which have not already been requested (released) by that recipient. So, the new QSN may include summaries of messages that the recipient has seen in previous QSNs, and some which the recipient has not seen in any previous QSN. But the new QSN does not include reference to any message the recipient has previously released. See 3.7.5 Setting Up the QSN Format and Schedule on page 151 for instructions on enabling this feature. Only messages in the Quarantine queue at the time of the new QSN request are included in the new QSN. Quarantined messages stay in the Quarantine queue until manually acted upon by an administrator (deleted, released, reprocessed or returned) or are automatically deleted by the Quarantine queue aging feature. Once removed from the Quarantine Queue, they are no longer available.
Identifying QSN Message Headers All QSN messages contain a message header that looks something like this: X-MMS-Quarantine-Summary: Version 6.0.4049
This special X-header is used to easily distinguish QSN messages from other messages. The X-header value identifies the QSN release, patch, and build number used to generate the message. 3.7 Using Personal Quarantine Manager
145
This X-header may be useful in troubleshooting. It can also be used to create a policy that prevents specified users from receiving QSNs. See3.9.1 Policies to Prevent QSNs from Being Sent to Specific Users on page 173.
PQM Server Responses When a recipient of a QSN requests release of a message from quarantine or requests a new QSN, Web responses are returned in the browser to indicate the success or failure of the requested action. The possible HTML responses include: • • • • • • • • • •
A queued message was released for recipient, including message data (sender, subject, etc.). A queued message was released for recipient, with no message data included. A queued message was not released because a corresponding message was not found in the quarantine queue. A queued message was not released because it has already been released for the specified recipient. An updated QSN was sent to a specified recipient. An updated QSN was not sent because there were no messages for the specified recipient. Service temporarily unavailable when PQM Server is disabled. Server busy error. Unable to complete request response due to an unexpected server error. Server healthy: initialized/responding to requests.
The last response is sent only in response to a specific Test PQM Server action or a specific URL, both of which request a server health check. See Testing the PQM Server on page 148. The Test PQM Server and health check URL are intended for administrators only. End users are not aware of the URL to perform the health check, and there is no health check link in the QSN. If the server is unhealthy, the response to this health check request will be the “Unable to complete request” response, and the administrator must diagnose the problem using the server log files. To set up the global configurations for PQM, navigate to the Setup > Personal Quarantine Manager pages for: • •
146
Server Settings Users
Chapter 3: Working With Queues
• •
3.7.3
Access Restrictions Notifications
Setting Up PQM Server Settings Initial identification of the PQM Server settings is made during installation. You can check the initial setup immediately after installation using Test PQM Server. Figure 3.5: Setting Up Personal Quarantine Manager Server Settings
3.7 Using Personal Quarantine Manager
147
If these settings need to be changed, use the configuration options on the Setup > Personal Quarantine Manager Server page. Setting up the PQM Server requires identifying the following: • • •
PQM server Host Name in the format host.example.com. PQM server Port Number: Default ports are HTTP 80, HTTPS 443. PQM server Protocol - HTTP or HTTPS. If HTTPS is enabled, IIS must be configured to both enable and require that HTTPS be used when accessing the Personal Quarantine Manager server. A server certificate must be installed on the server to do this.
To make any changes to the PQM Server setup, enter the information in the appropriate field, click Test PQM Server, and if the test is successful, click Save. Figure 3.6 shows a successful test result. Figure 3.6: Testing the PQM Server: Successful Response
Testing the PQM Server The PQM Server settings should be tested after installation. Additionally, if changes are made to any of these settings, the settings should be tested to verify they work properly, before saving them. The PQM Server Test PQM Server button is a health check request that allows an administrator to check the overall health of the PQM Server, without issuing a request to get a new QSN or release a queued message. The PQM Server test checks that the Email Firewall database can be accessed, and returns a response indicating whether it is available to handle requests. If an error response is sent, the administrator must check the server logs to diagnose the problem. Details of the problem are not sent in the response, as a client that is not an administrator
148
Chapter 3: Working With Queues
could use this URL. If not already done, the health check request causes IIS to load the PQM Server extension .dll and all server data to be initialized. In the Setup > Personal Quarantine Manager server page, click Test PQM Server to connect to the PQM Server using the settings shown. The test uses the current settings on the page, not the settings in the database. If you have not made any changes to these settings, then the information shown is the data from the database. If you make any changes to the setup, Test PQM Server allows you to verify the new settings before saving. You must click Save after making any changes, to commit the settings to the database. Be sure to save your settings after you have verified that they are correct. The URL that performs the health check test is: http:///MMSpqm?healthcheck where represents the server hosting the PQM Server. You can copy this URL into a browser to check the PQM Server, in addition to using Test PQM Server.
3.7.4
Specifying User Domains To Receive QSNs Users who should receive QSNs are identified by their domain. All subdomains of the specified domains are included. So, for example, specifying example.com will include host.example.com. It is redundant and therefore unnecessary to add subdomain.example.com to the PQM approved domains list if example.com is already on that list. If no user domains are specified, no QSNs are created. You must specify user domains after installing the PQM Server in order for Email Firewall to begin generating the QSNs. Normally, administrators will want to include only the internal domains in the list of QSN recipient domains. In order for a recipient to release a message from Quarantine, they will need HTTP or HTTPS access to the PQM server. If an organization wants to include external domains in the list, then HTTP or HTTPS access to the PQM server will need to be enabled through the enterprise firewall, and the hostname of the PQM server will need to be published to the Internet Domain Name Service (DNS). The Quarantine Notification service does not provide a direct way to exclude individual users within the approved domains from receiving QSNs. However, this type of exclusion can be accomplished with an Email Firewall policy. See3.9.1 Policies to Prevent QSNs from Being Sent to Specific Users on page 173.
3.7 Using Personal Quarantine Manager
149
To specify approved user domains: 1.
In the left menu, click Setup > Personal Quarantine Manager Users.
Figure 3.7: Setting up PQM User Domains
2.
Type the domain name in the Domain field.
3.
Click Add.
4.
Repeat until all domains are added.
5.
Click Save.
Editing and Removing User Domains When a domain is edited or deleted, quarantined messages for which a recipient has already been notified remain accessible to the recipient. However, if the recipient attempts to get an update of quarantined messages, an “Unable to complete request” response is returned.
150
Chapter 3: Working With Queues
To edit an existing user domain: 1.
In the left menu, click Setup > Personal Quarantine Manager Users.
2.
In the Domain table, click Edit in the domain’s row to make your changes.
3.
Click Save.
To remove an existing domain: 1.
In the left menu, click Setup > Personal Quarantine Manager Users.
2.
In the Domain table, click Remove in the domain's row.
3.
Click Save.
To remove multiple domains: 1.
In the left menu, click Setup > Personal Quarantine Manager Users.
2.
In the Domain table, mark the checkboxes beside the domains you want to remove, and click Remove Checked Domains.
3.
Click Save.
To remove all domains:
3.7.5
1.
In the left menu, click Setup > Personal Quarantine Manager Users.
2.
In the Domain table, click All.
3.
Click Remove Checked Domains.
4.
Click Save.
Setting Up the QSN Format and Schedule QSN messages can be sent in either HTML or plain text format. You should make this selection based on the capabilities of the email client most commonly used by recipients of the QSNs. Each QSN message report can contain up to 1000 links. If the maximum number of links is reached, the links will be included in multiple reports, sent in immediate sequence. The schedule options allow you to specify when Email Firewall should send out QSNs to users who have quarantined messages. Each new QSN provides access to all new quarantined messages that have arrived since the last QSN was sent. It is recommended that the notification scans be run during off-peak hours, to reduce the impact on performance. Runnings notification scans while also under a heavy message-processing load can decrease performance.
3.7 Using Personal Quarantine Manager
151
To avoid recipients being notified about the same quarantined message more than once, administrators running multiple Quarantine Notification Services should try to schedule the scans far enough apart that they do not overlap each other. For more information, see 3.11.3 Duplicate Notifications from Notification Service on page 182. Notification scheduling also has two User Requests options. One allows you to specify whether users have on-demand access to new QSNs containing links to all their quarantined messages. The other allows you to specify whether users can request white listing of specific message senders, to avoid having that sender’s messages blocked and quarantined in the future. To set up the QSN format: 1.
In the left menu, click Setup > Personal Quarantine Manager Notifications.
Figure 3.8: Setting up PQM Notifications
2.
152
On the Notification Options tab, Notification Format heading, mark the Textbased email radio button to send QSN messages in plain text. Using this
Chapter 3: Working With Queues
format, recipients of QSNs click an active PURL Release Link or copy and paste the PURL into their browsers to access their quarantined messages. Or, mark the HTML-based email radio button to send QSN messages in HTML format. Using this format, recipients click a Release button to access their quarantined messages. When this option is selected, QSNs are sent as multipart/alternative with HTML and plain text alternates. 3.
Under the Notification Size heading, leave the default 1000 or enter a different number to include more or fewer links in the QSN. A QSN with significantly more than 1000 links may be rejected by some email clients.
4.
Click Save.
To set up the QSN mailing schedule: 1.
In the left menu, click Setup > Personal Quarantine Manager Notifications.
Figure 3.9: Setting up PQM Notification Schedule
3.7 Using Personal Quarantine Manager
153
2.
On the Notification Delivery tab: 2a. Use the Day drop-down list to select weekdays (Mon-Fri), or a
weekend day (Sat or Sun). 2b. Use the Hour drop-down list to select the time of day that the QSN
should be sent. 2c. Click Add. 2d. Optionally, repeat to add additional scheduled deliveries. 3.
Under the User Requests heading: 3a. Mark the Allow users to request a notification... checkbox if you
want to allow users to request a notification including access to all the quarantined messages they are allowed to see (as determined by the Access Restrictions). See User Requests for Access to Quarantined Messages on page 145 and Enabling QSN Ondemand Access and White-listing for more information. 3b. Mark the Allow users to request a message... checkbox if you want to allow users to request a message sender to be added to the company's white list. See Enabling QSN On-demand Access and White-listing for more information These messages will then be marked appropriately and will be searchable from the Queue Search page. 4.
Click Save.
Enabling QSN On-demand Access and White-listing These two options provide additional user control over quarantined messages. The on-demand access option determines whether users can request a new QSN containing links to all of their currently quarantined messages, rather than waiting for the next scheduled QSN. See User Requests for Access to Quarantined Messages on page 145 for more information. If this feature is not enabled, QSNs sent to users do not include the paragraph “To get an updated report of all your blocked messages at any time, click here”. To enable user access to quarantined messages at any time: 1.
In the left menu, click Setup > Personal Quarantine Manager Notifications.
2.
On the Notification Delivery tab, User Requests heading, mark the Allow users to request a notification including access to all the quarantined messages they are allowed to see (as determined by the Access Restrictions) checkbox.
3.
154
Click Save.
Chapter 3: Working With Queues
To allow user access to quarantined messages only on receipt of a scheduled QSN: 1.
In the left menu, click Setup > Personal Quarantine Manager Notifications.
2.
On the Notification Delivery tab, User Requests heading, unmark the checkbox.
3.
Click Save.
The second option allows users to request that the sender of a quarantined message be put on the organization’s white list, to avoid having that sender’s messages quarantined in the future. If this option is not enabled, the Do Not Block button is not shown in the QSN message shown to the recipient after requesting release of the message. To enable users to designate a sender as a white-list sender: 1.
In the left menu, click Setup > Personal Quarantine Manager Notifications.
2.
On the Notification Delivery tab, User Requests heading, mark the Allow users to request a message sender to be added to company's white list checkbox.
3.
Click Save.
To prevent users from designating a sender as a white-list sender: 1.
In the left menu, click Setup > Personal Quarantine Manager Notifications.
2.
On the Notification Delivery tab, User Requests heading, unmark the checkbox.
3.
Click Save.
Turning Off QSN Deliveries After the QSN delivery schedule has been set up, a scheduled delivery of QSNs can be temporarily or permanently stopped. To temporarily suspend a scheduled delivery of QSNs: 1.
In the left menu, click Setup > Personal Quarantine Manager Notifications.
2.
On the Notification Delivery tab, click Disable in the scheduled delivery’s row.
3.
Click Save.
3.7 Using Personal Quarantine Manager
155
To permanently remove a scheduled delivery of QSNs: 1.
In the left menu, click Setup > Personal Quarantine Manager Notifications.
2.
On the Notification Delivery tab, click Delete in its row.
3.
Click Save.
QSN Format Issues with Outlook Express 6 on Windows 2003 When Outlook Express 6 is installed on clients using the Windows 2003 operating system, the option Read all messages in plain text is enabled by default. This option prevents email clients from displaying .html-based QSN email notifications in .html format, regardless of the setting selected by the Email Firewall administrator. Once this option is deselected, the .html formatted QSN emails are displayed correctly. The Read all messages in plain text option is located on Outlook Express 6’s Tools > Options > Read tab. To disable this option, users must unmark the checkbox beside Read all messages in plain text and click OK. QSN recipients who are using Outlook Express on Windows 2003 should be provided this information on how to disable the plain text option if the administrator wants QSN recipients to receive QSNs in .html format. This QSN display problem does not occur with Outlook Express 6 when installed on clients using the Windows 2000 operating system.
3.7.6
Setting Up QSN Access Restrictions The PQM allows an administrator to control which messages appear in the QSNs by specifying “include” and “exclude” Quarantine queue tags. These tags are added to messages by policies set up to catch, tag and quarantine certain messages. There are two ways to specify how the tags should be used. • •
Allow all messages to be included in QSNs unless they have specified exclude tags. Allow only messages with specified include tags to be included in QSNs, and only if they do not have specified exclude tags.
If no tags are specified, by default after installation, no QSNs are created. This default setting can be changed to allow access to all quarantined messages, or tags can be specified to allow access only to messages with the specified tags.
156
Chapter 3: Working With Queues
Defining exclude tags that deny user access is always optional. But if any exclude tags are defined, they are always used. If even one exclude tag is present, the message is not included in the QSN. It is recommended that tags used by virus scanning and forbidden attachment type policies be added to the list of tags that exclude a quarantined message from being listed in the QSN.
To make best use of the PQM, include and exclude quarantine tags should be used thoughtfully in quarantine policies so that each message can be easily identified by PQM for whether the message should or should not be included in the QSN. For example, tags signifying that a message has a virus should probably be on the “exclude” list, so that even if a message also includes a spam-type quarantine tag, the virus-infected message will not be included in a QSN. When selecting include and exclude tags, be sure not to include the same tag in both lists. If an attempt is made to do this, an error appears advising that the tag is already in use, and stating “A tag cannot be used to both allow and disallow access to quarantined messages.”
Tags and Outbound Security Policies Any message that is quarantined by an outbound security policy should be tagged in such a way that it is not included in any QSNs sent to the recipient. The reason is that the recipient will never be able to successfully release a copy of this message because the Policy Engine will always try to apply the outbound security policies again when the user attempts to release a copy of it.
3.7 Using Personal Quarantine Manager
157
Procedures for Setting Up QSN Tags The Allow users to access... options in PQM Access Restrictions allow you to specify whether the presence or absence of specified Quarantine queue tags should allow or deny user access to quarantined messages. See Figure 3.10. Figure 3.10: Setting up PQM Access Tags
To specify include and exclude tags for QSNs:
158
1.
In the left menu, click Setup > Personal Quarantine Manager Access Restrictions.
2.
To allow access to ALL messages EXCEPT those specifically excluded:
Chapter 3: Working With Queues
2a. Mark the ALL their quarantined messages... radio button to include
all messages except those marked with specified tags. 2b. Optionally, in the (EXCEPT for the specified Exceptions below)
phrase, click Exceptions and specify the exclude tags in the Exclude table. When these tags are selected, users do not have access to any message containing any of these tags. In the Exclude table, click Add to open the Select Tags pop-up page. To select existing tags, mark the checkbox beside each tag you want to select, then click Select Checked Tags. Or, to create one or more new tags, click Create to create the new tags, then select them. 2c. Click Save. 3.
To allow access ONLY to messages with specified tags EXCEPT if they also have tags that are specifically excluded: 3a. Mark the ONLY their quarantined messages... radio button to allow 3b. 3c.
3d.
3e.
access only to messages with specified include tags. In the Include table, click Add to open the Select Tags pop-up page. To select existing tags, mark the checkbox beside each tag you want to select, then click Select Checked Tags. Or, to create one or more new tags, click Create to create the new tags, then select them. Optionally, to specify tags that deny user access to a message even when include tags are present, in the (EXCEPT for the specified Exceptions below) phrase, click Exceptions and specify the exclude tags in the Exclude table. When these tags are selected, users do not have access to any message containing any of these tags. In the Exclude table, click Add to open the Select Tags pop-up page. To select existing tags, mark the checkbox beside each tag you want to select, then click Select Checked Tags. Or, to create one or more new tags, click Create to create the new tags, then select them. Click Save.
3.7 Using Personal Quarantine Manager
159
Editing and Deleting QSN Access Tags Following are procedures for editing and removing tags that determine whether a tagged message is included in a QSN. When editing tags, keep in mind that when a tag is edited or deleted: • •
Quarantined messages for which a recipient has already been notified remain accessible to the recipient. The Quarantine Notification service automatically reconsiders messages that it previously examined and excluded from QSNs because of the tags on the message.
To edit an existing tag: 1.
In the left menu, click Setup > Personal Quarantine Manager Access Restrictions.
2.
Click Add to open the Select Tags pop-up page.
3.
In the tag's row, click Edit to make changes.
4.
Click Save to save the changes to the tag.
5.
Click Save.
To remove a tag from include or exclude rules: 1.
Click Remove in the tag's row.
2.
Click Save.
To remove multiple tags: 1.
Mark the checkbox beside each tag you want to remove.
2.
Click Remove Checked Tags.
3.
Click Save.
To remove all tags: 1.
Click All.
2.
Click Remove Checked Tags.
3.
Click Save. If recipients of QSNs are releasing a large number of their quarantined messages, consider fine-tuning your policies so that these emails are not quarantined by Email Firewall.
160
Chapter 3: Working With Queues
3.8
PQM Reports Sent to Users This section shows some examples of the QSN Blocked Messages Reports sent to users.
3.8.1
HTML Format QSN Blocked Messages Reports Recipients of HTML format QSNs receive a Blocked Messages Report in their email client Inbox that looks like the example in Figure 3.11. Figure 3.11: Sample QSN Blocked Messages Report in HTML Format
A note will appear if the QSN has been broken up into multiple emails. There number of messages after which QSNs are broken up, e.g. 1000, is set up in 3.7.5 Setting Up the QSN Format and Schedule on page 151.
3.8 PQM Reports Sent to Users
161
To access a quarantined message, recipient must click Release. Recipient’s request is acknowledged in the browser. See Figure 3.12. Figure 3.12: QSN Release Message Response
If the message is still on the Email Firewall server, a copy of the message is sent from the Quarantine queue to the Policy Engine, where only security policies are applied, and then to the Outbound queue for delivery to recipient. If the User Requests option to prevent blocking is enabled, when a recipient wants messages from this sender to not be blocked in the future, recipient can click White List on the Message Request Received message. See Figure 3.12. Enabling QSN On-demand Access and White-listing on page 154 and 3.8.4 User Requests for “White List” on page 168 provide information on how to enable recipient access and how to determine which messages have been requested for no blocking.
162
Chapter 3: Working With Queues
A successful request is acknowledged in the browser. See Figure 3.13. Figure 3.13: No blocking Request Submitted and Received
If the request has already been made not to block the sender’s message, recipient is informed. See Figure 3.14. Figure 3.14: Duplicate Request to White list Sender Response
When a release request is made and the message is not still on the Email Firewall server, a message indicating that the message is no longer available is displayed. See Figure 3.15. A message may be unavailable because it was already deleted by an automatic aging action or administrator intervention. A slightly different message is sent when a message is unavailable because it was already released to the recipient. In this case the response informs the user that
3.8 PQM Reports Sent to Users
163
the message was previously released, and when and to whom the message was released. See Figure 3.16. Figure 3.15: PQM Response when Message is Not Available
Figure 3.16: PQM Message After Duplicate Request to Release Message
164
Chapter 3: Working With Queues
3.8.2
Text Format QSN Blocked Messages Reports Recipients of HTML format QSNs receive a Blocked Message Report in their email client Inbox that looks like the example in Figure 3.17. In this format, recipient clicks the PURL beside the RELEASE LINK text. If the mail client cannot display active links, recipient must copy and paste the PURL into the browser address field.The sequence of browser responses is the same as for the HTML notifications. See 3.8.1 HTML Format QSN Blocked Messages Reports on page 161. Figure 3.17: Sample QSN Blocked Messages Report in Text Format
3.8 PQM Reports Sent to Users
165
3.8.3
User Requests for QSNs “On-Demand” When the User Requests option Allow users to request a notification including access to all the quarantined messages they are allowed to see (as determined by the Access Restrictions) is enabled in the PQM Notifications setup, recipients can request an updated report of all blocked messages at any time. See User Requests for Access to Quarantined Messages on page 145. The updated report is triggered from the QSN Blocked Messages Report. In HTML format QSNs, recipients must click the here link in the sentence: “Click here to find out how you can have a report of all your blocked messages sent to you at any time.” When a recipient clicks here, the request is acknowledged in the browser. An example response is shown in Figure 3.18. In text format QSNs, recipients must click the PURL after the sentence “To have a report of all your blocked messages, such as this, sent to you at any time, go to the following Web Address:” The response is the same as for STML format requests as shown in Figure 3.17. Figure 3.18: PQM Requesting a Blocked Messages Report Update Message
166
Chapter 3: Working With Queues
Recipients must then click Request Now to receive a new, updated QSN. After clicking Request Now, a recipient’s request is acknowledged in the browser. An example Request Received response is shown in Figure 3.19. Figure 3.19: PQM Successful Request for QSN Update Message
When no messages for recipient are in the Quarantine queue when recipient clicks Request Now, that status is displayed in the browser. See Figure 3.20 Figure 3.20: PQM Response when No Messages Available
If the User Requests option is not enabled, then the QSN does not include the option to request an updated QSN. In HTML format QSNs, the sentence “Click here to find out how you can have a report of all your blocked messages sent to you at any time” does not appear in the message. In text format QSNs, the sentence “To have a report of all your blocked messages, such as this, sent to 3.8 PQM Reports Sent to Users
167
you at any time, go to the following Web Address:” and PURL do not appear in the message.
3.8.4
User Requests for “White List” When the User Requests option Allow users to request a message sender to be added to company's white list is enabled in the PQM Notifications setup, recipients can request that this sender’s messages not be blocked. See Enabling QSN Ondemand Access and White-listing on page 154. These messages are then marked appropriately and are searchable from the Queue Search page. To determine which messages have been requested for white listing, the Queue Search page Advanced Options selection Message requested for white listing by one or more recipient can be used in a search. See 3.3.2 Creating a Queue Search on page 127 for instructions. It is recommended that a saved search be created for ready access to such messages.
3.8.5
Bookmarking the QSN Update URL When the User Requests option is enabled in the PQM Notifications setup, recipients can bookmark the URL used for requesting updates to their Blocked Messages Reports. In the browser response for QSN updates, the sentence “To bookmark this site for future reference, click here” is provided. See Figure 3.18. For Internet Explorer users, clicking here opens the browser Add Favorite dialog where the bookmark location is specified. Figure 3.21 shows an example. For Netscape users, a message is shown advising that bookmarking is done by entering CTRL-D. Recipients of QSNs using the Lotus Notes client may experience an error if Lotus Notes is configured to use Internet Explorer for the Internet Browser setting. When configured this way, this causes Internet Explorer to be opened within the Lotus Notes client. In this case clicking the link in the QSN Blocked Messages Report page to bookmark the page will generate an error.
168
Chapter 3: Working With Queues
The correct way to bookmark the page in this scenario is to select Create > Bookmark from the Lotus Notes menu bar. Figure 3.21: Specifying the PQM Update Bookmark
3.8.6
PQM and Message Security Concerns This section addresses some of the security concepts related to the format and content of the QSN messages sent to recipients.
Sending QSNs in the Clear QSNs and other SMTP mail sent from Email Firewall to internal recipients are sent on the network “in the clear” unless Email Firewall policies are in use that encrypt all mail sent to internal recipients, or unless other steps have been taken to encrypt the network traffic between the outbound Email Firewall SMTP Relay service and the internal LAN mail system.
3.8 PQM Reports Sent to Users
169
If steps have not been taken to secure internal SMTP message traffic, it may not be worthwhile to configure the PQM Server to require HTTPS. This is because somebody who is monitoring internal network traffic would already be able to read email messages being sent between Email Firewall and the internal recipients. Consequently, encrypting the requests to release quarantined messages adds little security to the environment. However, there are two security benefits of requiring HTTPS access to the PQM Server. •
•
The user identifier value in the URL is hidden (encrypted) from somebody monitoring internal network traffic. If a user’s identifier code becomes known, it is possible for a malicious internal user to repeatedly request new quarantine summary notifications for that user. Normally, the sender and subject of a message released from the Quarantine queue is included in the response message sent from the PQM server to the recipient’s Web browser. If HTTPS is used, this information is hidden (encrypted) when it is sent over the internal network. It is possible to prevent the PQM Server from including these details in the response message.
Message Contents Not Displayed The PQM Server only forwards a copy of the quarantined message; it does not provide an option to display the message in the Web browser. Since Email Firewall does not require that users authenticate themselves when they access the PQM Server and does not require secure (encrypted) HTTP access to the PQM Server, it would be inappropriate for the PQM Server to show the contents of the message in the Web browser. If the message contents were returned using HTTP, this would allow someone who guessed a correct URL to read someone else’s quarantined email in their Web browser. For higher security, there is a configuration parameter that can be modified to prevent the Web browser from showing certain details about the message in the HTTP response. This configuration parameter is in the PqmConfigValues table and is called Enable Message Details in HTTP Response. It can be set to 0 to stop the PQM Server from showing these details about the message in the Web browser. You can use the Configuration Editor to modify this value. See 10.11 Using the Configuration Editor on page 609. The details text that is hidden if Enable Message Details in HTTP Response is set to 0 is: Message Subject: Sender:
170
Chapter 3: Working With Queues
When these details are hidden, the response sent on successful release of a message contains just the following: The message you have requested will be sent to you at: .
3.9
Using Policies with PQM Following is an example policy setup that could be used with PQM. This example assumes that you have the Dynamic Anti-spam Service installed. It also assumes you have completed configuring the PQM Server Settings, Notifications and Users. Policies that you want to use with PQM must be applied to folders, domain records, or user records in the EMF directory in order to create the policy coverage and exception cases required by your organization. For this example, we assume that the organization would want to quarantine for recipient release all messages that are identified as Spam_Moderate. It is expected that these messages are the most likely to be messages recipients would not consider spam (false positives). We also assume that the organization: •
•
would not want recipients to have access to messages identified as containing adult content or adult business-inappropriate language, without administrative review. would not want recipients to have access to messages identified as containing a virus that was not cleaned.
It is also assumed that the organization would want this policy applied to the folder.
Internal
3.9 Using Policies with PQM
171
To set up this PQM scenario, the basic tasks are to: 1.
Select the spam policy that detects Spam_Moderate tag added by DAS. See Figure 3.22.
Figure 3.22: Selecting a Policy to Use with PQM
2.
Enable the policy on the Internal directory folder.
3.
Specify the PQM Access Include and Exclude Tags.
If you do not have DAS installed, you can create a new spam policy and tags to use with PQM.
172
Chapter 3: Working With Queues
To enable a spam policy to work with PQM: 1.
In the left menu, click Policies to open the Policies page.
2.
Click the Spam - DAS: Moderate Confidence policy and review it to be certain it is appropriate for your environment. See Figure 3.22.
3.
If the policy is appropriate for your environment, click Cancel. Or, make any necessary changes for your environment and click Save.
4.
In the left menu, click Directory.
5.
Navigate to the folder containing internal users who will be the QSN recipients. (In most environments this would be the Internal folder.) Click Edit.
6.
Navigate to the Spam - DAS: Moderate Confidence policy and click Enable.
7.
In the left menu, click Setup.
8.
In the setup page, under the Personal Quarantine Manager heading, click Access Restrictions.
9.
In the Personal Quarantine Manager Access page, under the Allow users to heading, mark the ONLY their quarantined messages tagged... radio button.
access...
10. In the Tags table immediately below, click Add. 11. In the Select Tags pop-up page, mark the checkbox beside Spam_Moderate
and click Select Checked Tags. 12. In the Personal Quarantine Manager Access page, under the Exceptions
heading, verify that the Inbound Virus Not Cleaned tag and the Spam_Adult tag appear (these tags appear by default in this table). 13. Click Save.
3.9.1
Policies to Prevent QSNs from Being Sent to Specific Users To prevent recipients who should not receive QSNs from receiving them, you can create an Email Firewall policy. The type of policy to accomplish this is a recipient-based Unencrypted Message Filter policy that catches messages that are not encrypted and will not be encrypted by the server, and which also contain the X-MMS-Quarantine-Summary message header. See Identifying QSN Message Headers on page 145 for more information on this header.
3.9 Using Policies with PQM
173
The policy summary for this type of policy is: Catch messages where... Not encrypted by the client and will not be encrypted by the server and X-MMS-Quarantine-Summary exists Take the following actions... Drop the message
If you are currently using some type of encryption policy (for example, proxy encryption) between Email Firewall and the internal recipients who are not allowed to receive QSNs, this approach will not work. This is because the message will be encrypted and therefore will not be caught by the Unencrypted Message Filter policy. Also, if you are unable to create user records for the forbidden recipients, you must fine-tune the example policy. In this case, the policy should be changed to a sender-based policy applied to a single user record in the directory, created for the Email Firewall notifier sender email address. This address is configured in the Notifications setup. See 6.4.1 Global Notification Settings on page 288. You must add another condition on the policy to check when the recipient is on an address list of forbidden recipients. This approach works because QSNs never have more than one recipient; so there is no concern about all recipients being blocked because of the presence of one forbidden recipient.
3.9.2
QSNs for Recipients with Multiple Aliases The Quarantine Notification service does not attempt to coalesce notifications that are sent to different aliases for the same user. So, if a user has a quarantined message that was addressed to two different aliases, the user will receive two separate notifications, one for each alias. You can work around having multiple QSNs sent to the same user if each user has a user record in the Email Firewall directory. On the user record, there is a text field labeled Delivery Address. When a delivery address is specified, mail sent to any of the user’s aliases is modified so that the delivery address replaces the alias on the SMTP envelope. Consequently, all quarantined mail for that user will be addressed to exactly one email address.
174
Chapter 3: Working With Queues
3.10 Personal Quarantine Manager Maintenance The following sections provide information that may be useful in maintaining the Personal Quarantine Manager.
3.10.1 Changing the PQM Server Account Password If you need to change the PQM Server account password, you must follow these steps. Just changing the password on the system will not work. If you change the password on the system without updating the new password from the IIS Service Manager, this will cause a problem when releasing messages. To update the password for the PQM Server account in IIS: 1.
Start Internet Service Manager.
2.
Expand the Default Web Site tree.
3.
Select EMFPQMServer.
4.
In the right pane, locate the pqm.dll. Right-click it, then select Properties.
5.
In the Properties dialog, select the File Security tab.
6.
In the Anonymous access and authentication control group box, click Edit.
7.
In the Authentication Methods dialog, Anonymous access group box, click Edit.
8.
In the Anonymous User Account dialog, enter the new password for the user account. In the confirmation dialog, re-enter the password.
9.
Click OK, OK, and OK to close the dialogs and save the new settings.
3.10.2 PQM Tables that Must Not be Replicated For a complete overview of using Email Firewall with replication, see the Tumbleweed Email Firewall Best Practices Guide. However, when using replication with PQM, the following tables must not be replicated between a publisher and a subscriber: •
PqmConfigValues
Cannot be replicated because of the HTTP host name, which must be unique for each Email Firewall database.
3.10 Personal Quarantine Manager Maintenance
175
•
PqmUsers
This table is updated independently in each Email Firewall database. •
PqmScanStarted
This table is updated independently in each Email Firewall database. The other tables added during PQM installation may be included in the list of tables replicated between Email Firewall databases.
3.10.3 PQM and IIS Server Configuration Issues This section discusses aspects of IIS configuration as they relate to the PQM Server, to be considered in addition to regular IIS server administration.
Authentication Methods By default, the PQM Server supports anonymous access and integrated Windows authentication. In the case of anonymous access, the PQM Server uses a configured NT account to access the Email Firewall database. To change the PQM Server authentication control or anonymous account, you must: 1.
Navigate to the PQM.dll in IIS under Default Web Site/EMFPQMServer
2.
Right-click on PQM.dll and select Properties.
3.
Select the File Security tab.
4.
Click Edit under Anonymous access and authentication control.
5.
Enable/disable authentication methods as require.
6.
To change the account user for anonymous access, click Edit under Anonymous access.
7.
Click OK until Properties is closed.
There is no need to stop and start the World Wide Web Publishing Service, as the new settings will take immediate effect.
176
Chapter 3: Working With Queues
PQM Server Anonymous Account The PQM Server anonymous account is specified during installation. It is recommended that a new account be created for PQM Server anonymous access. This account should be granted the minimum permissions required to access the Email Firewall database and the server running the PQM Server. The minimum database roles that must be assigned to the PQM Server account are the db_datawriter and db_datareader roles for EMFMail (or whatever the Email Firewall Mail catalog is named). No Server Roles need to be assigned. The PQM Server account must have the following server access: • •
• •
write access to Windows Event Log. read/write access to the system temporary file folder and permission to read from the Email Firewall installation folder (where the QSN templates are stored). read access to the HKLM\Software\Tumbleweed\MMS windows registry key. read access to the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib.
Read access to the HKLM\Software\Tumbleweed\MMS windows registry key can be granted using regedt32.exe. Navigate to the HKLM\Software\Tumbleweed\MMS windows registry key, select Security, and give the PQM Server account Read permissions to the Email Firewall key.
Application Protection By default, the PQM Server is configured to be run by IIS as “out-of-process medium isolated application.” This is configured by setting Medium(Pooled) as the value for Application Protection, on the EMFPQMServer IIS virtual directory Properties page. However, you can change this setting to High(Isolated), if desired. PQM can run as either a high isolated or medium isolated (pooled) process. Both high and medium are “out-of-process” and safe. However, running as a high isolated process guarantees that PQM will run in a separate process, whereas running as a medium isolated process means that PQM will run in a common process along with other Web applications. Running PQM as a high isolated process is the most effective. However, running PQM as a high isolated process is possible only if MSDTC service is installed and running. If MSDTC is not installed, then running PQM as a medium isolated process is an alternative. On Windows 2003, the Com+ System 3.10 Personal Quarantine Manager Maintenance
177
Application Service should also be running (or at least enabled) so that the PQM can be registered as a high isolated process. During installation the Email Firewall installer first tries to make PQM an IIS application that will run as a medium isolated process. If this is not possible due to any reason, then the installer tries to make PQM an IIS application that will run as a high isolated process. The application protection can, however, be manually changed by following the instructions in Adding IIS Virtual Directories Manually, and especially step 17, in the Email Firewall 6.1 Installation and Upgrade Guide. If you are running Windows 2003, IIS 6.0 can be configured to run in one of the following modes: • •
IIS 5.0 Isolation Mode - used for backward compatibility. If you have upgraded from IIS 5.0 (or earlier) then this is the default setting. Worker Process Isolation Mode - provides some enhancements. This is the default setting if you have fresh installation of Windows 2003.
See the IIS 6.0 documentation for more information. The above information is also valid if you are running IIS 5.0 (on Windows 2000) or IIS 6.0 in IIS 5.0 Isolation Mode (on Windows 2003). If you are using IIS in Worker Process Isolation Mode (on Windows 2003), you may want to isolate the Email Firewall PQM Server in a new separate application pool. This would be equivalent to the high isolated application on Windows 2000. By default, the Email Firewall installer runs the Email Firewall PQM Server in the default application pool. If, for whatever reason, the application protection mode is changed to Low (IIS Process), then PQM_res.dll must be copied from the Email Firewall installation directory to the location of inetinfo.exe (usually C:\winnt\system32\inetsrv), and IIS Admin Service and World Wide Web Publishing Service must be stopped and restarted. If this is not done, the PQM Server will return the “Unable to Complete Request” response, and the IIS log file will log that a failure occurred loading PQM_res.dll.
Secure HTTP Access PQM Server can be configured to use HTTPS for secure access. This can be configured during installation or after installation. In addition to configuring Email Firewall to use HTTPS for Email Firewall Web Administration, a server certificate must have been created for the IIS web site under which the PQM Server is running.
178
Chapter 3: Working With Queues
PQM Server Logging PQM Server problems can be diagnosed using Email Firewall events and the IIS log file. Email Firewall Event Logging Level The Email Firewall event logging level for the PQM Server is set through an integer value in the PQMConfigValues database table, called Web Service Logging Level. The default value is 2, for Web Service Normal Logging Level. To enable Trace level logging, set Web Service Logging Level = 1. To enable Debug level logging, set Web Service Logging Level = 0. It is recommended that the Web Admin Set Up > Configuration Editor page be used to set the value of Web Service Logging Level in PqmConfigValues. This will ensure that lastUpdate is also updated, which is required for the PQM Server to detect that the logging level has been changed. If you change the default value for troubleshooting, be sure to change it back to Web Service Logging Level = 2 when troubleshooting is complete.
IIS Logging The location of the IIS Log files is set using the IIS Web Site Properties. This location of the latest log file containing a log of HTTP requests received by the Web Site is usually: C:/WINNT/System32/LogFiles/W3SVC1
Diagnosing Authentication Problems Authentication problems can arise in three settings: • • •
access to the PQM server Web site access to the server on which the PQM is installed access to the Email Firewall database
The following sections describe the issues and likely resolutions.
3.10 Personal Quarantine Manager Maintenance
179
Unauthorized to Access the PQM Server This indicates the PQM.dll authentication method is not configured correctly. This can occur if: • • •
no authentication method is selected. Windows integrated authentication is the only authentication method, and the user is not using Windows authentication. Anonymous access is selected, but the anonymous account name or password is invalid.
In each of these cases, the response is the standard You are not authorized to view the page, HTTP 401 response. The PQM Server extension is not even called, so clearly no Email Firewall events will be logged. This problem can be detected by searching for HTTP Status code 401 (Unauthorized) in the IIS logs. Unauthorized to Access Server In this case an account is used that is authorized by IIS but does not have access to the server on which PQM Server is running, in particular does not have access to the Windows registry or NT Event Log. No Email Firewall Event will be logged, nor will a Windows Event be logged. The IIS log must be used to diagnose the problem. Search for [MMSPQM:+Error:+Access+denied+to+Windows+registry.].
In this case, PQM Server does send the generic Unable to Complete Request page.
Unauthorized to Access Email Firewall database It is possible that the PQM Server is accessed using an account that does have server access privileges but does not have access to the Email Firewall database. In this case, no Email Firewall Event is logged. However, a Windows event is logged: Event ID: 14502. Event Description: PQM Server initialization failed. Details: PQM Server initialization error. Error code: 0x80040e4d. Unable to process requests.
180
Chapter 3: Working With Queues
To detect this in the IIS log file, search for [MMSPQM:+Error:+Creating+QSN+library+handle.+Error+code+0x 80040e4d]
In this case the generic Unable to Complete Request page is returned.
3.11 Troubleshooting the PQM The following sections provide information that may be useful in troubleshooting the Personal Quarantine Manager.
3.11.1 PQM Notification Service “Not Running” or Not Shown If SQL Server was down (for example, during an upgrade, or for any other reason), after it is back online, the Email Firewall Personal Quarantine Manager service is shown as Not running on the Email Firewall Web Administration Status page. This is not a cause for immediate concern. After SQL Server has been down, the reason the PQM Server is shown as Not running is because even though SQL Server has been restarted, the PQM Server does not yet have a connection to SQL Server. The PQM Server will create a new connection when it receives a request from a user to release a message or a request for a new QSN. At that time, the service will be shown as running. You must refresh the Status page to view the change to the Running status. Also, immediately after installation, the PQM Server ISAPI extension is not accessed, and so does not make a connection to the Email Firewall database until the first request is received. Once a request is made to the PQM Server, the Personal Quarantine Manager status is displayed. You must refresh the Status page for this to appear.
3.11 Troubleshooting the PQM
181
3.11.2 Localization Issues and PQM Message Display The PQM uses the UTF-8 character set for QSNs, and this is the only supported and tested character set. This means that all Quarantine Summary Notification (QSN) content is in the English language and uses the UTF-8 character set for the inline text and HTML content of the notifications. It is possible that some email clients may not handle UTF-8 gracefully, especially when it comes to rendering symbols that are not part of the native character set of the recipient's computer. In this case, it is likely the recipient would have had trouble viewing this message had it been passed by Email Firewall rather than being retained in the Quarantine queue. In the unlikely event that conversion of the Subject header from Unicode to the UTF-8 character set fails, the QSN will use the following string in place of the original subject: The subject of this message could not be displayed. If the conversion of the sender's display name from Unicode to UTF-8 fails, the display name will not be shown, although the sender's email address will be shown.
3.11.3 Duplicate Notifications from Notification Service The Quarantine Notification service may be installed on multiple hosts, each of which is referencing the same Email Firewall database. However, exactly one service will execute a scheduled scan of the Quarantine queue, regardless of how many instances of the service are running. You may want to have more than one instance of the service running for high-availability reasons, but there is no performance advantage gained by installing multiple Quarantine Notification services. To avoid recipients being notified about the same quarantined message more than once, administrators running multiple Quarantine Notification services should try to schedule the scans far enough apart that they do not overlap each other. Normally, it should not take more than one hour for a Quarantine Notification service scan to run. However, the first time the service is run, or if has not been run for a number of days, there may be a buildup of messages in the Quarantine queue. The default behavior is that a single Quarantine Notification service will not start a scheduled scan if the current time is more than 30 minutes after the time that the scan was supposed to start. For example, when there is only one Quarantine Notification service running, the 10:00 a.m. scheduled scan will start after the 9:00 a.m. scan finishes, if the 9:00 a.m. scan finishes between 10:00 a.m. and 10:30 a.m. 182
Chapter 3: Working With Queues
However, if more than one Quarantine Notification service is installed, scans may be running at the same time. For example, assuming a backlog of quarantined messages, if one QNS starts the scan at 9:00 a.m. while the second QNS starts a scan at 10:00 a.m., if the 9:00 a.m. scan has not completed before the 10:00 a.m. scan starts from the other service, a recipient may be notified twice about the same quarantined message. Similarly, if a recipient requests an updated QSN before a previous request for an updated QSN has been completed, the recipient may be notified twice about the same quarantined message.
3.11.4 Personal Quarantine Manager FAQs Following are some frequently asked questions about PQM. Q: What happens if a spam email is sent to a mail list (e.g.,
[email protected]) and quarantined? Will the QSN be sent to all email addresses included in that list? A: Yes, normally they would. To avoid this you can create a policy to block emails from the Internet to email lists. Q: What happens if all recipients have not requested a copy of the message before the automatic aging feature or an administrator deletes the message from the Quarantine queue? A: Recipients who request a message after the message is deleted from the queue receive an HTML response advising them that the message is no longer on the server. This is a normal occurrence, as it is strongly recommended that Quarantine queue aging be enabled and configured to manage the size of the queue. Q: Why doesn’t the QSN tell recipients how long their quarantined messages will remain on the server? A: An accurate estimate cannot be provided because custom Quarantine queues have independent aging configurations. A message can end up in any of the queues and the associated aging of individual messages in an individual QSN will vary. Q: What happens if an administrator removes the message before the Quarantine queue aging time has run?
3.11 Troubleshooting the PQM
183
A: The QSN recipient will get a response in the Web browser indicating that the message is no longer available on the server. (The recipient can still contact the sender using the information in the QSN.) Q: Will all aliases for given email account receive the notification? A: Yes. The PQM does not do anything particular for aliases. If a recipient receives messages to multiple aliases, the recipient normally will receive a summary notification (QSN) for each of the aliases. See 3.9.2 QSNs for Recipients with Multiple Aliases on page 174 for information on how to work around this. Q: If a messages is released to recipient, is it processed by the Policy Engine again or is it sent directly to the Outbound queue? A: It is processed by the Policy Engine again, but only outbound security policies are applied. This is exactly the same process that is used when an Email Firewall Administrator releases a message from Quarantine using Web Admin. This means that the Policy Engine will not apply content-type policies, but will apply security policies. Q: After the recipient releases the message and receives it, can the recipient view the sender’s email address and reply to the message? A: Yes, the message released is exactly as though the recipient had received it directly in the first place. Q: The server hosting Email Firewall Web Admin is usually located behind firewalls and only administrators have access to it. Does the PQM server need to be exposed to the public (Internet)? A: No, the PQM server normally does not need to be exposed to the public. This would only be necessary if you configured Email Firewall to send quarantine summary notifications to recipients in an external domain.
184
Chapter 3: Working With Queues
4
Working With the Event Log
The Email Firewall Event Logs shows how Email Firewall is operating in your environment. Filtered event log files show only the information that is important to you. This chapter contains the following sections: 4.1 4.2 4.3 4.4
Setting Up Email Firewall Event Logging ............................. 186 Searching the Event Log......................................................... 190 Using Event Log Filters ......................................................... 192 Searching for Message Events................................................ 199
For information on Centralized Event Logging and Reporting, see 2.8.2 Setting Up Centralized Event Logging and Reporting on page 101.
185
4.1
Setting Up Email Firewall Event Logging The Event Log is the Email Firewall component that stores and displays events logged by Email Firewall. An event is any significant occurrence in Email Firewall, such as initialization of services, process failure, or defined policy events. Use the event logging options to configure how Email Firewall will record events. The importance level of events from the Policy Engine and SMTP Relay can be configured using these options. Events can be held indefinitely or can be deleted after a configurable number of days. Automated event log export is available to save the log events to a location other than the database. See 4.2 Searching the Event Log on page 190 for more detailed information on how to define the event log information that is collected and how it is displayed. Global configuration setup allows you to specify these logging levels for the Policy Engine and SMTP Relay: • • • •
Major Normal Trace Debug
Whenever a message is handled by the Email Firewall Policy Engine and the logging level is set to Normal, an event is logged. The Email Firewall reporting tool uses these Normal event log files to produce the email-usage reports described in Chapter 11, Email Firewall Reports. Global configuration setup allows you to define when to delete logged events for the following: • • • • •
Policy Engine SMTP Relay Audits Report Summary Tables Report Detail Tables
Automated event log export is available to save the log events in a location other than the database. Custom events can be created that record specific system events that you may want to monitor. See 4.3.2 Creating Custom Events on page 194.
186
Chapter 4: Working With the Event Log
4.1.1
Setting up Global Event Log Settings The global configuration settings for event logging are: • • •
•
Logging Levels:
specifies what type of events are logged. Event Aging: specifies how long event log files are kept in the database before being deleted. Centralized Event Log and Reporting: specifies the settings for setting up Centralized Event Log and Reporting; see 2.8.2 Setting Up Centralized Event Logging and Reporting on page 101 for more information. Event Log Export: specifies whether to automatically export the log events on a regular basis. When Centralized Event Log and Reporting is setup, Logging Levels and Event Log Export settings are available only on the central machine.
There are two ways to access the global settings for the Event Log:
• •
4.1.2
In the Email Firewall main menu, click Set Up to open the Set Up page, then click Event Logging to open the Set Up > Event Logging page. In the left menu, click Event Log to open the Event Log page, then click Setup Event Logging to open the Event Log > Event Logging page.
Setting Up Logging Levels The logging level determines which events generated by the Policy Engine and SMTP Relay are written to the Event Log. The logging level options are: 1.
Major
- Some significant events and errors (least detail). When the Policy Engine logging level is set to Major, only the Audit reports and single user audit reports show the events.
2.
Normal
3.
Trace
4.
Debug
- Most events and high level message processing.
- All message processing steps and actions taken. - Full binary dumps and debug messages (most detail).
4.1 Setting Up Email Firewall Event Logging
187
Event Logging using Trace and Debug levels can significantly affect performance and will require additional disk space. Due to the amount of system resources used when the Debug level is selected, it is recommended that you select Debug only when requested to do so by your Global Support representative.
4.1.3
Setting Up Event Aging Event log aging determines when logged events are automatically deleted from the database. Automatic deletion is available for events logged by the following: • • • • •
Policy Engine SMTP Relay Audits Report Summary Tables Report Detail Tables
For each of these, you can select to delete after a specified number of days, or choose to never delete the events. The log files to produce email-usage reports are based on the Normal events logged by the Policy Engine. However, the Event Log data and Report Log data do not depend on each other, so you do not need to synchronize the data expiration actions when setting up event logging for the Policy Engine and for the Reports Detailed and Summary Tables. Due to the rapid growth of events, it is recommended that you do not select the option to never delete events unless you are sure that your database is powerful enough. The Event Log can accumulate over a million events per day.
To understand how event log aging affects performance, review 4.1.5 Cleanup Jobs and Message Processing on page 189 before making these selections. To specify event log aging:
188
1.
For each table, mark the radio button to Delete events older than X days and enter the number of days in the field, or, mark the radio button to Never delete events.
2.
Click Save.
Chapter 4: Working With the Event Log
4.1.4
Event Log Export Automated event log export is available to save the log events in a location other than the database. This allows you to free up database space while still retaining event log information. To prevent the off-loaded events folder from becoming too large, these file can be automatically deleted after a specified number of days. To enable automatic event log offloading:
4.1.5
1.
Mark the Enable automated event log export checkbox to enable event log offloading from the database to another folder.
2.
Enter the full path of the Destination Folder where the export files will be stored. This folder must be on the same machine as the Email Firewall database.
3.
Enter the number of days to save the files before they are deleted.
4.
Click Save.
Cleanup Jobs and Message Processing If the number of events in your Event Log tables is large, the Policy Engine may accept messages very slowly during the Cleanup Tables job. SQL Server is set to run this job every day, and by default will delete events and audit events older than seven days. If you notice a slowdown in message processing, you can configure the log events to be deleted more frequently than daily. Also, if the Event Log tables are full when SQL Server begins a Cleanup Tables job, the Email Firewall database will go into suspect mode. To avoid this, make sure the Event Log is not allowed to become filled to capacity, and do not set the Event Log table to autogrow. For more detailed information on configuring you SQL Server optimally for Email Firewall, see the Tumbleweed Email Firewall Best Practices Guide.
4.1 Setting Up Email Firewall Event Logging
189
4.1.6
SQL Server Job Events Not Reported Email Firewall runs SQL Server jobs periodically that do not report events to the Email Firewall Event log. These jobs are: • • • •
Cleanup Tables Create Summary Queue Aging Actions Queue Thresholds
You can monitor these jobs manually by using SQL Server Enterprise Manager to view the job history. You should check periodically to verify that the jobs are enabled and are running on schedule.
4.2
Searching the Event Log The Event Log stores all events logged by Email Firewall. An event is any significant occurrence in Email Firewall such as initialization or failure of services, default and custom policy events, and audited administrator actions. In the left menu, click Event Log to open the Event Log Search page. In most environments, the event log grows very quickly. For performance reasons, the default set of filtered events shows all non-audit events logged at all event levels in all categories and components in the last 30 minutes. Click
190
Chapter 4: Working With the Event Log
to view the default set of filtered events. Figure 4.1 shows a sample Event Log search results page.
Search
Figure 4.1: Event Log Search Results
Message event searches use the data in the EventDetails tables. You can only search on the data based on the retention period for the Report Detail Tables. To ensure accurate searches, be sure the Report Detail Tables deletion time is the same or longer than the deletion time for the Policy Engine and SMTP Relay events. See 4.1 Setting Up Email Firewall Event Logging on page 186 for more information. When Centralized Event Log and Reporting is setup, the Event Log Search page shows all logged events for the central and satellite machines. The user can distinguish where this event has taken place by the information in the Machine column.
4.2 Searching the Event Log
191
4.3
Using Event Log Filters In most enterprise production environments the event log grows very large, very quickly. Too many events makes viewing all events, even those from just the previous 30 minutes, unproductive. One of the first tasks when using the Event Log is to create meaningful and useful filters to show only those events you are interested in. Event Log filters let you view the specific types of events, or range of Event IDs or Message IDs, that you are interested in. Once the filter is created, for the time period defined by the filter, you can: • •
Find events by Event IDs or Message IDs Find events with any of these specified Event properties: • Event type: Info, Warning and Error • Email Firewall Component and Component Category • Event Description, Details or Machine • Logging level: Major, Normal, Trace and Debug • Audit event: by Administrator and Audit Category
Most organizations create a number of filters that let them view how specific areas of Email Firewall are operating in their environment. The more specific the filter query, the faster the results will return. If a query is taking too long to return, click Cancel and refine the filter.
4.3.1
Creating Event Log Filters Event log filters let you control how much and what kind of information is displayed in the Event Log page. Filters make it easier to find more specific information that is useful to you. Search granularity can be achieved using the contains or begins with search options in the Description field. When creating a filter, you can select to filter for specific Event IDs. You can create your own custom Event IDs to log events that keep track of policy violations, and then filter for them. See 4.3.2 Creating Custom Events on page 194.
192
Chapter 4: Working With the Event Log
To create a new Event Log filter: 1.
In the left menu, click Event Log to open the Event Log Search page.
2.
In the Event Log Search page, click Edit Filters to open the Event Log > Event Filters page. This page shows the filters you currently have in place, if any.
3.
In the Event Log > Event Filters page, type a name for the new filter in the Filter Name field. The name should be descriptive of the type of event you are filtering. For example, type “Administrator Actions” if you want to filter for specific audit events created by administrator actions. Then click Create.
4.
In the Event Log Search page, mark the radio button to select a time period (in minutes, hours or days) or a specific time range for events the filter should show. See Figure 4.2. Or, mark the No time filter radio button if you want to search without a time restriction. This option is useful when the filter is expected to return a relatively small number of events.
Figure 4.2: Event Log Search Time Parameters
5.
Mark the radio button to select either Event IDs or Message IDs or with All the following event properties.
5a. If you selected Event IDs or Message IDs, type the IDs you want to
search in the corresponding fields. Be sure to enter multiple IDs as a comma-separated list of IDs or ID ranges, ex. 1,3-5. 5b. If you selected event properties, make your selections from some or all of the following: • Event Type that occurred: Information, Warning, or Error events. • Logging Level that was logged: Major, Normal, Trace, or Debug. • Email Firewall Component you want to monitor, or All Components. • Email Firewall Category you want to monitor: Services, SMTP Relay, Policy Engine, Policy Manager, Directory, or All Categories.
4.3 Using Event Log Filters
193
• Event Description text. Optionally, use the drop-down list to select begins with. By default, the selection is contains. • Event Details text. • Machine where the event occurred. If you employ a centralized Email Firewall database server to which to log all events within your distributed Email Firewall deployment, you can enter more than one machine name to perform a search for multiple Email Firewall systems. Multiple machine names must be entered as a comma-separated list. 5c. If you selected event properties, Audit events, enter the name of Administrator who has EMF audit privileges. Then select from the drop-down list select the specific EMF Audit Category. 5d. Click Save to commit the new filter to the database.
4.3.2
6.
Verify that the new filter appears in the Event Log > Event Filters page.
7.
On the main Event Log Search page, use the drop-down list to select and search events using the new filter. Depending on the size of your event log, it may take a few moments to display the filtered events.
Creating Custom Events An event log action can be added to most Email Firewall policies to alert you to when the policy was triggered. You can use these event log actions to keep track of policy violations. You can track these specific policy-related events
194
Chapter 4: Working With the Event Log
(identified by their Event IDs) by creating custom events. See Figure 4.3: Email Firewall Custom Events on page 195. Figure 4.3: Email Firewall Custom Events
When you create or edit an event, you must define: • • • •
Event ID:
Values between 300 and 999 are reserved for custom log events. Event Severity: Information, Warning, or Error. Event Level: Major, Normal, Trace, and Debug, as described in4.1.2 Setting Up Logging Levels on page 187. Description: A brief description of the event details.
The global Event Log settings affect whether the custom events you create for policy violations are displayed in the Event Log. See 4.1 Setting Up Email Firewall Event Logging on page 186. For example, if your Policy Engine Logging Level is set to Normal and you create a custom Event with the logging level set to Major, the custom Event will not be displayed in the Event Log, even though the policy may have been violated, because your global setting is to show only Normal events.
4.3 Using Event Log Filters
195
To create a new Event: 1.
In the left menu, click Events.
2.
In the Events page, Event ID field, type a number for the Event ID.
Event ID numbers must be between 300 and 999.
3.
In the Severity column, use the drop-down arrow to select a severity level: Information, Warning or Error.
4.
In the Level column, use the drop-down arrow to select a logging level: Major, Normal, Trace or Debug. Setting logging at a level that generates a lot of events has an impact on system performance.
Check your Policy Engine event log Logging Level to be sure your new Event ID logging level is at a level that will be displayed in the event log when the policy is violated.
5.
196
In the Description field, type a description for the Event ID that is descriptive of the event that will be logged. For example, if you know you want to log an event when a virus policy is triggered, Virus Policy Violation would be a good description.
Chapter 4: Working With the Event Log
6.
In the Action column, click Create to open the Event > Edit Event page. See Figure 4.4.
Figure 4.4: Defining the Details for an Event ID
7.
In the Events > Edit Event page, type an explanation for the Event ID in the Detail field. You can use placeholders in the Detail field. Table 4.1 lists the event detail text placeholders and what they invoke. (You can use either upper or lower case.)
Table 4.1: Event Detail Placeholders Placeholder
Will Be Replaced With
$DATE
The date and time the message was processed
$SUBJECT
The subject of the message that triggered the policy
$POLICY
The name of the policy that was triggered
$RECIPIENTS
The RFC 2821 (SMTP envelope) recipients of the original message, including BCC recipients
$SENDER
The RFC 2821 (SMTP envelope) sender of the original message
$SIZE
The size of the original message
$SERVER
The Email Firewall server name
4.3 Using Event Log Filters
197
Table 4.1: Event Detail Placeholders Placeholder
Will Be Replaced With
$ATTACHMENTS The names of the attachments contained in the original message $REASON
The reason the policy fired
$MESSAGE_ID
The ID of the message
8.
Click Update. An Email Firewall event is logged as a Windows event only when the Email Firewall Event Level is “Major.”
See 4.3.1 Creating Event Log Filters on page 192 for information on creating and using filters to organize how log events are displayed.
198
Chapter 4: Working With the Event Log
4.4
Searching for Message Events You can search the event log to see how Email Firewall is processing specific message events. There are two options for finding message-related events. You can specify Event Log Message Search criteria according to: •
Time range or all events and • Subject • Sender • Recipients • Attachment File Name You can enter an address or a domain in the Sender and Recipient fields.
•
One or more specified Message IDs Multiple Message IDs must be entered as a comma-separated list.
Search granularity can be achieved using the contains or begins with search options in the Subject, Sender, Recipients and Attachment File Name fields. See Figure 4.5.
4.4 Searching for Message Events
199
Figure 4.5: Searching for Events About Messages
To find message events: 1.
In the left menu, click Event Log.
2.
In the Event Log page, click Search for Message Events to open the Event Log Message Search page. See Figure 4.5, which shows the search options available.
3.
To search message events by time and any of these specified criteria: Subject, Sender, Recipient, and Attachment File Name, mark the ALL the following criteria radio button and complete the fields you want to search for. 3a. Optionally, use the drop-down lists beside each field to select contains, and enter the search text in the adjacent field. By default, the option is set to begins with.
3b. Optionally, in the Sender and Recipient fields you can use a
wildcard search using the asterisk (*), and enter either an address or a domain.
200
Chapter 4: Working With the Event Log
3c. Optionally, Recipient and Attachment File Name fields can include
multiple comma-separated entries. 4.
Or, to search by message ID, mark the or ANY of the following Message IDs radio button and type one or more message IDs in the field. Multiple message IDs must be entered as a comma-separated list.
5.
Click Search.
Click Refresh to add additional messages to the filtered set that may have come in since the last search.
4.4 Searching for Message Events
201
202
Chapter 4: Working With the Event Log
5
Understanding Policies
This chapter gives an overview of Email Firewall policies and how they work. It is recommended that you review these concepts carefully before editing the default policies or defining new ones. Instructions and examples for creating policies are provided in Chapter 6, Creating and Editing Policies. Global Email Firewall policy settings for Peak Time, Archive, Options and that apply to all Email Firewall policies that use any of these policy actions are configured in the Setup > Policies page. See 2.7 Setting Up Global Policy Settings on page 87. Policy-based Routing
This chapter contains the following sections: 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Policy Overview...................................................................... 204 Policy Categories and Types .................................................. 210 Email Firewall Directory........................................................ 220 How Email Firewall Applies Policies .................................... 233 General Policy Planning Considerations ............................... 240 Default Policies and Folders.................................................. 245 Policy Building Tools ............................................................. 253
203
5.1
Policy Overview Policies provide the message security measures available to Email Firewall after a message has been accepted by the Email Firewall SMTP Relay. This section explains how Email Firewall policies are structured. Before you attempt to create any new policies, you should understand the concepts described in this chapter. You should also understand how the Email Firewall directory works. See 5.3 Email Firewall Directory on page 220. No policy is in effect for any user until the policy is applied to an Email Firewall directory object.
5.1.1
Definitions Policy A policy is a set of rules and actions.
Rules Rules define to whom a policy applies, and the selected catch and exclude conditions that constitute a policy violation that triggers the policy action.
Actions Actions are the response to the policy violation. Some policies may also include backup actions stating which further actions to take should the initial action fail. Basic Mail Filtering dispositive policy actions include: • • • • • • •
204
Drop/Delete Message Return Message to Sender Quarantine (with Spam tags) (message remains in quarantine until action performed by reviewer) Detain for X minutes/hours/days (with Spam tags) Redirect Message to a secure IME server Defer Delivery to off-peak hours Deliver Normally
Chapter 5: Understanding Policies
Other non-dispositive policy actions include: • • • • • • • •
Route to a specified server using a routing rule Add Recipients (from List) Annotate Message (header/subject/body/or add attachment) Send Notification/Forward message (to Sender/Recipient/others/etc.) with options to include original message as attachment or inline Log Event Append/Delete text to/from Subject Add X-header Archive Message (with Spam tags) to disk or to a mailbox address
Other policy types provide additional or different policy action options.
5.1.2
Example Each policy begins with a simple phrase; for example, “Catch messages where ALL of the following are true.” To this phrase, you add a context (sender/recipient/this user) in which the policy operates, what conditions the policy looks for, what conditions are excluded from triggering the policy, what actions follow when the policy conditions are met, and sometimes backup actions to complete the policy. All policies have one or more of the following components: • • • •
Name Catch Conditions Exclude Conditions Actions
5.1 Policy Overview
205
The complete textual description of every policy can be viewed in its Policies > Edit Summary page. Figure 5.1 shows an example of the Email Firewall default Infected Message (Sender) policy viewed in its summary page. Figure 5.1: Infected Message (Sender) Policy Summary page
Name Each policy should have a simple and descriptive name. For example, the default Virus policy that detects viruses in outbound messages is named Infected Message (Sender), as that best describes its function.
Catch Conditions Catch conditions state the conditions under which a policy will be invoked. Available conditions vary among the policy categories and policy types. Some policies require that the sender or recipient be identified; others look only at content, attachment, or type of message.
206
Chapter 5: Understanding Policies
For example (conditions in bold): Policy Name: Large Attachments Deferral Policy Type: Basic Mail Filtering Applies To: Recipient Catch Messages where... Contains any attachments
and Size is larger than 2MB Take the following actions... Defer delivery of the message until “Off-Peak”
and Send the notification “Recipient Note - Inbound Large Attachments Deferral”
Exclude Conditions Exclude conditions state what will prevent a policy from being invoked though it otherwise meets the policy catch conditions. For example (exception in bold): Policy Name: Large Attachments Deferral Policy Type: Basic Mail Filtering Applies To: Recipient Catch Messages where... Contains any attachments
and Size is larger than 2MB But Exclude messages where... Marked as High Take the following actions... Defer delivery of the message until “Off-Peak”
and Send the notification “Recipient Note - Inbound Large Attachments Deferral”
5.1 Policy Overview
207
Actions Actions are the response when a policy is triggered. An action can be: • • •
informative, such as sending a notification, making a log entry, or copying the message to an archive. transformative, such as appending an annotation, changing the subject text, adding X-headers, adding recipients. dispositive, that is, determining whether it will be processed normally, delivered based on a specified routing rule, returned to sender, or have a delivery exception applied to it such as defer, detain, redirect, drop, or quarantine.
For example (actions in bold): Policy Name: Infected Message (Recipient) Policy Type: Infected Message Applies To: Recipient Catch Messages where... One or more viruses were detected Take the following actions... Forward a Clean Copy of the message if successful, Quarantine the infected message with the tag: “Inbound Virus Cleaned” and Append the annotation “Recipient - Inbound Virus Alert” and Send the notification “Admin Virus Note - Inbound Virus Cleaned” and Send the notification “Sender Note - Inbound Virus Found” otherwise Quarantine the infected message with the tag: “Inbound Virus Not Cleaned” and Send the notification “Sender Note - Inbound Virus Found” and Send the notification “Admin Virus Note - Inbound Virus Quarantined”
208
Chapter 5: Understanding Policies
Backup Actions Backup actions available to some policy types state which further actions to take should the initial action fail. These backup actions are available to certain transformational actions such as: strip attachment, strip virus, and security related transformations. For example (backup actions in bold): Policy Name: Infected Message (Sender) Policy Type: Infected message Applies To: Sender Catch Messages where... One or more viruses were detected Take the following actions... Forward a Clean Copy of the message if successful, Quarantine the infected message with the tag: “Inbound Virus Cleaned” and Append the annotation “Recipient - Inbound Virus Alert” and Send the notification “Admin Virus Note - Inbound Virus Cleaned” and Send the notification “Sender Note - Inbound Virus Found” otherwise Quarantine the infected message with the tag: “Inbound Virus Not Cleaned” and Send the notification “Sender Note - Inbound Virus Found” and Send the notification “Admin Virus Note - Inbound Virus Quarantined”
Summary While not a discrete component of a policy, the policy summary is the textual statement of the complete policy, including its name, catch conditions, exclusion conditions, and actions. Every policy type has a summary page where you can view the policy while you are creating it, and when it is complete.
5.1 Policy Overview
209
5.2
Policy Categories and Types Figure 5.2 shows the main Policies page. Figure 5.2: Email Firewall Policy Categories and Policy Types
210
Chapter 5: Understanding Policies
This section describes the policy categories and to whom they apply (senders, recipients, or “this user”); the types of policies in each category; and the actions available to them. When an email message is received by the Policy Engine in a compressed format or with embedded files, the Policy Engine can decompress and decompose many compressed and embedded files and file formats, making the content available to all the policy types for policy enforcement. For a complete list of the file types recognized by the Policy Engine, see Appendix A, File Types Scanned.
5.2.1
Basic Mail Filtering Policy Types The Basic category contains one policy type: Basic Mail Filtering. Policies in this category apply to either senders or recipients. Basic Mail Filtering policies can look in: •
Message address, including: • Any sender or reply address in (or not in) a specified address list. This option checks the SMTP (envelope) sender address plus several message header addresses against the address list, including FROM, REPLY-TO, etc. • The SMTP sender address in (or not in) a specified address list. This option checks only the SMTP (envelope) sender address against the address list. • This user's address in (or not in) a specified address list. This option checks only the address that was used to determine which sender policy to apply against the address list. Normally, this is only the FROM header address. This condition is especially useful for policies that are applied to Domain records, where you may have a list of addresses within that domain that need to have some policy applied/excluded and you do not want to create user records for those users. This option can also be very useful in policies that attempt to detect address spoofing. See the Tumbleweed EMF Anti-Spam Best Practices Guide for more information. This option is available in Sender-based policies only.
5.2 Policy Categories and Types
211
•
•
•
• Any recipient in a specified address list. This option checks the SMTP (envelope) recipient address plus several message header addresses against the address list. Message volume - Policies that look at message recipients can look for messages sent to more or fewer than a specified number of recipients. • This includes the number of recipients the message is sent to, including Display Recipients (To and CC), Routing Recipients (RCPT TO), or BCC Recipients. When the Dynamic Anti-spam Service is installed, presence of Spam Indicators: • Content - adult, scam and broadcast • Confidence level - high and moderate Message content: • Subject - Policies that look for keywords in the message subject. • Body - Policies that look for keywords in the message body also scan the plain text extracted from any inline text/html MIME parts. • Attachments - Policies that look for the presence of attachments at all, or specific types of attachments, or keywords in attachments to the message.
Additional options to message scanning include: • • •
Scanning messages for HTML tags when scanning for the words specified in a policy. Counting at most one instance of each word list expression when scanning the subject, message body and attachments. Not scanning plain text MIME part if an alternative HTML part is available. Ignoring the plain text part introduces a potential security risk since the text and HTML parts can have different content.
You can also specify catch and exclude conditions for: • • • •
212
Message signature status - when the message is signed, validation status. Message priority - high, normal, low. Message size - larger than, smaller than (in MB or KB). When sent - before X date, after X date.
Chapter 5: Understanding Policies
• • •
Origin and authentication information - internal or external network, and DNSBL and TLS status. Message headers - standard header field, custom header field
SPF test results - filter for the SPF test results of Passed SPFTest, Failed SPF Test, Soft Failed SPF Test, and Inconclusive or Not Tested. If you select to filter on Failed SPF Test for either catch or exclude conditions, you are required to change the Reject On Failed SPF Test key to 0 in the RelayConfigValues table to enable the SPF Fail policy. Otherwise, by default when the SPF test result is failed, the message is rejected and is not passed through the Email Firewall Policy Engine. To enable the SPF Fail policy, do the following: 1.
Go to Set Up > Configuration Editor page.
2.
Select RelayConfigValues from the Table Name drop-down menu.
3.
Enter Reject On Failed SPF Test in the Key Name field.
4.
Click Find.
5.
Change the default integer value in the Integer Value field from 1 to 0.
6.
Click Update.
These general-purpose policies are well suited to preventing junk mail and spam from entering or leaving your organization. They can also be very precisely defined to catch mail containing specific harmful, objectionable or confidential content. Policy actions specify what Email Firewall should do with messages that meet the catch conditions. For information about how policy actions are applied, see 5.4 How Email Firewall Applies Policies on page 233.
Random Selection In the Basic policy category you can also specify that a random selection (by percentage) of messages normally caught by the policy be caught. This can assist in performance and reporting functions. Each time a “random policy” is evaluated, the server calls a random number generator to produce a random integer. Then, Email Firewall calculates the percentile of that integer in the range of legal values that can be returned by the random number generator. If
5.2 Policy Categories and Types
213
that percentile is less than or equal to the percentile specified in the policy condition, the condition is satisfied. You must take special care when creating this type of policy if you combine the random sample policy condition with other policy conditions. This is because there is no way to specify which policy condition is evaluated first. For example: Policy Name: Random Sample Plus Policy Type: Basic Mail Filtering Applies To: Sender Catch messages where... The subject contains the phrase “this keyword” and Only 75.00% percent of the time Take the following actions... Deliver normally and Log the event “Random Sample”
In the above example, there is no way to determine whether this policy will catch 75% of the messages from this sender and then check the subject for keywords, or whether it will it catch 75% of the messages that have the keyword in the subject. While Email Firewall will always do one or the other, there is no way to tell ahead of time which it will do. If you want to create a policy that will catch 75% of the messages that have the keyword in the subject, it could be written like this example: Policy Name: Random Sample Plus Policy Type: Basic Mail Filtering Applies To: Sender Catch messages where... The subject contains the phrase “this keyword” But Exclude messages where... Only 25.00% percent of the time Take the following actions... Deliver normally and Log the event “Random Sample”
This policy will be triggered for 75% of the messages that have the keyword in the subject. 214
Chapter 5: Understanding Policies
5.2.2
Attachments Policy Types The Attachments policy category includes two types of policies: • •
File Attachment Stripping Convert UUencoded Attachments to MIME format
These policy types scan messages for attachments and specific attachment types. The distinction between these types of policies and the Basic policy types is that the attachment policy types perform transformational actions: they either remove attachments, or convert attachments. Policies in this category apply to either senders or recipients, depending on the specific type. In the File Attachment Stripping category, you can also specify that a random selection (by percent) of messages normally caught by the policy be caught. See Random Selection on page 213 for more information.
File Attachment Stripping This policy type applies to either senders or recipients. Use this policy type to remove or change file attachments. You can specify files by name, MIME type, or true file type. Email Firewall determines true file type by examining the content of the file, rather than simply trusting the file name or MIME type. There is an option to perform the stripping after the virus scanning policies. When enabled, the attachment stripping performed by the policy engine will occur after the message has been scanned for viruses. This option allows the administrator to define different dispositions for: • •
messages containing forbidden attachments messages that are virus infected and contain forbidden attachments
When this option is not enabled, once the forbidden attachment (which also happens to contain a virus) has been stripped, the Policy Engine will not know that the original message was virus infected. For example, one could set a policy to quarantine or drop virus infected messages, but let clean messages pass after stripping any attachments containing an executable file. This option is disabled by default, which means that virus scanning policies are applied after file attachment stripping policies.
5.2 Policy Categories and Types
215
Convert UUencoded Attachments to MIME Format. This policy type applies to recipients. Use this policy type to examine messages for UUencoded attachments and reformat them as MIME body parts.
5.2.3
LDAP Policy Types The LDAP query-based filtering policy type applies to either senders or recipients. You can apply this policy type on either the external domain records or internal domain records. Use this policy type to filter messages based on the addresses returned by an LDAP query. The policy uses an LDAP query that looks up message sender or recipient addresses in an external, LDAP-enabled enterprise directory. This policy type is useful when, for example, you want to add a policy that detects mail sent by a user in an external domain that is not addressed to a company employee, based on the company enterprise directory. This can be accomplished by adding a recipient policy to the internal domain record to catch when a message is sent to an address in the internal domain that does not exist in the corporate directory. A disposition for messages sent to a recipient address that is not found in the company directory can be configured as required. This policy type is useful when, for example, you want to add a policy that detects mail sent by a user in an external domain that is not addressed to a company employee, based on the company enterprise directory. This can be accomplished by adding a recipient policy to the external domain record that has a “This user's address is not in” condition that uses an LDAP query to the company directory. This policy would be added to the internal domain record, to catch when a message is sent to an address in the internal domain that does not exist in the corporate directory. A disposition for messages sent to a recipient address that is not found in the company directory can be configured as required. This policy type can also be used when you want to add a policy that detects when company employees or a certain sub-set of employees are sending messages to recipients in a specific mail domain. This can be accomplished by adding a recipient policy to a domain record that has a “Sender is in” condition that uses an LDAP query to the company directory. A disposition for messages sent by a user whose address is returned by the LDAP query can be configured as required.
216
Chapter 5: Understanding Policies
5.2.4
Virus Policy Types The Virus policy category includes two types of policies: • •
Infected Message Clean Stamp Uninfected Messages
These policy types apply to either senders or recipients. They scan all message bodies for viruses in order to prevent them from entering or leaving your organization. They can also provide recipients with assurance that the messages sent to them are not infected.
Infected Message Use this policy to detect messages with infected attachments, disinfect them, and forward a clean copy of the message to the recipient.
Clean Stamp Uninfected Messages Use this policy to add a Clean Stamp annotation to messages that do not contain viruses. This assures the recipient or sender that virus detection policies are in place and working.
5.2.5
Security Policy Types The Security policy category includes eight types of policies that are used for server-to-client proxy security and for client-to-client security: • • • • • • • •
Sender Signature Proxy Decrypt and Verify Proxy Encrypt and/or Sign Automatic Certificate Association Unencrypted Message Filter Client Encryption and Signature Allow Security Stripping Plaintext Access
The Security policy types sign, encrypt, decrypt and secure inbound and outbound mail traffic. Policies in this category apply to either senders or recipients, depending on the specific policy.
5.2 Policy Categories and Types
217
For a full overview of Email Firewall security, see Chapter 8, Email Encryption and Authentication Overview. For more detailed information on the Email Firewall proxy security and clientto-client security policies, see: • • •
5.2.6
8.5.3 The Email Firewall Proxy Security Policy Types on page 384 8.6.1 “Allow” Client-to-Client Security Policies on page 387 8.6.2 “Require” Client-to-Client Security Policies on page 389
SPN Policy Types The SPN policy category includes three types of policies that are used for server-to-server security: • • •
Non-SPN Message Received from an SPN Domain (inbound) Imperfect SPN Message Received (inbound) Unable to Encrypt and Sign Message to an SPN Domain (outbound)
The SPN policy types apply to “This user.” They recognize SPN messages and specify the actions to take when security problems in correspondence with SPN domains are encountered. For a full overview of Email Firewall security, see Chapter 8, Email Encryption and Authentication Overview. For more detailed information about establishing SPNs and using SPN policies, see 8.3.4 The Email Firewall SPN-Type Policies on page 372.
5.2.7
Headers Type Policies The Headers policy category includes three types of policies: • • •
Remove MIME Headers Remove Host Names and Subdomains from MIME Headers Normalize Email Addresses in MIME Headers
Use these policies to remove or change specific headers in messages.
218
Chapter 5: Understanding Policies
Remove MIME Headers Use this policy to strip MIME or message headers from email messages to remove, for example, Received headers that would disclose your internal network or internal mail system information.
Remove Hostnames and Subdomains From MIME Headers Use this policy to protect your organization’s network information by removing internal hostname and subdomain information about your network from email before it is sent outside of your organization.
Normalize Email Addresses in MIME Headers Use this policy to protect network privacy by removing internal hostnames from email addresses specified in the message headers. This policy type replaces the display name and the email address in common standard headers such as To, From, CC. However, it replaces only the email aliases from other MIME headers. For instance, in the Disposition-Notification-To header, it replaces only the email alias but not the display name.
Message Header Fields Header fields are of numerous types, and they display information that an organization may wish to scan for in messages, or to hide from external view. The Email Firewall program installs many common header types with the default policies. Table 5.1 lists the default message header types you can select from. You can also add your own custom message header fields. See 6.10 Using Headers Type Policies on page 313 for additional information and instructions.
Table 5.1: Types of Message Header Fields cc
Resent-bcc
Comments
Resent-cc
Content-Description
Resent-Date
Content-Disposition
Resent-From
Content-ID
Resent-Message-ID
Content-MD5
Resent-Precedence
5.2 Policy Categories and Types
219
Table 5.1: Types of Message Header Fields (Continued)
5.3
Content-Transfer-Encoding
Resent-Reply-To
Content-Type
Resent-Sender
Date
Resent-To
Encrypted
Return-path
From
Return-Receipt-To
In-Reply-To
Sender
Keywords
Subject
Message-ID
To
MIME-Version
X-Advertisement
Precedence
X-Mailer
Received
X-MMS-Redirect-To
References
X-MSMail-Priority
Reply-to
X-Priority
X-MMS-Spam-Confidence
X-Urgent
X-MMS-Content-Rating
X-MMS-Spam-Filter-ID
Email Firewall Directory The following sections describe the Email Firewall Directory objects to which policies are applied.
5.3.1
Directory Objects The Email Firewall Directory contains three types of objects: folders, domain records, and user records.
220
Chapter 5: Understanding Policies
Folders Folders are containers for other objects in the Directory. Folders can contain other folders, domain records, and user records. Policies assigned to folders are inherited by all the user records, domain records and subfolders contained in the folder. You can create as many levels of folders and subfolders as you need to define appropriate security for everyone in your organization. Any object in a folder inherits policies from all parent folders. Because of the way policies are inherited, folders are usually the recommended objects for assigning policies. See 5.4 How Email Firewall Applies Policies on page 233 for more information on policy inheritance. Unlike a user record or a domain record, a folder by itself does not represent a specific user or group of users. In fact, a folder has no function until you add other objects to it, but then it becomes a useful and flexible tool for assigning policies to groups of users with similar security needs.
Domain Records Domain records represent users in a common domain who have no individual user records in the Email Firewall Directory. If your domains are consistent with logical or functional groups within your organization, you can use domain records to assign specific policies to those groups. A domain record inherits policies from the folder in which it resides. A domain record can also have its own set of policies. You can avoid unnecessary maintenance by structuring your Directory and policies around specific domains rather than creating multiple duplicate policies for specific users. The recommended strategy for assigning a policy to a domain is to create a folder for the domain, add the domain record to the folder, and assign the policy to the folder. This strategy makes it easier to define additional policies for specific users within the domain, without those users losing the protection of the domain-level policies.
Default Domain Record The default domain record is a special instance of domain record. It represents all email addresses where the domain does not match any domain record in the Email Firewall Directory. Use the default domain record to set generic policies that apply to all email traffic between unspecified domains and users.
5.3 Email Firewall Directory
221
User Records User records represent individuals both within and outside your organization. User records inherit policies from parent folders only, never from domain records.
User records represent specific users who require distinct policies. User records can be used for the following: • • •
Creating an individualized policy for one unique user. Creating an individualized policy for one or more groups of individual users with similar security needs. Defining exceptions to policies defined at the folder level.
User records inherit policies and permissions from the folders in which they reside. The recommended strategy for assigning a policy to an individual user is to create a folder for the user, add the user record to the folder, and assign the policy to the folder. This strategy makes it easier to assign the same policy to other users in the future simply by adding other user records to the same folder. If Email Firewall will be performing encryption, a user record is required for a person who is not part of an SPN but to whom you plan to send signed or encrypted mail.
5.3.2
Default Directory Structure This section describes the default Email Firewall Directory structure. It is set up so that you can use a set of policies that apply to all users, a set of policies that
222
Chapter 5: Understanding Policies
apply to users within your organization only, and a set of policies that apply to users outside your organization only. Figure 5.3: The Email Firewall Default Directory Structure
All Folder By default, this folder contains: • •
policies that apply to all users and domains. the External and Internal folders and all the objects that they contain.
Policies applied to the All folder apply to all inbound and outbound mail traffic in your organization. Use this folder to create umbrella policies that you want to apply to all email traffic entering or leaving your organization.
External Folder By default, this folder contains: • •
the default domain record, which represents all email domains that are unknown to your organization. policies that apply to users in external organizations. These policies apply to users in external organizations because the default domain record is in this folder. It is not a property of the folder itself.
Use the External folder to apply policies to mail to and from users outside your mail domain who do not have an Email Firewall directory record, and to store records for any external domain or users with which you regularly exchange mail. This folder inherits the policies applied to the All folder.
5.3 Email Firewall Directory
223
Internal Folder By default, this folder contains: • •
policies that apply to users within your organization. a domain record for your internal domain.
Use the Internal folder to apply policies to email to and from all users in your email domain and to store records for additional internal domains. This folder inherits the policies applied to the All folder. See 5.6 Default Policies and Folders on page 245 for more information on the policies installed with Email Firewall. See Chapter 6, Creating and Editing Policies for more information on how to customize policies to apply to specific domains, users, and groups of users.
5.3.3
Viewing Policies Applied to Directory Objects You can see which policies are applied to specific directory objects using the Directory. To view the policies applied to a directory object: 1.
In the left menu, click Directory.
2.
Click the Directory folder icons until the folder, domain record or user record you want to view is displayed, then click Edit.
3.
The Policies on this... tab shows the polices for that directory object. Remember, directory objects inherit policies from their parent folders.
5.3.4
Adding New Directory Objects You can customize the Email Firewall Directory so that it more closely reflects how groups within your organization, and users within those groups, should be protected by Email Firewall policies. Also, when you automate adding user records to the Email Firewall Directory using the LDAP Import tool, you must have an Email Firewall Directory
224
Chapter 5: Understanding Policies
structure in place that allows you to map user records to their appropriate Directory folder. See 10.2 Setting Up LDAP Directory Imports on page 534 for information about using LDAP import. For information about setting security for directory objects, see 9.1.1 Email Firewall Security Prerequisites on page 431. Figure 5.4shows a typical simple Email Firewall Directory structure. Figure 5.4: Email Firewall Simple Directory Structure
Adding Folders To add a folder to the Directory: 1.
In the left menu, click Directory to open the directory page.
2.
Decide where in the Email Firewall Directory hierarchy the new folder should reside.
3.
Navigate to the parent folder in which the child folder will reside.
4.
In the Entry column, click the directory folder icons until the folder (at the top of the page) into which you want to place the new folder is open.
5.
In the Entry column field, type a name for the new folder.
6.
In the Type column, use the drop-down arrow and select Folder.
5.3 Email Firewall Directory
225
7.
Click Create to open the Directory > Edit Folder page. See Figure 5.5 for an example.
Figure 5.5: Creating a New Directory Folder
8.
In the Notes field, type any information about the folder’s intended purpose or contents (optional).
9.
Click Save.
10. Verify the new folder appears in the directory hierarchy in the proper
location.
226
Chapter 5: Understanding Policies
Adding Domain Records To add a domain record to the directory: 1.
In the left menu, click Directory to open the directory page.
2.
Decide where in the Email Firewall Directory hierarchy the new domain record should reside. Click the directory folder icons until the folder into which you want to place the new domain is open.
3.
In the Entry column field, type a name for the new domain.
4.
In the Type column, use the drop-down arrow and select Domain.
5.
Click Create to open the Directory > Edit Domain page. See Figure 5.6 for an example.
6.
In the Domain Properties tab, complete the following information: 6a. Name: 6b. Email domain: 6c. Notes: optional information about the domain record’s intended
purpose or members. 6d. Click Save. 7.
Verify the new domain appears in the directory hierarchy in the proper location.
8.
To configure domain security, in the new domain’s row, click Edit.
9.
Scroll down to the Domain Security tab and make your selections for reformatting S/MIME signatures, secure public network for SPN and S/MIME Gateway, certificate selection to associate with the domain, and encryption strength.
10. Click Save.
For background information on security features available in Email Firewall, see Chapter 8, Email Encryption and Authentication Overview. For instructions on setting up security, see Chapter 9, Security Configuration. For additional information, see the Email Firewall Help.
5.3 Email Firewall Directory
227
Figure 5.6: Creating a New Directory Domain Record
Adding User Records To add a user record to the directory:
228
1.
In the left menu, click Directory to open the directory page.
2.
Decide where in the Email Firewall Directory hierarchy the new user record should reside.
3.
Click the directory folder icons until the folder into which you want to place the new user record is open. Note that you cannot create a user record in the top-level Directory folder. You must open the Directory and select a folder in it.
Chapter 5: Understanding Policies
4.
In the Entry column field, type a name for the new user record.
5.
In the Type column, use the drop-down arrow and select User.
6.
Click Create to open the Directory > Edit User page. See Figure 5.7 for an example of some of the options in the Edit User page.
Figure 5.7: Creating a New Directory User Record
7.
In the User Properties tab, complete the following information: 7a. Public Email Address: Required. This address must be unique in
the entire Email Firewall Directory. 7b. Display Name: 7c. Name: 7d. Email Alias: You can add multiple aliases. While this field is
optional, if it is used, the address must be unique in the entire Email Firewall Directory. 7e. If you added any email aliases, mark the Replace the delivery address and all email aliases in FROM, TO and CC message headers with the public email address checkbox, if you want the user’s
email to display a consistent address—the user’s public email 5.3 Email Firewall Directory
229
address. This option is used to replace all of the user’s email aliases with the user’s public email address in the message headers that affect the address to which replies will be sent. The Replace the delivery address and all email aliases in FROM, TO and CC message headers with the public email address option is not used to protect network privacy.
7f. Delivery Address: This is the forwarding address used if the
delivery address is different from the public email address. 7g. Notes: optional information about the user record’s intended
purpose or user. 8.
Click Save.
9.
Verify the new user record appears in the directory hierarchy in the proper location.
10. To configure user record security, in the new user record’s row, click Edit. 11. Scroll down to the User Security tab and make your selections for
reformatting S/MIME signatures, certificate selection to associate with the user record, and encryption strength. 12. Click Save.
For background information on security features available in Email Firewall, see Chapter 8, Email Encryption and Authentication Overview. For instructions on setting up security, see Chapter 9, Security Configuration. For additional information, see the Email Firewall Help.
230
Chapter 5: Understanding Policies
5.3.5
How Policies and User Records Work Together Policies can be assigned directly to a user record, or can be assigned by placing a user record into a folder to which policies are already applied. See Figure 5.8 for an example of a user record placed in a folder so that all the policies that apply to the folder also apply to the user record. For additional information about policies and inheritance, see 5.4.3 Understanding Policy Inheritance and Overrides on page 237. The easiest and most efficient way to assign policies to individual users is to place the user record in a folder that has a particular policy or policies assigned to it. Then, under the rules of inheritance, all user records in that folder inherit all policies assigned to that folder.
5.3 Email Firewall Directory
231
Figure 5.8: Policies Assigned to a User Record
5.3.6
Using LDAP Import You can populate your Email Firewall directory with user records using LDAP Import. For complete instructions, see 10.2 Setting Up LDAP Directory Imports on page 534.
232
Chapter 5: Understanding Policies
5.4
How Email Firewall Applies Policies To fully understand how Email Firewall applies policies, you need a good understanding of the Email Firewall Directory structure and its objects. See 5.3 Email Firewall Directory on page 220 for this background information. Email Firewall applies policies by first matching the sender or recipient email address to the Email Firewall Directory using the specifier
[email protected]. If there is no user defined with that address in the Directory, Email Firewall looks for the domain name. It searches for the most specific domain match in the Directory. If there is no specific match, it will widen the domain search. If there are no more specific matches, it will match with *domain (the default domain). When Email Firewall finds a matching user record or domain, it applies the inherited sender or recipient policy set as appropriate.
5.4.1
Hierarchy of Message Actions When more than one policy action is specified, or when more than one policy is triggered by a message, each policy action is evaluated by the Policy Engine to determine the final disposition of the message.
Not all policy actions are available in all policy types.
There is a hierarchy of dispositive actions. If multiple policies are triggered by the same message, then the most severe disposition from that set of policies is applied. For example, if one policy specifies a quarantine action while another policy specifies a defer action, the quarantine action would take precedence. This is true regardless of whether the policy is a sender policy or a recipient policy. Actions determining a message’s disposition are subject to the following hierarchical response (listed in the order of most severe to least severe action): 1.
Drop
2.
Return to Sender
3.
Quarantine
5.4 How Email Firewall Applies Policies
233
4.
Detain
5.
Redirect
6.
Defer Delivery
7.
Deliver Normally
Where multiple dispositive actions are invoked: • •
•
If multiple detention policies apply, the longest detention period is used. If different dispositive actions apply to different recipients, the message is partitioned as necessary. The Policy Engine considers each recipient separately, so the message is partitioned if different recipients have different dispositions that need to be applied. Once partitioned: • If the disposition indicated by the sender policy is more severe than the disposition indicated by the recipient policy, then the sender disposition is the one that is applied for that recipient. • If the disposition indicated by the recipient policy is more severe than the disposition indicated by the sender policy, then the recipient disposition is applied. If a message is subject to a Redirect action, additional rules apply. See the Secure Redirect Administrator’s Guide.
When a message meets the Deliver Normally, Defer or Detain dispositions, Routing dispositions can apply that specify where the message should be routed. These are set up in the SMTP Relay Setup Routing Rules. See 2.5.12 Mail Routing Rules Overview on page 57 and 2.5.13 Setting Up Mail Routing Rules on page 60. Email Firewall also provides informative and transformative actions: • • • • • • • • • • • 234
Add Recipients Annotate Notify Log Event Change Subject - append, prepend and delete text from the message subject Add X-header name and value Archive Strip Attachments Encrypt/Decrypt Clean Message/Eradicate Virus Change Header: remove headers, remove alias, remove internal hostname
Chapter 5: Understanding Policies
Non-hierarchical Policy Actions Informative and transformative policy actions are not subject to hierarchical response; the action is carried out for every invoked policy. If dispositions are different for different senders/recipients, the message is partitioned. When a message is partitioned, multiple copies of the same message are made so that each disposition can be applied for each sender/recipient to which the policy actions apply.
Timing and Ordering of Policy Action Application Email Firewall policies are applied in order so that composition aspects of security policies are applied last to outbound messages, and decomposition aspects of security policies are applied first to inbound messages. This allows the unencrypted messages to be scanned by the Policy Engine. Outbound messages are scanned before any encryption action occurs. Inbound messages are decrypted before being scanned by the other policies. In general, the order in which policies are evaluated will vary, except that: •
• •
5.4.2
The outbound security policies are applied in the second phase of Policy Engine processing, after all other types of policies are evaluated. The outbound security policy types are: SPN encryption related policies, Proxy Encryption & Signature, Sender Signature, and Unencrypted Message Filter. These policies are applied only to messages that have been “passed” by the first phase. When a message is released from the Quarantine or Detention queues, the outbound security policies are applied. Attachment stripping occurs before virus scanning, although that order can be altered on a per-attachment stripping policy basis.
How Severity of Action Affects Policy Enforcement Most likely you will find that you have multiple policies defined for the different folders, domains, or users in your Email Firewall Directory. If a message invokes multiple policies, each of which specifies a different disposition, the most severe disposition among the applicable policies is enforced.
5.4 How Email Firewall Applies Policies
235
Suppose this Large Attachment Deferral policy is in place for all users: Policy Name: Large Attachment Deferral Policy Type: Basic Mail Filtering Applies To: Recipient Summary of policy, ready to save: Catch messages where... contains any attachments with a size larger than 10KB defer delivery of the message until “Off Peak” and send the notification “Large Attachment Message Deferral” to the user to whom policy is being applied
Suppose this SPAM Quarantine policy is also in place for all users: Policy Name: SPAM Quarantine Policy Type: Basic Mail Filtering Applies To: Recipient Summary of policy, ready to save: Catch messages where... The message text has a “spam keywords” score of at least 9 Take the following actions... Quarantine the message with the tag: “Spam” and Send the notification “Manager Note - SPAM”
If a message that has an attachment larger than 10KB and also contains words from the SPAM list is sent to one of these users, it invokes both policies. Quarantining the message is more severe than deferring it, and the following actions occur: 1.
The message is quarantined, not deferred.
2.
The mail administrator receives a “Manager Note - SPAM” notification.
3.
The intended message recipient receives a “Large Attachment Message Deferral” notification.
Although the action specified in the SPAM Quarantine policy was enforced, any nonconflicting (informational or transformational) actions in all policies that apply to the message are performed as well. These actions include sending notifications, annotating messages, logging events, and adding recipients. An example of a conflicting action that could prevent an informational or transformational action from being applied is if either of the “Don’t send” Notification options have been selected for the Notification policy action and are triggered. See Dropped or Returned Message Notification Option on page 293 and Virus in Message Notification Option on page 293. 236
Chapter 5: Understanding Policies
5.4.3
Understanding Policy Inheritance and Overrides The following section describes how policy inheritance and overrides work. Generally, they can be conceptualized as follows: • • •
All directory objects inherit policies from their containing folder objects. Policies can be modified only from the Policies > Edit pages. Modifying a policy affects the policy everywhere it is used. Modifying a policy is a global action affecting every instance where the policy applies. Enabling, disabling, and locking a policy are actions affecting application of the policy to the directory object(s) to which it applies.
•
• •
Policies can be enabled or disabled at any level (unless they were locked at the level at which they are owned) without affecting application at other levels. Policies can be removed only at the level at which they are owned. Policies owned at a higher level and disabled at a lower level are retained at the lower level even if the policy is removed from a higher level (though not enforced if disabled). However, once the policy is removed at the higher level, the lower level directory object becomes the owner of the policy as though it had originally been added at that level.
The following procedures show how policy inheritance works, and shows how to create policy overrides using the Lock, Enable and Disable features. These exercises assume you have installed the Email Firewall default policies and directory objects.
5.4.4
Policy Inheritance Example Note how inheritance works: 1.
In the Email Firewall main menu, select Directory.
2.
Click the All folder.
3.
Click the Internal folder.
4.
Click a domain record to open the Directory > Edit domain page which shows the Policies on this Domain tab.
5.4 How Email Firewall Applies Policies
237
5.4.5
5.
View the policies in effect for the domain.
6.
Note that the entries in the Origin column are All and All/Internal. All directory objects inside this folder will inherit each higher level folder’s policy set.
Policy Override Example Note how policy overrides work: 1.
In the Policies on this Domain tab, find the Chainmail Block policy.
2.
Note that in the State column beside the policy, the policy is listed as Enabled.
3.
In the Action column beside the policy, click Disable.
4.
Note the listing in the State column changes from Enabled to Disabled. The Chainmail Block policy will no longer be enforced for this domain.
5.
In the Action column beside the policy, click Enable to return the policy to enabled status.
6.
Verify that the listing in the State column changes from Disabled to Enabled. The Chainmail Block policy will again be enforced for this domain.
5.4.6
Preventing Policy Overrides Policies can be locked so that they cannot be disabled at lower levels. However, be careful when deciding whether to lock a policy. If you anticipate you may not want to apply the policy to specific users or groups of users, locking the policy may prevent this flexibility. For example, for the Inbound Size Deferral policy, you may want to defer large files until off-peak hours for most users, but want to allow them to be received by users who need access to large files at all times. If the policy is locked at a higher level, you will not be able to disable it at a lower level for those special users. Use locking only when you are confident that the policy should always be applied and that exceptions will not be granted. Otherwise, you will need to unlock the policy at the higher level if you later want to grant an exception.
238
Chapter 5: Understanding Policies
Note how policy overrides are prevented: 1.
In the Email Firewall main menu, select Directory.
2.
Click the All folder.
3.
Click Edit to open the Directory > Edit Folder page.
4.
In the Action column, note the Lock button.
5.
In the row beside the Virus Hoax Block, click Lock.
6.
Note that in the Action column in the row beside the Virus Hoax Block, the button changes to Unlock.
7.
Beside the All folder, click Open.
8.
Click the External folder.
9.
Click the Default domain icon to show the Policies on this Domain tab, and view the policies in effect for the domain.
10. Note the State column in the row beside the Virus Hoax Block now shows Enabled, Locked,
and there is no Disable button in that row.
The Virus Hoax Block policy can no longer be disabled at this lower level. 11. Navigate back to the All folder and click Edit. 12. In the Directory > Edit page, in the row beside the Virus Hoax Block, click Unlock.
13. Navigate back to the External folder, Default Domain. Note the Virus
Hoax Block row now shows the policy is Enabled (but not locked), and the Disable button now appears. If a policy has been disabled at a lower level and the policy is then removed at a higher level, the disabled policy is still shown at the lower level as disabled, and the lower level directory object becomes the owner of the policy.
5.4 How Email Firewall Applies Policies
239
5.5
General Policy Planning Considerations The following general concepts will help with planning your Email Firewall policies. You should also be familiar with the concepts explained in 5.4 How Email Firewall Applies Policies on page 233.
5.5.1
Inheritance Is From Parent Folders Only When planning policies and understanding how they will apply to users, an important concept to keep in mind is that User records only inherit from their parent folders. A user cannot inherit policies from a domain record, even if the email domain name for that user matches the domain in the domain record.
5.5.2
When to Use Sender Polices It is generally more efficient for the Email Firewall Policy Engine to evaluate sender-based policies because they only need to be considered once per message. On the other hand, recipient-based policies may need to be considered for each recipient for whom that policy is to be applied. Therefore, sender policies are generally more efficient than other policies, and usually can accomplish the same end. For example: • •
A Sender type policy applied to the External folder is more efficient than a Recipient type policy applied to the Internal folder. A Sender type policy applied to the Internal folder is more efficient than a Recipient type policy applied to the External folder.
There are some cases in which recipient policies may be required to achieve the desired effect. The Policy Engine minimizes the performance impact of
recipient policies by avoiding unnecessary reevaluation of previously determined policy conditions. As a result, in most cases, there is no noticeable performance impact of using a recipient policy.
240
Chapter 5: Understanding Policies
5.5.3
When to Use Recipient Policies When a transformative action is taken by a sender policy, that transformation must be applied such that all recipients get the modified message. When a transformative action is taken by a recipient policy, the Policy Engine must make sure that the recipient gets a copy of the message with only that recipient’s content modifications. Partitioning is required when different transformations need to be applied for different recipients. For example, if a recipient policy adds an annotation for one recipient but that policy does not apply to the others, there will be at least two partitions of the message (one with the annotation and one with no annotation.) Some transformative actions are part of the policy conditions; the success or failure of the action indicates what other actions should be taken. The creation of a clean copy of a virus infected message and the attachment stripping actions are examples of this. There are also transformative actions that are triggered as a result of a policy, such as adding an annotation to a message or altering the Subject header. There is one situation in which the use of a recipient-based policy is required. If you want the Policy Engine to partition (split apart) the message so that different recipients get different dispositions, you must use a recipient-based policy. An example of this is described in the next section.
5.5.4
Where To Apply Anti-spam Policies The discussion here assumes that you are using the default Email Firewall directory structure. • • •
There is a folder named All at the root with two subfolders, Internal and External. The default domain record is located somewhere beneath the External folder. There are domain records for each of your internal domains located somewhere beneath the Internal folder.
If you are using a recipient-based policy that is intended to block spam heading into your organization, the policy should be applied at the Internal folder. This means that the policy will be enforced for all recipients in your internal domains. Exemptions can be created by disabling the inheritance of that policy on records located beneath the Internal folder.
5.5 General Policy Planning Considerations
241
If you are using a sender-based policy that is intended to block spam heading into your organization, you could choose to apply the policy to the External folder. This makes sense if you assume that all spam messages will always have a reply address in an external domain. However, there are spammers who will spoof the reply address to use a mailbox in one of your internal domains, perhaps under the assumption that the message is more likely to be opened by the recipient if it appears to be sent from an internal sender. The Policy Engine determines the message sender by looking at the reply address on the message (which is usually the message FROM: header.) Consequently, a spam message with a spoofed reply address will not be blocked by a sender policy deployed on the External folder. There are several alternative approaches to deal with spoofed reply addresses. •
•
•
•
One solution to this problem is to apply the sender-based anti-spam policy on the All folder instead of the External folder. This will have the effect of applying the policy to all messages that are inbound to your organization and outbound to the Internet. This may have the undesirable effect of blocking some email that is heading out of your organization to the Internet. A slight improvement is to create two policies with identical catch and exclude conditions. One policy should be placed on the External folder and the other should be placed on the Internal folder. These two policies can be written to take different actions (e.g. apply a different quarantine tag) when the anti-spam policy triggers for a sender in an external domain versus a sender in an internal domain. Implement a sender address validation strategy (see section 5.1) to block email with an invalid reply address within your internal domains. This will prevent a spammer from using a fictional return address within in your domains, but it will not prevent them from using a valid one. If you are keeping an address list of known spammer domain names, also known as a “black list,” you can create a recipient-based policy that will check for messages where the sender is on the black list and apply the policy to the Internal folder of your directory. This type of policy filter will check the SMTP sender address as well as the reply address. It is not uncommon for spam messages to have the spammer’s domain name in the SMTP sender address even when the reply address uses some other domain name (such as one of your internal domain names).
Configuring the inbound SMTP Relay to reject messages from external networks that use a sender address in your internal domain is not a solution to this problem. This is because the SMTP Relay makes its mail rejection decision based on the SMTP sender (envelope) address rather than on the reply address.
242
Chapter 5: Understanding Policies
Using a Recipient Policy for Spam Example Suppose you want to create an anti-spam policy that will quarantine all messages that include words from a word list. Suppose further that you know that there are some recipients in your organization who need to receive all email addressed to them as quickly as possible, so they need to be exempt from the policy. Table 5.2 illustrates different strategies for solving this problem and the effect of each. The behavior that is most commonly desired is listed in the last row of the table. Unfortunately, the technique to use to obtain that result is probably not obvious. The table attempts to make this technique more clear. Table 5.2: Policy Application Concepts for Multiple Recipients Type Of Policy Defined
Sender- or recipient based policy to drop, return, quarantine or detain the message.
How Users Are Exempted From What Happens If There Are Multiple The Policy Recipients On The Message?
Modify the policy to exclude messages where the message is sent to exempted recipients, who are listed on an address list.
If the message is sent to any address on the exempted user list, all recipients will receive the message (including the non-exempted recipients.)
Sender-based policy to Make sure that the policy is not drop, return, quarantine, applied to the exempted recipior detain the message. ents in the Email Firewall directory.
If the message is sent to at least one non-exempted recipient, no recipients will receive the message (because the sender’s disposition is more severe than the recipients’.)
Recipient-based policy to drop, return, quarantine, or detain the message.
If the message is sent to exempted users and non-exempted users, the message is partitioned so that the exempted recipients get the message, but the others do not.
5.5.5
Make sure that the policy is not applied to the exempted recipients in the Email Firewall directory.
Use Directory Folder Policies Whenever Possible There are three basic ways to use policies to block messages from specific users or domains. These include: • • •
policy applied directly to the user or domain record. policy that uses an address list containing addresses of the specific user or domain, applied to a folder. policy applied to a folder that contains the user and domain records for the specific users or domains. 5.5 General Policy Planning Considerations
243
Of the three, policies applied to Directory folders are usually the most efficient. When planning policies, use policies applied to folders whenever possible. For example, you could have a Recipient type spam-blocking policy defined at the domain level that scans for all messages going to your domain, from an address list with six “bad” domains. And this policy would work. However, every time the Policy Engine encountered any message, it would have to check the message against all the addresses on that address list. A better way to accomplish the intended effect would be to use a Directory level policy such as the following: 1.
Create a Block folder under the External folder.
2.
Create directory objects for all “bad sender” domains or users (spammers) as domain or user records in the Block folder.
3.
Create a Sender type policy that blocks ALL messages coming from “this user.”
4.
Apply the policy to the Block folder.
Blocking spam this way accomplishes two things: • •
244
Only messages coming from spammers are scanned by the spammer policy. By keeping the scan rate down, you improve efficiency. You have created a sender policy instead of a recipient policy. By doing so, only one sender email address is analyzed, instead of multiple recipient email addresses. Again, you have improved efficiency.
Chapter 5: Understanding Policies
5.6
Default Policies and Folders This section describes the default Email Firewall policies and context in which applied. These policies provide protection against commonly encountered problems such as spam, large attachments and viruses, and are available during Email Firewall installation. You can always create new policies, or modify and rename the default policies, to fit the specific needs of your organization. To view the installed policies, click Policies in the Email Firewall main menu. To see where a particular policy is applied in the Email Firewall Directory, click the policy name link to open the Policies > Summary page, then click Show Where Used.
5.6.1
General Rules About Policy Application Following are some general rules to keep in mind when adding to, editing, enabling and disabling, and removing policies from directory objects. • • • • •
•
•
A policy can be locked, unlocked, and removed only in the directory entry where it was added. A policy can be disabled in any directory entry inheriting that policy unless it was locked in the entry where it was added. A policy can be disabled in a higher directory entry but enabled at a lower entry. A policy removed from a higher directory entry is removed from all lower directory entries to which it applied, unless it is disabled at a lower entry. A policy removed from a higher directory, if previously disabled from a lower level, will still show as applied to the lower entry, but the lower entry becomes the owner of the policy. A policy can be edited only from the Policies > Edit page. This page can be accessed from any directory entry to which it applies, and a policy edit performed from any directory entry changes that policy in every directory entry to which the policy applies. The same policy (from the global policy list) can be applied at multiple places in the Directory.
5.6 Default Policies and Folders
245
5.6.2
Policies Applied to the All Folder Policies applied to the All folder are inherited by all subfolders, domain records, and user records under it in the Email Firewall Directory. The All folder can contain policies that apply to all inbound and outbound mail traffic in your organization. When using policies at this level, keep in mind the general rules set out in 5.6.1 General Rules About Policy Application. Figure 5.9 shows the default policies that apply to the All folder. Figure 5.9: Email Firewall Policies Applied to the All Folder
Decompression Errors This sender policy detects attachments on outgoing messages that failed to be decompressed by the Email Firewall decompression libraries. These messages are quarantined with the tag Decompression errors.
Decomposition Errors This sender policy detects all MIME parts, including text/plain and text/html, in outgoing messages that could not be processed correctly by the Email Firewall
246
Chapter 5: Understanding Policies
text-extraction and type-identification libraries. These messages are processed normally.
Partial Message Block Tumbleweed has provided Partial Message Block as a default policy, and highly recommends using it, to block any message that attempts to use the message/partial MIME type. This sender policy checks the MIME type of messages and quarantines the message with the tag Partial Message. The partial MIME subtype allows large messages to be sent as multiple separate entities that are reassembled into a single message at the endpoint or email client. Email Firewall does not attempt to capture each partial message and assemble it into a single message to apply policies; instead, it applies policies to each partial message as a distinct, individual, message. The result is that a message as reassembled by the client may appear as though Email Firewall should have detected, and perhaps blocked, its delivery. For example, a policy to block messages greater than 6MB will not be triggered if the message is sent as three separate 2MB messages using the message/partial MIME type. However, when reassembled by the email client, the message may in fact be 6MB in size. Other examples include messages where a search phrase is split across multiple messages; keyword weighting is used but the keywords are spread across multiple messages; and perhaps even viruses where the virus signature is broken at the point where the data is divided for the multiple messages. Policy exceptions may also fail to be recognized for these same reasons. Some email clients in widespread use have configuration settings that allow the desktop user to set the threshold at which an email message will be split into multiple messages using multipart/partial. This means that the ability to generate such messages is well within the means of an ordinary user. Because of its potential ease of use, the security risk associated with this MIME type should not be considered trivial.
Virus Hoax Block This sender policy checks the body and subject line of messages from any domain against a default list of virus hoax keywords. Messages containing any of the keywords are quarantined with the tag Hoax.
5.6 Default Policies and Folders
247
5.6.3
Additional Policies Applied to the External Folder The External folder contains the default (*) domain record, which inherits all policies applied to the External folder. Policies applied to the External folder generally apply to users outside your organization who do not have a record in the Email Firewall Directory (or who are not part of your internal domains). When using policies at this level, keep in mind the general rules set out in 5.6.1 General Rules About Policy Application on page 245. The objects in the default External folder are subject all the policies that apply to the default All folder, as well as to the following policy:
Outbound Size Deferral This recipient policy defers delivery of internal-to-external or external-toexternal messages larger than 10MB until off-peak hours and notifies senders of the hold. By default, peak hours are 8:00 A.M. to 5:00 P.M., Monday through Friday, but peak hours can be modified in the Set Up > Policies page. See 2.7.1 Setting Up Peak Time for Policy Actions on page 87 for information on defining peak time.
5.6.4
Additional Policies Applied to the Internal Folder The Internal folder contains the mail domain record(s) for your organization, which inherit all the default policies described below. Policies applied to the Internal folder generally apply to all users in your domain.
248
Chapter 5: Understanding Policies
Figure 5.10: Policies Applied to the Internal Folder
Figure 5.10 shows the default policies that apply to the Internal folder. These policies perform the following general actions: • • •
Prevent users from sending or receiving viruses, offensive material, or large attachments. Protect users from spam, unsolicited advertisements, or attachments with long file names (sometimes used to conceal viruses). Prevent users from sending sensitive material such as résumés or confidential information. 5.6 Default Policies and Folders
249
The objects in the default Internal folder are subject all the policies that apply to the default All folder (see 5.6.2 Policies Applied to the All Folder on page 246 for explanation of these policies), and are also subject to the following policies:
EXE Blocking This recipient policy detects incoming messages with executable attachments. It attempts to strip the attachment. If successful, the message is annotated, archived with the tag Executable, and then delivered. If unsuccessful, the message is quarantined with the tag Executable Not Stripped, and a notification is sent to the Email Firewall administrator. See A.2.5 All Supported Executable Files on page 647 for a list of the executable files included in the All Executable Files attachment list.
Inbound Size Deferral This recipient policy defers delivery of external-to-internal messages larger than 10MB until off-peak hours and notifies recipients of the hold. By default, peak hours are 8:00 A.M. to 5:00 P.M., Monday through Friday, but can be modified in the Set Up > Policies page. See 2.7.1 Setting Up Peak Time for Policy Actions on page 87 for information on defining peak time.
Infected Message (Recipient) This recipient policy detects viruses in incoming messages. If a virus is detected, the policy attempts to create and forward a clean copy of the message. If successful, an annotation is appended to the clean copy, the original infected message is quarantined with the tag Inbound Virus Cleaned, and notifications are sent to the Email Firewall administrator and to the sender. If unsuccessful, the infected message is quarantined with the tag Inbound Virus Not Cleaned, and notifications are sent to the Email Firewall administrator and to the sender.
Infected Message (Sender) This sender policy detects viruses in outgoing messages. If a virus is detected, the policy attempts to create and forward a clean copy of the message. If successful, an annotation is appended to the clean copy, the message is sent normally, and the original infected message is quarantined with the tag Outbound Virus, and notifications are sent to the Email Firewall administrator and to the sender.
250
Chapter 5: Understanding Policies
If the clean-copy action is unsuccessful, the infected message is quarantined with the tag Outbound Virus Not Cleaned, and notifications are sent to the Email Firewall administrator and to the sender.
Long Filename Quarantine This recipient policy checks attachments in incoming messages against a list of long file names. (A weakness in some email clients can allow executable code, such as a virus, to be placed at the end of a long file name.) It quarantines the message with the tag Longfilename.
Multimedia Attachments Deferral This recipient policy detects incoming messages that have multimedia attachments larger than 2MB. It defers message delivery until off-peak hours and notifies recipients of the hold. By default, peak hours are 8:00 A.M. to 5:00 P.M., Monday through Friday, but can be modified in the Set Up > Policies page. See 2.7.1 Setting Up Peak Time for Policy Actions on page 87 for information on defining peak time.
Outbound Message Archival If the Email Firewall Archive Service is installed and configured, this sender policy saves outgoing messages as .msg files (text files) with the tag Default. There is a special consideration to be aware of when configuring the global policy setup option for archiving, “Do not archive undelivered messages,” see 2.7.2 Setting Up Archive for Policy Actions on page 88. When this option is selected, if an archiving policy is set to archive the original or decomposed message and the message gets quarantined or detained, on release from the quarantine or detention queue the message is archived “as sent” and not original/decomposed as specified in the archiving policy.
Résumé Block This sender policy checks the content of outgoing messages against a list of known résumé keywords, each weighted with a numerical value. Messages with a cumulative value of at least 9 are quarantined with the tag Resume.
5.6 Default Policies and Folders
251
Sensitive Info Review This sender policy checks the body, subject line, and attachments of outgoing messages against a list of known sensitive information keywords. Messages containing any of the keywords are quarantined with the tag Secrets, and a notification is sent to the Email Firewall administrator.
5.6.5
HIPAA Compliance Policy This policy is provided to assist organizations that must comply with the Health Insurance Portability and Accountability Act of 1996 (HIPAA). The policy is a sender-based policy. It is not applied to the Email Firewall Directory by default, but can be added to the directory. Its purpose is to prevent inadvertent nonsecure sending of messages that contain confidential or sensitive health-related information and patient identifiers. In practice, it would be most useful if applied to the Internal folder. When applied to the Email Firewall directory, the policy is invoked when the entire message has a HIPAA lexicon score of at least 25. The HIPAA lexicon is a weighted word list installed with the Email Firewall program. Keep in mind that the HIPAA lexicon is only a starting point. You should review and edit the HIPAA word list to be sure that it meets the needs of your organization. For more information about word lists, see 6.2.2 Word Lists on page 258. If a message triggers the HIPAA Compliance policy, the policy action is to quarantine the message with the tag: HIPAA.
5.6.6
Dynamic Anti-spam Service Policies The following policies are provided for use with the Dynamic Anti-spam Service (DAS). For more information about DAS, see Chapter 7, Dynamic Anti-Spam Service.
Spam - DAS: Adult This sender policy detects messages containing the adult content message property added by DAS. If the adult content property is detected, the policy quarantines the message in the Default Quarantine queue and adds the Spam_Adult tag.
252
Chapter 5: Understanding Policies
Spam - DAS: High Confidence This sender policy detects messages containing the high confidence message property added by DAS. If the high confidence property is detected, the policy quarantines the message in the Default Quarantine queue and adds the Spam_High tag.
Spam - DAS: Moderate Confidence This sender policy detects messages containing the moderate confidence message property added by DAS. If the moderate confidence property is detected, the policy quarantines the message in the Default Quarantine queue and adds the Spam_Moderate tag.
5.7
Policy Building Tools Email Firewall provides a number of tools to use when creating or editing Email Firewall policies. These include: • • • • • •
Lists - word, attachments and address lists. Tags - quarantine and archive tags. Annotations - add text to messages. Notifications - SMTP messages sent to a specified recipient when a policy violation requires a notification action. Event IDs - to keep track of various types of policy violations. Text wildcards and regular expressions - used for text matching in Email Firewall policies.
For more information and instructions on using these building blocks in policies, see 6.1 Introduction to Policy Building on page 256.
5.7 Policy Building Tools
253
254
Chapter 5: Understanding Policies
6
Creating and Editing Policies
This chapter describes how to create effective Email Firewall policies that will protect your organization’s email communications. The information in this chapter builds on the information and procedures described in Chapter 5, Understanding Policies. For additional information and instructions on security type policies, see Chapter 8, Email Encryption and Authentication Overview and Chapter 9, Security Configuration. This chapter contains the following sections: 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12
Introduction to Policy Building .............................................. 256 Lists and Tags ......................................................................... 257 Annotations ............................................................................. 278 Notifications ........................................................................... 287 Using Events as Policy Actions .............................................. 295 Creating Policies .................................................................... 296 Applying the Policy to a Directory Object ............................. 301 Using Virus- and File-Stripping Policies ............................... 303 Policy Protection Against New Viruses .................................. 305 Using Headers Type Policies.................................................. 313 Using DAS Message Properties.............................................. 315 Troubleshooting Policy Enforcement ...................................... 324
Global Email Firewall policy settings for Peak Time, Archive, and other Options that apply to all Email Firewall policies that use any of these policy actions are configured in the Setup > Policies page. See 2.7 Setting Up Global Policy Settings on page 87.
255
6.1
Introduction to Policy Building Email Firewall provides a number of tools for creating and editing Email Firewall policies. Most tools are available directly from the Email Firewall main menu. These policy building tools include: •
• • • •
Lists - address, attachment, and word lists are used to specify conditions or
exceptions in a policy. You can customize the default lists included with your Email Firewall installation, or create customized lists that meet the specific needs of your organization. Tags - archive and queue tags are used in policies that specify an archive or send to queue action. Annotations - add text to specified outgoing messages. Notifications - are SMTP messages sent to a specified recipient when a policy violation requires a notification action. Events - keep track of specified policy violations.
The remainder of this chapter describes these tools and provides instructions and examples showing how to use them.
6.1.1
Using Multiple Policy Actions When creating a policy with more than one notification, tag or event, you must complete the selection of one action before selecting additional actions. Moving from page to page in a pop-up without saving changes deselects the items selected in the previous page. To avoid automatic de-selection, use the following procedure when creating policies that use multiple actions. To properly select multiple actions using multiple popup pages:
256
1.
In the Policy Action Options page, click Select Tags, Select Events, or Select Notifications.
2.
Select items in the page.
3.
Click Select Checked Tags, Select Checked Events, or Select Checked Notifications to close the pop-up dialog and implement your selection.
4.
Re-open the popup page and select items from the next page.
5.
Click Select Checked Tags, Select Checked Events, or Select Checked Notifications to close the pop-up dialog and add all items from both pop-up dialogs to the policy action.
Chapter 6: Creating and Editing Policies
6.2
Lists and Tags Address, attachment, word lists and tags are used to specify conditions or exceptions in a policy. Once these lists have been created, they can be used over and over again in any number of policies. Email Firewall provides a number of default lists that are used in some of the default policies. You can also use these lists in policies you create. Before using a default list, verify that the list is appropriate for your environment. Words that might be appropriate for one organization may not be appropriate for a different organization.
It is often useful to know where lists are used. The Show Where Used button in each list opens a new page containing a list of policies where the specific list is used. You can navigate to the policy edit pages from this list and modify or remove the list from the policy. If you modify a list, it is modified in every policy that uses the list.
This section contains the following topics: 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.2.10 6.2.8 6.2.9 6.2.11 6.2.12
Cautions on Using Text Wildcards in Lists ............................ 258 Word Lists ............................................................................... 258 Advanced Add, Character Sets and Lists ............................... 262 Using Regular Expressions in Word Lists .............................. 262 Creating a Word List Example ............................................... 263 Address Lists........................................................................... 265 Creating an Address List Example ......................................... 266 Exporting Lists ....................................................................... 273 Attachment Lists ..................................................................... 268 Creating an Attachment List Example.................................... 271 Tags......................................................................................... 274 Creating a New Tag Example ................................................. 275
6.2 Lists and Tags
257
6.2.1
Cautions on Using Text Wildcards in Lists The asterisk (*) and question mark (?) characters function as text wildcards when used for text matching in Email Firewall lists. They function somewhat differently in each type of list. • • •
6.2.2
For word lists, see Using Wildcards in Word Lists on page 259. For address lists, see Address Lists and Wildcards Caution on page 266. For attachment lists, see Using Advanced Add and Wildcards in Attachment Lists on page 270.
Word Lists Word Lists are used when creating policies that monitor message body text, message subjects and attachments. You can use specific words or phrases in lists, and you can also use Unix regular expressions to define and amplify word lists. For more information on how to use regular expressions, see 6.2.4 Using Regular Expressions in Word Lists on page 262 and Appendix C, Using Regular Expressions. Improperly formed word lists can impact performance. Therefore, entries in word lists are validated by Email Firewall when added to make sure all entries are properly formed before the Policy Engine begins to use them. If you use regular expressions, the syntax is checked to be sure it is a valid entry. If a word list entry is invalid, you must correct it before saving the list. You can also check your text file word lists before adding them to Email Firewall, using the Word List Tester utility. See 10.5 Using the Word List Tester on page 564 for more information. There are several options when creating word lists, in increasing order of complexity: •
•
258
To add just a few words to a list that will not change often, select and edit an existing list. You can modify the list by simply changing the weight of words already on the list, or add new words to the list. To use a short list specific to your organization that does not match well with an existing list (for example, you want a list that uses keyword weighting, and the default word list does not), create a new list using Email Firewall Web Admin. See 6.2.5 Creating a Word List Example on page 263.
Chapter 6: Creating and Editing Policies
•
For a longer list, create a word list using a text-editing program such as Notepad, and use Advanced Add to import the list as an Email Firewall word list.
Figure 6.1 shows the default word lists shipped with Email Firewall. Figure 6.1: Email Firewall Word Lists
Using Wildcards in Word Lists In Word List text searches, the asterisk (*) character matches zero or more instances of any character (A-Z, a-z, 0-9) in a word. It does not match white space or punctuation. For example, *boat matches tugboat, sailboat, and steamboat. The ? character matches any one character (A-Z, a-z, 0-9) in a word. For example, B?ll matches Ball, Bill, and Bull. It does not match white space or punctuation. You cannot escape text wildcards in text searches. If you need to search for either the * or ? character itself, use a regular expression. See Appendix C, Using Regular Expressions for more information on using regular expressions.
6.2 Lists and Tags
259
Word Lists and Wildcards Caution When defining text entries on a word list, excessive use of the wildcard asterisk character (*) should be avoided. In particular, it is highly recommended that you avoid using the asterisk wildcard character (*) at the start of a text entry. This may result in a significant increase in the time and space required for the Policy Engine to initialize its internal data structures. It is only necessary to start a text entry with * when you need to match all words that end with a particular suffix. If defining a phrase, it is not necessary to use the wildcard at the beginning. For example, if you want to search for the sequence of words “get rich quick”, there is no benefit to adding wildcards to your entry, like “* get rich quick *”. Similarly, if you want to search for the appearance of a domain name that might appear in a URL, just add “www.domain.com” without wildcards.When defining regular expressions, use of .* and .+ should be limited for the reasons described above. When creating a policy, multiple word lists can be selected. It is recommended that complex word lists be broken up into smaller word lists that will compile more quickly. This process should involve the use of the EMFWordListTester, which shows how long a work list takes to compile. See 10.5 Using the Word List Tester on page 564 for more information on using the tool. Expressions that will lead to large compilation times should be avoided, These include multiple entries of the type **. Testing shows that up to fourteen ** items can be used in a word list without compromising performance.
Word List Construction and Weighted Word List Syntax Some syntax tips for word list construction when using Advanced Add Option 1: Add multiple words or phrases and Option 2: Add words or phrases from a file: • •
• •
Words can be added to a word list as a single word or as a phrase. A phrase must be surrounded by double quotes if it contains a special character, for example, a comma, question mark, asterisk, or semi-colon. Example: “word, and more words”. When creating a weighted word list, add a comma and then a weight value as a whole integer after the word. Example: word,3. To add a phrase containing a comma and a number to a weighted word list, be sure the weight value is added outside the double quotes. Example: “word, 1, and more words”,3.
260
Chapter 6: Creating and Editing Policies
• •
If a word or phrase in a weighted word list is not followed by a comma and numerical value, the word or phrase is automatically given a weight of 1. Negative word weights can be used to lower the incidence of false positives. For example, if the word “sex” has a weight of 3, “sex education” can be added to the list with a weight of -3 to reduce the possibility of unintended messages triggering the policy. Similarly, “good experience” or “bad experience” could be added to the Resume word list with a negative weight.
Validating and Saving Word Lists Using Advanced Add There is some behavior that you should be aware of when creating word lists using Advanced Add Option 1: Add multiple words or phrases and Option 2: Add words or phrases from a file, to avoid unintentional results in your word lists. This behavior results from the way word list validation works. When using these options, when you click OK, the word list is validated, phrases that are valid are added to the list, and you are returned to the main Word List > Edit Word List page. There you will see the valid entries in the list. If all entries are valid, you must click Save to commit the word list to the database. If any entries were invalid, you should correct them before saving the list. This can be done two ways: • •
Make corrections in the Advanced Add page text field, and click OK. If they are now valid, click Save in the Word List > Edit Word List page. Cancel the word list in the Edit Word List page, correct the word list file, and upload the file again. When all word entries are valid, click Save in the Word List > Edit Word List page.
If you click Save before correcting the invalid words in the text field, the word list will not contain the invalid words. If you click Save before correcting the invalid words in the uploaded file, if you then correct the invalid words and upload the file again, all the valid words are added a second time.
6.2 Lists and Tags
261
6.2.3
Advanced Add, Character Sets and Lists When using the Advanced Add feature to import word list files, the character set used in the imported file should be UTF-8. This character set is normally supported by most common text editors. For example, when using Notepad, you can select to Save As, and in the Encoding heading, use the drop-down list to select UTF-8. If the file contains non-ASCII characters, these also can be uploaded and imported as long as the character set used in the file is UTF-8. If you obtained the word list file by exporting it from Email Firewall, it should Non-ASCII characters are letters that are not part of the English language alphabet and other symbols that do not have an encoding in the ASCII character set.
already use the UTF-8 encoding. If you are manually editing such word list files, remember to use the UTF-8 encoding when saving the file. For additional information about encoding and Email Firewall, see Appendix B, Code Set Support.
6.2.4
Using Regular Expressions in Word Lists Some syntax tips for using regular expressions in word lists when using Advanced Add Option 1: Add multiple words or phrases and Option 2: Add words or phrases from a file: •
• •
Regular expressions must be preceded by two asterisks (**) at the beginning of the line and should also be enclosed in double quotes. This is how Email Firewall recognizes and identifies the item as a regular expression. Example: "**regular.*expression" Word weight can be assigned to regular expressions by adding a comma followed by the weight. Example: "**regular.*expression", 5 Regular expressions containing a special character (comma, question mark, asterisk, semi-colon, double quotes, etc.) must be enclosed in double quotes. Example: "**regular.*expression "with" double quotes"
•
262
Using two or more asterisks (in the form *text*) in regular expressions may result in a significant increase in the time and space required for the Policy Engine to initialize its internal data structures.
Chapter 6: Creating and Editing Policies
See Appendix C, Using Regular Expressions for more information on how to use regular expressions
6.2.5
Creating a Word List Example In the left menu, click Word Lists to open the Word Lists page where you can create, modify, or delete lists of words or phrases. Following is an example of a word list that could be used as a “Company Sensitive List” word list. This list is used later in this chapter to create a “Company Sensitive List” policy designed to detect confidential or sensitive content in outbound messages. See 6.6 Creating Policies on page 296. There is a Sensitive Info Review policy shipped with Email Firewall that uses the Sensitive Info (un-weighted) word list. You may want to review this policy and word list as additional examples.
To illustrate a variety of word list creation options, in this example the word list uses the Advanced Add function to import an external file containing the words in the list, and uses keyword weighting.
Plan the New Word List First To avoid unnecessary impacts on performance, be careful when using asterisks in word lists. See Word Lists and Wildcards Caution on page 260 for more information. To plan the new word list: 1.
Consult with others in your organization as necessary and create a list of words or phrases that will invoke the policy.
2.
Decide whether the word list should use keyword weighting. Keyword weighting lets you assign a numerical value to each word or phrase. You then set a threshold, based on the accumulated value of the detected words, that invokes the policy when reached. You might decide, for example, that “ComDot.com” should have a value of 1 and “merger” a value of 5, and that a message with a weight of 6 or more invokes the policy. For this example, use keyword weighting.
6.2 Lists and Tags
263
3.
Type the list using a text editor such as Notepad. Type each word or phrase followed by a comma and the numerical value for the word or phrase weight (with no spaces), on a new line. The list should look something like this: Acme,1 ComDot.com,1 merger,5 partners,5 pending,2
4.
Save the file as a plain text file with UTF-8 encoding, in a convenient location.
Associate the External Word List and Create the List To create the new word list:
264
1.
On the Email Firewall main menu, click Word Lists to open the Words Lists page.
2.
In the Words List page, Word List column, type Company Sensitive List in the field as the name of the new word list.
3.
In the Type column, use the drop-down arrow to select Weighted.
4.
Click Create to open the Edit Word List page.
5.
Click Advanced Add to open the Advanced Add page.
6.
Scroll to the Option 2: Add words or phrases from a file tab.
7.
Click Browse to locate the file you created in Plan the New Word List First, select it and click Open to select it into the tab field, then click Add.
Chapter 6: Creating and Editing Policies
Or, type the path and file name in the field, and click Add. Figure 6.2: Creating a New Word List
8.
Verify the words in the list appear in the Word List page. (Click Edit in any row if you need to a word or phrase’s weight. After changing any weight, click OK. Click Save.
9.
Verify the new “Company Sensitive List” appears in the Word Lists page.
The new word list can now be used in a Company Sensitive List policy, or in any other Email Firewall policy.
6.2.6
Address Lists Address Lists are used to create policies that monitor messages with specific addresses or domains in the message header. The particular addresses that are matched by the Policy Engine are as follows: •
Sender-type policies are based on the RFC2822 From: address, or any of the following headers: From: Sender: Reply-To: Resent-From:
6.2 Lists and Tags
265
Resent-Sender: Resent-Reply-To:
•
Recipient-type policies are based on both the RFC2821 RCPT TO: and the RFC2822 To: and Cc: addresses.
These description assume you are familiar with the difference between the RFC 2821 SMTP addresses and the RFC 2822 display recipients. Review the Email Firewall 6.1 Installation and Upgrade Guide for background information.
Address Lists and Wildcards Caution Address Lists support the use of the asterisk (*) and question mark (?) characters as text wildcards. The * character matches zero or more instances of any character in an address, including whitespace characters. The ? character matches any single character. It does not match white space or punctuation. Separate addresses with a comma, semicolon, or return. Excessive use of wildcards in address lists may result in a significant increase in the time and space required for the Policy Engine to initialize its internal data structures. It is generally not necessary to use the wildcard character * on address list entries. If you want to match all addresses in a particular domain and in all subdomains of that domain, just specify the domain name like “domain.com”. You should only use entries like “*@domain.com” when you want to match addresses that specify domain.com, but not any subdomains. You should only specify “*.domain.com” when you want to match all addresses where a subdomain of domain.com is present.
6.2.7
Creating an Address List Example To add, modify, or delete lists of addresses or domains, in the left menu click Addresses to open the Address List page. Figure 6.3 shows a sample address list page showing a number of address lists that could be used in building a policy. To avoid unnecessary impacts on performance, be careful when using asterisks in address lists. See Address Lists and Wildcards Caution on page 266 for more information.
266
Chapter 6: Creating and Editing Policies
Following is an example of an address list that could be used as an “East Coast Partners” list designed to detect messages to specified east coast partners. Always use paragraph returns to separate addresses in an address list. Address lists in which individual addresses are separated by a space, comma ( , ) or semicolon ( ; ) are not imported properly.
To create the new East Coast Partner address list: 1.
In the left menu, click Addresses to open the Address Lists page.
2.
In the Address Lists page, Address List column, type East Coast Partners in the field as the name of the new address list.
3.
Click Create to open the Edit Address List page.
4.
In the Address column, type an address in the field. Use the full domain address, or use wildcards to widen the scope of the address.
5.
Click Add.
6.
To add more addresses, repeat the previous two steps until the address list is complete.
7.
Click Save.
8.
Verify the new address list appears in the Address List page.
The new address list can now be used in any policy created to detect messages to and from your company’s east coast partners.
6.2 Lists and Tags
267
If the list of east coast partners changes, or if an east coast partner changes its email address, select the list and click Edit to make changes the list. Figure 6.3: Address Lists
6.2.8
Attachment Lists Attachment Lists are used when creating policies that monitor messages based on the style or type of the attachment. Specification styles include File Name, File Type, Standard MIME Type and Custom MIME Type. When the specification style is File Type, you can select from a drop-down list of file types. To create, modify, or delete attachment lists, in the left menu, click Attachments to open the Attachment Lists page. Figure 6.4 shows the attachment lists installed with the default policies.
268
Chapter 6: Creating and Editing Policies
To review all the file types and file type groups recognized by Email Firewall, see File Types Scanned on page 639. Figure 6.4: Attachment Lists
Viewing File Types for Attachment Lists To view the file types you can select from: 1.
In the Email Firewall main menu, click Attachments.
2.
In the Attachment List field, type the name of an attachment list. For this procedure, type test, and click Create.
3.
In the Attachments > Edit Attachments page, use the Specification Style drop-down arrow and select File Type.
4.
In the Attachment Name or Type column, use the drop-down arrow to view the list of file types. See Figure 6.5. Use the scroll arrows to view all the file types.
5.
Click Cancel to escape without saving test.
6.2 Lists and Tags
269
Figure 6.5: Attachment File Types
See A.2 “All Supported” File Types on page 645 for a list of the file types included in the “All...” file types. See A.3 Groups on page 651 for a list of the files included in the groups listed here. You can also use Advanced Add to add attachment names and types from a plain text file, or to add attachments using existing attachment lists.
Using Advanced Add and Wildcards in Attachment Lists Attachment Lists Advanced Add supports use of the asterisk (*) and question mark (?) characters as text wildcards for filename matching. The * character matches zero or more instances of any character in a filename, including whitespace characters. The ? character matches any single character. It does not match white space or punctuation. Wildcards can also be used in MIME type specifiers on attachments lists.
Attachment Lists and Wildcards Caution Limit your use of wildcards when defining text entries on an attachment list. Excessive use of the asterisk wildcard character (*) should be avoided. In particular, it is highly recommended that you avoid using the asterisk wildcard
270
Chapter 6: Creating and Editing Policies
character at the start of a text entry, as this may result in a significant increase in the time and space required for the Policy Engine to initialize its internal data structures.
Special Considerations for File Names and File Types When you identify attachments by File Type rather than by File Name, the Policy Engine looks inside the file headers to determine the file type. If you want Email Firewall to handle attachments based on the named file extension, use the File Name specification rather than File Type. Catching attachments based on File Name rather than by File Type will catch any attachment with the designated file extension, even if the contents of the file are not really those of the type specified, i.e., the contents are not really those of an .exe or .com file. For example, the default Email Firewall EXE Blocking policy strips attachments based on the default file type All Executable Files. See EXE Blocking on page 250 for a complete description of this policy. The All Executable Files include .exe files (except very old DOS .exe formats), .dll files, most .com files, and .scr files. However, to catch absolutely all .exe files, you should create an additional policy that catches attachments based on file name *.exe. Similarly, to catch all .com files, you should create an additional policy that catches attachments based on file name *.com. For additional information on how Email Firewall recognizes and scans file types, see Appendix A, File Types Scanned.
6.2.9
Creating an Attachment List Example Following is an example of an attachment list that could be used as a “Company Spreadsheet” list. This list is designed to detect confidential or sensitive information in outbound messages with spreadsheet attachments. For this example, assume that two spreadsheet programs, Microsoft Excel and Lotus123, are used in your company’s accounting department, and you want to selectively screen for those spreadsheet file types. To create the new Company Spreadsheet attachment list: 1. 2.
In the left menu, click Attachments to open the Attachment Lists page. In the Attachment Lists page, Attachment List column, type Company in the field as the name of the new attachment list.
Spreadsheet
6.2 Lists and Tags
271
3. 4.
Click Create to open the Attachments > Edit Attachment List page. In the Specification Style column, use the drop-down arrow to select File Type.
5.
In the Attachment Name or Type column, use the drop-down arrow to show the list of available file types. For this example, scroll down to and select Microsoft Excel and click Add.
6.
In the Attachment Name or Type column, use the drop-down arrow again to show the list of available file types. Scroll down to and select Lotus123 and click Add. If you want to filter for all spreadsheet files, you can do so by selecting All spreadsheet files. If you make this selection, review Appendix A, File Types Scanned to see what file types are included in the All spreadsheet files category.
7.
Verify the attachments appear in the Company Spreadsheets Attachment List page. Figure 6.6shows what the page would look like after making these selections.
Figure 6.6: Adding File Types to an Attachment List
272
8.
Click Save.
9.
Verify the new “Company Spreadsheets” list appears in the Attachment Lists page.
Chapter 6: Creating and Editing Policies
The new attachment list can now be used in a Company Spreadsheets policy created to detect these types of spreadsheet files, or it can be used in any other Email Firewall policy.
6.2.10 Exporting Lists For any word list, attachment list or address list, you can export the list and save it as a text file. As with importing lists, the export character set used is UTF-8, the character set normally used by most common text editors. For this example we use the standard attachment list Multimedia Files and export a selection of those file types. To export files from the Multimedia Files attachment list: 1.
In the left menu, click Attachments to open the Attachment Lists page.
2.
In the Attachment Lists page, Attachment List column, click Multimedia Attachments to open the Multimedia Attachments list page.
3.
In the Specification Style column, mark the checkboxes beside the file types or file names you want to export. Figure 6.7 shows an example of a selection of files.
4.
Click Export Checked Attachments.
5.
In the File Download dialog, mark the Save this file to disk radio button and click OK.
6.
In the Save As dialog, specify where to save the file, and name the file. Use the .txt file extension. Then click Save.
7.
In the Download Complete dialog, click Close. (Or you can open the file immediately if you prefer.)
You can now use this text file version of the list when creating other attachment lists, such as when using Advanced Add to create a new attachment list.
6.2 Lists and Tags
273
Figure 6.7: Marking File Types and File Names for Export
6.2.11 Tags Tags are used when creating policies that specify an archive or queue action. You can create tags that tell you why a message was archived, or why it was sent to the queue. To add, modify, or delete tags, in the left menu, click Tags to open the Tags page. Figure 6.8 shows the Tags selection page. Tags are also used with the Personal Quarantine Manager feature. See 3.7.6 Setting Up QSN Access Restrictions on page 156.
274
Chapter 6: Creating and Editing Policies
The next section provides an example of a tag that could be used when a message violates a policy that uses the Company Spreadsheets attachment list. This list was created in the example in 6.2.9 Creating an Attachment List Example on page 271. The example tag created here is used to tag messages caught by a policy using the Company Spreadsheet attachment list. That policy specifies Quarantine as a policy action, and specifies adding this tag when a message violating the policy is caught.
6.2.12 Creating a New Tag Example To create the new Company Spreadsheet tag: 1.
In the left menu, click Tags to open the Tags page.
2.
In the Tag Type column, use the drop-down list to select Queue.
3.
In the Tag column, type Company Spreadsheet and click Create.
4.
Verify the Company Spreadsheet name now appears in the Tags list.
The new tag can now be used in a policy created to detect messages caught by the Company Spreadsheet attachment list, or by any other policy.
Tag text length is limited to 50 bytes.
6.2 Lists and Tags
275
Figure 6.8: Tags
276
Chapter 6: Creating and Editing Policies
Advanced Add for Tags Using the Advanced Add function, you can add multiple tags, or add tags from text files or application files like Word or Excel to create multiple tags. Files from applications like Word or Excel must be saved as a plain text file with UTF-8 encoding before import. For more information, see 6.2.3 Advanced Add, Character Sets and Lists on page 262. When adding tags from a file: • •
Archive tags must include the number 1 Queue tags must include the number 2
The number must be followed by a comma, and then the tag itself. There should be no spaces between the number, comma and word. A series of tag entries would resemble the following: 1,Default 1,Executable 2,Hoax 2,HIPAA
6.2 Lists and Tags
277
6.3
Annotations Annotations are used to inform an email recipient of something. Most email users have received messages that include an annotation. Most common are these: • • •
•
Liability disclaimers such as “All views expressed in this message are those of the individual sender.” Warning disclaimers such as “This Financial Corporation reserves the right to monitor and review the content of all email communications.” Confidentiality statements such as “The following message may be protected by the attorney-client privilege or other applicable privilege under the law.” Assurances that your email is scanned and free of viruses.
You might want to create a policy that adds an annotation to outgoing messages. By selecting Annotation as a policy action when creating policies, this type of text can be included. An annotation can be added in-line as part of the message, or added as an attachment. Email Firewall provides several default annotations for common policy actions such as when an executable attachment is stripped, when an inbound virus is detected, and when an inbound virus is detected and stripped from a message. Once an annotation is created it can be used by any policy that allows annotation as a policy action. If an annotation is subsequently modified, it is modified for all policies that specify that annotation as a policy action. To view, add, modify, or delete annotations, in the left menu click Annotations to open the Annotations page. Annotations can also be accessed when creating many policy types, in the Policies > Edit Actions page. Figure 6.9 shows some sample annotations.
278
Chapter 6: Creating and Editing Policies
Figure 6.9: Annotations in Policy Actions
6.3.1
Global Settings for In-line Annotations When a message triggers a policy with a policy action to annotate the message, the global settings for in-line annotations determine the preface and epilog text that will surround each in-line annotation. When selecting annotation as a policy action, you can specify whether the annotation should be added in-line and immediately preceding the policy-specific annotation (preface), or immediately following the policy-specific annotation (epilog), or both. Email Firewall provides a default in-line preface global annotation that alerts recipients that an annotation was added.This annotation identifies the server that made the annotation, and the date the action occurred. Figure 6.10 shows the default global annotation in-line settings options.You can modify this message to customize it for your organization. Or, you can choose not to provide any information about the annotation’s origin, by leaving the global annotation fields empty. To view or modify the global in-line annotation text, in the left menu click Annotations and scroll down to the In-Line Annotations Settings tab.
6.3 Annotations
279
Figure 6.10: In-line Annotation Settings Options
Using Placeholders in Global In-line Annotations You can use placeholders in the preface and epilog of the global annotation. Table 6.1 lists the global annotation placeholders and what they invoke. You can use either upper or lower case in the placeholder text. Table 6.1: Global Annotation Placeholders
280
Placeholder
Will Be Replaced With
$SERVER
The server name
$DATE
The date and time the message was processed
Chapter 6: Creating and Editing Policies
6.3.2
Using Placeholders in Policy Annotation Text You can use placeholders in the text of any policy annotation. The placeholders that can be used in annotation text are shown in Table 6.2. You can use upper or lower case. Table 6.2: Annotation Text Placeholders Placeholder
Will Be Replaced With
$DATE
The date and time the message was processed
$SUBJECT
The subject of the message that triggered the policy
$POLICY
The name of the policy that was triggered
$RECIPIENTS
The RFC 2821 (SMTP envelope) recipients of the original message, including BCC recipients
$SENDER
The RFC 2821 (SMTP envelope) sender of the original message
$SIZE
The size of the original message
$SERVER
The Email Firewall server name
$ATTACHMENTS The names of the attachments contained in the original message
6.3.3
$REASON
The reason the policy fired
$MESSAGE_ID
The ID of the message
Skipping Annotation Text Annotations are added to a message after text scanning is completed. The skip option applies to messages previously annotated by Email Firewall that are then received by Email Firewall, for example, when a message previously annotated by Email Firewall is received in a reply message. The skip option does not apply to new annotations currently being added to the original message-in-process. When creating annotations you can choose whether the Email Firewall Policy Engine should skip the annotation text when scanning messages. If annotation text is not skipped, annotation words are scanned along with the original message. If you have policies that scan for specific words, words in your
6.3 Annotations
281
annotation could inadvertently trigger a policy that would not have been triggered but for the annotation. However, annotations, including disclaimer annotations, are ignored (skipped) by content scanning policies only in the calculation of keyword-weighted lists. To skip a disclaimer using an un-weighted list, convert the un-weighted list to a weighted list, make the list keyword weighted with a value of 1 for each word, then set the policy to trigger on a score of 1. Then use the new weighted list in the policy. For example, you might create an annotation similar to the following: The information in this message contains confidential sensitive company information about a pending merger and is not to be distributed outside our organization’s executive management team.
If you also had a policy, such as the “Company Sensitive” policy created in the examples in 6.6 Creating Policies on page 296, which uses a weighted word list that contains the words “merger” and “confidential,” then your annotation text would match the words “merger” and “confidential” on the Company Sensitive word list. In this case, the annotation words together with the message text could trigger the Company Sensitive policy in circumstances where the message text alone might not.
6.3.4
Annotating All Outbound Mail with a Disclaimer The following example illustrates how one organization defined a policy to annotate all Outbound mail with a disclaimer. This example assumes the organization’s email users or internal email domains have been added to the Internal folder of the Email Firewall policy hierarchy. It includes the following basic steps:
282
1.
Plan the policy before starting. When creating a policy that will specify an annotation as a policy action, plan the annotation as well, even if you are going to create the annotation on-the-fly while creating the policy.
2.
Create the Outbound Disclaimer annotation.
3.
Create the Outbound Disclaimer policy using the new annotation as a policy action.
4.
Apply the new policy to the Internal folder of the Email Firewall policy hierarchy.
5.
Test the new policy to be sure it works as intended.
Chapter 6: Creating and Editing Policies
Plan the Outbound Disclaimer Policy In this example, the organization decided that its policy should read as follows: Policy Name: Outbound Disclaimer Annotation Policy Type: Basic Mail Filtering Applies to: Sender Take the following actions... Deliver normally
and Append the annotation “Outbound Disclaimer”
They decided the text of the Outbound Disclaimer annotation should read as follows: The opinions expressed in this message are the opinions solely of the author, and do not represent the opinions or positions of the author’s organization.
They decided that they would want the Email Firewall Policy Engine to Skip the annotation text when scanning for policy violations, to avoid unintentionally triggering other Email Firewall word-scanning policies. They decided the annotation should appear as an Information type, to indicate the intent of the annotation. They also decided that the annotation should be an in-line annotation, appearing of the original message.
inline at bottom
6.3 Annotations
283
Create the Outbound Disclaimer Annotation To create the Outbound Disclaimer Annotation: 1.
In the Email Firewall main menu, click Annotations to open the Annotations page.
Figure 6.11: Annotations
2.
For this example, in the Annotation column field, type Outbound Disclaimer as the name of the new annotation. Use the drop-down arrow for Select Not Skip/Skip. Select Skip, so the Email Firewall Policy Engine will overlook the words in the Outbound Disclaimer annotation when scanning for policy violations in policies that use weighted word lists.
284
3.
Click Create to open the Annotations > Edit Annotations page. (Because you selected Skip, the checkbox beside Skip this text during any scan for words or phrases is marked.)
4.
In the Text field, type the annotation text you want to appear. Click Save to commit the new annotation to the database.
5.
Verify that the new Outbound Disclaimer annotation appears in the Annotations page list.
6.
Review the information in the In-Line Annotation Settings tab. Any text in the global annotation Preface and Epilog fields will appear in all messages using an in-line annotation as a policy action. See 6.3.1 Global Settings for In-line Annotations on page 279 for more information.
Chapter 6: Creating and Editing Policies
Create the Outbound Disclaimer Policy Create the Outbound Disclaimer policy: 1.
In the Email Firewall main menu, click Policies to open the Policies page.
2.
In the Policy column field, type Outbound Disclaimer and click Create to open the Policies page.
3.
Verify the name of the new policy appears in the Policies page Policy Name field.
4.
In the Category column, Basic row, verify the Applies To column indicates Sender.
5.
Click Create to open the Policies > Edit Catch Conditions page.
6.
Click Action to open the Policies > Edit Actions page.
7.
Under the Annotate heading, mark the checkbox and click Select Annotation to open the Select Annotations to Add page.
8.
In the Select Annotations page: 8a. Mark the Outbound Disclaimer checkbox. (Note that Skip appears
in the Skip column, indicating that the annotation text will be skipped when Email Firewall is processing messages with this annotation.) 8b. In the Type column, use the drop down arrow to select Information or Alert; for this example, select Information. 8c. In the Method column, use the drop-down arrow to select where the annotation will be placed: as Attachment, inline at Top, or inline at Bottom; for this example, select inline at Bottom. By selecting an inline option, global annotation Preface and Epilog text will also appear in the annotated message. 8d. Click Add Checked Annotations. 9.
Click Summary to view the policy, and then click Save to commit the new Outbound Disclaimer policy to the database.
10. In the Email Firewall main menu, click Policies to verify the Outbound Disclaimer
policy appears in the Policies page list.
Apply the New Disclaimer Policy to the Policy Hierarchy To apply the new policy to the Internal folder: 1.
On the Email Firewall main menu, click Directory to open the Directory page.
2.
Click the All folder and then the Internal folder. 6.3 Annotations
285
3.
Click Edit beside the Internal Folder to open the Directory > Edit Folder page. From here, you can apply the Outbound Disclaimer policy to the Internal folder and all its objects.
4.
On the Policies on this folder tab, Action column, click Add Policy to open the Select Policies page.
5.
In the Select Policies page, mark the Outbound Disclaimer checkbox and click Add Checked Policies.
6.
Verify the new Outbound Disclaimer policy appears on the Policies on this tab.
folder
Test the New Policy To test the policy:
286
1.
Open your email client and create a new message.
2.
Send the message to yourself (assuming that your email will be routed through Email Firewall).
3.
Check your email Inbox and read the message you sent. Verify it has the Outbound Disclaimer annotation in the message.
Chapter 6: Creating and Editing Policies
6.4
Notifications A notification is an SMTP message sent to a specified recipient when a policy violation specifies a notification action. For example, you may want an administrator to be informed when a certain policy is violated. You may also want to inform the sender or recipient of a message that the message violated the organization’s email policy. Figure 6.12 shows a list of the default notifications installed when Email Firewall is installed. Figure 6.12: Notifications
6.4 Notifications
287
You can create a variety of notifications to be sent when policies are violated. To view, add, modify or delete notifications, on the Email Firewall main menu, click Notifications to open the Notifications page. Notifications can also be accessed when you are creating many policy types.
6.4.1
Global Notification Settings Global notification settings are used whenever a notification action is required by a policy and a custom notification is not specified. See Figure 6.13. Figure 6.13: Global Notifications Settings
288
Chapter 6: Creating and Editing Policies
When a notification is sent, Email Firewall will use the default values specified in the Notifications page Global Notification Settings tab unless you specify different text.
Notification Routing Critical notifications can be sent using an alternate host and port in the event the Email Firewall Relay is down or the Outbound queue is backlogged or not processing messages. To enable the Notification Routing option: 1.
Mark the Send critical notifications via alternate SMTP Host checkbox.
2.
Enter the Alternate SMTP Host Name in the field.
3.
Enter the Port Number on which the alternate SMTP host connects to Email Firewall.
4.
Click Save.
Default Global Notification Settings The information specified in the Global Notification Settings tab is used whenever a notification action is required by a policy action and a custom notification is not specified. When the notification is sent, the default values specified here are used. To change the default Global Notification Settings: 1.
To change the default “sender” of an Email Firewall notification, modify the text in the Notification Sender User Name and Notification Sender Email Address fields.
2.
To change the default subject of an Email Firewall notification, modify the text in the Notification Subject field.
3.
The change who the “Administrator” in policies refers to, modify the text in the Administrator User Name field and specify the Administrator Email Address at which the Administrator can be contacted by email.
4.
Click Save.
Instead of having these default global notification settings used in policies, you can create custom notifications to be used by a policy when that policy is violated. See 6.4.2 Creating a New Notification for a Policy Action on page 290. Multiple policies can use the same Notification.
6.4 Notifications
289
If you modify a notification, it is changed for all policies that use that notification.
Email Firewall Web Admin displays the SMTP address (RFC 2821) sender/recipient address (envelope address) and not the MIME (RFC 2822) sender/recipient address when notifications are placed in an Email Firewall queue. You should keep this distinction in mind when creating notifications and when using them as policy actions. See the Email Firewall 6.1 Installation and Upgrade Guide for more detailed information about RFC 2821 and RFC 2822 address definitions.
6.4.2
Creating a New Notification for a Policy Action The following procedure describes how to create a custom notification that can be used when a policy action is to send a notification. This example could be used in the Company Sensitive List policy example described in 6.6 Creating Policies on page 296, designed to detect confidential or sensitive content in outbound messages. To create the notification: 1.
In the Email Firewall main menu, click Notifications to open the Notifications page.
2.
In the Notification column field, type Company Sensitive List. Notification text length is limited to 2,000 characters. An error message will display if this limit is exceeded.
290
3.
Click Create to open the Notifications > Edit Notification page.
4.
In the Subject field, type the subject of the notification. Email Firewall Notification appears in the field by default, but you can customize the subject to be more descriptive. For this example, type Company Sensitive List Violation Notification.
Chapter 6: Creating and Editing Policies
5.
Type the text of your notification message in the Text field. Note that you can use placeholders in the message. Table 6.3 lists the notification placeholders and what they invoke. You can use either upper or lower case.
Table 6.3: Notification Placeholders Placeholder
Will Be Replaced With
$DATE
The date and time the message was processed
$SUBJECT
The subject of the message that triggered the policy
$POLICY
The name of the policy that was triggered
$RECIPIENTS
The RFC 2821 (SMTP envelope) recipients of the original message, including BCC recipients
$SENDER
The RFC 2821 (SMTP envelope) sender of the original message
$SIZE
The size of the original message
$SERVER
The name of the Email Firewall server that sent the notification
$ATTACHMENTS The names of the attachments contained in the original message $REASON
The reason the policy fired
$MESSAGE_ID
The ID of the message
6.
In the Send To heading, indicate to whom you want the notification sent. In this case, mark the Original Message Sender radio button. When the Send To notification option selected is Original Message Content Recipients, the Policy Engine interprets this to mean all of the recipients on the TO: and CC: headers in the MIME message. By definition, the BCC: recipients are not visible in these headers and so the notification is not sent to them.
7.
In the Send From heading, indicate from whom you want the notification sent. For this example, mark the Administrator radio button.
8.
Mark the checkboxes provided for the Options heading as shown in Figure 6.14.
6.4 Notifications
291
Figure 6.14: Notification Options
9.
Click Save.
10. Verify the Company Sensitive List notification appears in the Notifications
page.
Avoiding Duplicate Notifications A single message may trigger multiple policies. If the policy action in these policies includes sending a notification, then the notification recipient could receive duplicate notifications. To eliminate sending multiple notifications to the same recipient, the Notification option Eliminate duplicate notifications; send only one copy per message processed should be enabled. This option is not a global option; you must set it for each notification. When this option is selected, the Policy Engine uses the sender information from the first of the triggered policies to determine the subject of the notification. The sender information considered by the Policy Engine is: • • •
292
sender name sender email address subject
Chapter 6: Creating and Editing Policies
Dropped or Returned Message Notification Option The Notification option Don't send this notification if the original message is dropped or returned by any policy is provided on the Notifications > Edit Notification page. If this option is enabled, a decision is made whether to send the notification based on the message disposition taken for the sender or recipient whose policy triggered the notification. The decision is not based on who is the intended recipient of the notification.
For a notification that is associated with a sender policy, the notification will be sent if none of the sender's policies drop or return the message, and if there is at least one recipient whose policies do not drop or return the message. So if the disposition taken for the sender is to drop or bounce, or the disposition taken for all recipients is to drop or bounce, the notification will not be sent. For a notification that is associated with a recipient policy, the notification will be sent if none of that particular recipient's policies drop or return the message, and if none of the sender's policies drop or return the message. For example: A message is sent to 2 recipients, A and B. Both A and B trigger a policy that will quarantine the message and send a notification to the administrator and a notification to the recipient. Both notifications have the option enabled to not send the notification if the message is dropped or returned by any policy. B also triggers a policy that drops the message. In this case, the administrator notification will be sent, and the recipient notification will be sent to recipient A. Recipient B will not receive a notification. If the message sender triggered a policy that returned or dropped the message, then the administrator notification will not be sent, nor will the recipient notification be sent to either A or B. The default setting of this option for all existing notifications is disabled.
Virus in Message Notification Option The Notification option Don't send this notification if EMF detected a virus in the message is provided on the Notifications > Edit Notification page. If this option is enabled, a decision is made whether to send the notification based on whether Email Firewall detected a virus.
6.4 Notifications
293
It is important to distinguish between Email Firewall detecting a virus and a virus being present in the original message. If an infected attachment is removed by a file attachment stripping policy, then Email Firewall will not detect the virus and the notification may still be sent. There is an existing notification option to attach the processed message to the notification. This has lead to problems with infected messages. The new option described here will allow the administrator to solve this problem by specifying that the notification should not be sent if Email Firewall detected a virus. Currently the option to attach the processed message to the notification will actually attach the original message to the notification. This new option will not prevent an infected message from being attached to the notification if the infected attachment was removed before virus scanning. However, there is an existing option available for file attachment stripping policies to specify that the policy should be applied after virus scanning policies. This option can be used to ensure Email Firewall does not fail to detect a virus in the original message due to the infected file being stripped. The default setting of this option for all existing notifications is disabled.
294
Chapter 6: Creating and Editing Policies
6.5
Using Events as Policy Actions Events are useful for tracking particular policy or policy type violations. You can use the same event for multiple policy violation actions, or create unique events for each policy violation. An event is identified by an ID number, and an event action can be added to most policies as a policy action. You can then use the event log to keep track of these types of policy violations. For instructions and information about Email Firewall global event setup, see Chapter 4, Working With the Event Log. Once set up, you can search for and sort policy action log events by ID number, severity, event level, and event description. For instructions on using the event log, see 4.2 Searching the Event Log on page 190. You might want to create a series of similar events for similar policy type violations. For example, you might want to create a 500-series of events for security policy violations, a 600-series of events for virus policy violations, and so forth. Then when you view the event log you can easily filter or sort the event log to show the similar events grouped in an easily reviewed order. For information and instructions on creating and using custom events, see 4.3.2 Creating Custom Events on page 194. To view, add, modify or delete Events, on the Email Firewall main menu, click Events to open the Events page. (Events can also be directly accessed when you
are creating many policy types.) Keep in mind that the global Event Log setup affects whether the Events you create for policy violations are displayed in the Event Log. For example, if your global Event Logging for the Policy Engine Logging Level is set to Major and you create an event with the logging level set to Normal, the Event will not be displayed in the Event Log even though the policy may have been violated. If the Policy Engine logging level is set to Normal, both Normal and Major events will be logged, but not Trace or Debug events. See 4.1 Setting Up Email Firewall Event Logging on page 186 and 4.1.2 Setting Up Logging Levels on page 187 for more information.
6.5 Using Events as Policy Actions
295
6.6
Creating Policies If you selected to install the default policies, you now have policies that are in place and being enforced. These policies have been defined to meet the security needs of most organizations, but they can be modified as desired to meet specific needs. You can also create new policies specifically for your organization. If you have installed Secure Redirect see the Secure Redirect Administrator’s Guide for instructions on setting up the Redirect service to use redirect as a policy action.
6.6.1
Viewing the Default Policies In the Email Firewall main menu, click Policies to open the Policies page. Figure 6.15 shows some of the default policies.
You can control how many rows appear on you browser page using the Preferences menu item.
All the default policies, as well as any policies you may have created after installation, are listed on the Policies page. Click any policy name link to open the Policies > Edit Summary page where you can review the complete policy. Or, if you know the name of the policy you want to view, type all or part of the policy name, then click Find to jump to the page with the policy name link.
Editing Default Policies to Scan HTML Tags If your organization uses the default policies and determines that it is important to scan HTML tags when scanning messages, you can modify the default policies. To do this, in the Edit Policies > Edit Catch Conditions page of each default policy, under the Message Scanning Options heading, mark the checkbox Scan within HTML tags when scanning message body content and attachments. Then click Save.
296
Chapter 6: Creating and Editing Policies
Figure 6.15: Default Email Firewall Policies
6.6 Creating Policies
297
6.6.2
Creating a New Policy Example In addition to modifying default policies, you will probably want to create new policies specific to your organization. This section describes how to create a new policy called “Company Sensitive List.” The Company Sensitive List example illustrates a policy intended to scan outbound messages for confidential information about a planned merger between two imaginary companies, Acme and ComDot.com. The policy is designed to detect confidential or sensitive content in outbound messages. In building this policy, you will rely on the steps previously described to create a new word list and a new notification. Assume you decide the policy should read as follows: Policy Name: Company Sensitive List Policy type: Basic Mail Filtering Applies to: Sender Catch messages where... The message text has a “Company Sensitive List” score of at least 6 Take the following actions... Quarantine the message with no tag and Send the notification “Company Sensitive List Violation Notification”
To create the new Company Sensitive List policy:
298
1.
Create the Company Sensitive List Violation Notification to be used as a policy action in the Company Sensitive List policy. See 6.4.2 Creating a New Notification for a Policy Action on page 290.
2.
Create the Company Sensitive List word list to be used as a catch condition in the Company Sensitive List policy. See 6.2.5 Creating a Word List Example on page 263.
3.
Define the policy: In the Email Firewall main menu, click Policies to open the Policies page.
4.
In the Policy column, type Company Sensitive List and click Create. See Figure 6.16.
5.
In the Category column, Basic row, verify the Applies To column indicates Sender. Use the drop-down arrow if necessary to select Sender.
6.
Click Create to open the Policies > Edit Catch Conditions page.
Chapter 6: Creating and Editing Policies
7.
Under the Message Contains Words heading, mark the Subject or Body checkbox.
contains
Figure 6.16: Creating the New Policy
8.
Mark the Any words from list radio button.
9.
Click Select Word List.
10. In the Select Word List page, mark the Company Sensitive List radio
button, then click Select Chosen Word List. 11. Mark the Total word weight at least checkbox and type 6 in the field, then
click OK. 12. Click Action to open the Policies > Edit Actions page. 13. Under the Deliver heading, mark the Quarantine radio button. 14. Under the Notify heading, mark the checkbox and then click select notifications
to open the Select Notifications to Add page.
15. Mark the Company Sensitive List checkbox, then click Select Checked Notifications.
16. Click Summary to view the policy you created. See Figure 6.17. 17. Click Save to commit the new policy to the database.
6.6 Creating Policies
299
Figure 6.17: Company Sensitive List Policy Summary
300
Chapter 6: Creating and Editing Policies
6.7
Applying the Policy to a Directory Object After a policy is created, you must apply it to a directory object. Using the policy created in the previous section, apply the policy to all outbound mail. To do this, you must apply the policy to all the users and domains in the Internal folder (or the folder where your internal domain record and internal user records are located). To apply the Company Sensitive List policy to the Internal folder and to all its objects: 1.
On the Email Firewall main menu, click Directory to open the Directory page.
2.
Click the All folder and then the Internal folder.
3.
Beside the Internal folder, click Edit to open the Directory > Edit Folder page.
4.
On the Policies on this Folder tab, click Add Policy.
5.
In the Select Policies page, mark the Company Sensitive List checkbox and click Add Checked Policies.
6.
Verify the new policy now shows on the Policies on this Folder tab.
7.
Click Lock if you do not want the policy to be disabled at a lower level. See 5.4.3 Understanding Policy Inheritance and Overrides on page 237 for information about the effects of locking, enabling and disabling policies.
To test the policy: 1.
Open your email client and create a new message.
2.
In the message body, type enough words from the Company Sensitive List to achieve the keyword threshold of 6 or more to trigger the policy.
3.
Send the message to yourself. (This assumes your email passes through Email Firewall.)
4.
In the Email Firewall main menu, click Quarantine to view the Quarantine queue and verify that the message was quarantined.
5.
Verify that a notification was sent to the mail administrator.
6.7 Applying the Policy to a Directory Object
301
6.7.1
Adding Policies to Directory Objects The previous section describes how to apply the example policy to the Directory. This section describes how to apply policies to directory objects in general. To add a policy to a directory object: 1.
On the Email Firewall main menu, click Directory to open the Directory page.
2.
Click the folders until the folder or directory object to which you want to apply the policy is displayed.
3.
In the Action column, click Edit to open the Directory > Edit page.
4.
On the Policies on this tab, click Add Policy.
5.
In the Select Policies pop-up page, in the Action column of the row of the policy you want to add, click Add. Or, to add multiple policies, mark the checkbox beside each policy you want to add, and click Add Checked Policies.
302
6.
Verify the new policy shows on the Policies on this tab.
7.
Optionally, to prevent the policy from being disabled at a lower level, click Lock. See 5.4.3 Understanding Policy Inheritance and Overrides on page 237 for more information.
Chapter 6: Creating and Editing Policies
6.8
Using Virus- and File-Stripping Policies This section gives a brief overview of the different behavior and application of the virus- and file-stripping policies. These are the available policies: •
•
6.8.1
For cleaning and stripping viruses detected on inbound or outbound messages, Email Firewall provides the following default Virus policies: • Infected Message (Recipient) • Infected Message (Sender) For stripping files that meet the conditions specified in a policy, Email Firewall provides the following policy: • File Attachment Stripping
How Virus-Stripping Policies Work The default (and recommended) behavior of the Infected Message virusstripping policies is as follows: 1.
Scan messages and detect viruses.
2.
Attempt to create a disinfected copy of an infected message without stripping attachments.
3.
If the virus cannot be removed, attempt to strip infected attachments.
4.
If cleaning or stripping is successful: 4a. Annotate the clean copy. 4b. Quarantine the original infected message with a tag noting that it
was cleaned. 4c. Send a notification to the sender and the mail administrator. 5.
If cleaning or stripping is unsuccessful: 5a. Quarantine the original infected message with a tag noting that it
was not cleaned. 5b. Send a notification to the sender and the mail administrator.
6.8 Using Virus- and File-Stripping Policies
303
6.8.2
How File-Stripping Policies Work File stripping, unlike virus stripping, does not result in a copy of the original message being sent. The original message itself, minus its attachment, is sent to the recipient. Therefore, it is not recommended that policy actions quarantine or drop messages from which files have been successfully stripped. If not successful, if you suspect that failure to strip a specified file attachment could result in damage to your organization, you could specify a quarantine or other disposition. There is an option to perform the file stripping after the virus scanning policies. See File Attachment Stripping on page 215 for details. The following is a sample file-stripping policy: Policy Name: Executable File Attachment Stripping Policy type: File Attachment Stripping Applies to: Recipient Catch messages where... Contains attachments in the attachment list “All executable files” Take the following actions... Remove those file attachments (post virus scanning) if successful, Deliver normally and Append the annotation “Executable Attachment(s) Stripped” otherwise Quarantine the message with the tag: “Executable Not Stripped”
304
Chapter 6: Creating and Editing Policies
6.9
Policy Protection Against New Viruses To provide the highest level of protection against new viruses, it is recommended that you keep the default configuration in the Virus policy scanning options to update the pattern files automatically. By default, they are updated on an hourly basis. See 2.6 Setting Up Anti-virus and Anti-spam on page 80 for instructions. However, if you discover a new virus before the virus pattern files have been updated, you can define a policy to filter on content or attachments, or enable file-stripping to significantly increase your organization’s resistance to the new virus.
6.9.1
Defining Content-Based Policies for Viruses Because new viruses appear at unpredictable intervals, you might receive a virus before the virus pattern files have been updated. To provide the highest level of protection against viruses that are so new that they are not yet recognized by the Policy Engine virus filter files, once you identify a new virus or have been warned about one, you can create a policy to protect against it. The Melissa virus, for example, was distributed as an attachment to a message with the subject line “An important message from .” The message body contained the text “Here is that document you asked for…don’t show anyone else :-).” This virus caused infected documents to be sent to the first 50 names in a user’s address book. Besides having the potential for unintentionally propagating confidential or sensitive information, the virus caused widespread performance problems with mail servers, especially at large sites. The following example illustrates how one organization defined a simple but effective policy to protect against the Melissa virus. The principles and procedures described here can be easily translated to similar contexts.
Creating the New Policy To create a new policy: 1.
Plan the policy before starting. The organization decided that the final policy should read as follows: Policy Name: Melissa Virus Policy Type: Basic Mail Filtering
6.9 Policy Protection Against New Viruses
305
Applies to: Recipient Catch messages where... The subject contains the phrase "an important message from" Take the following actions... Quarantine the message with the tag: "Melissa Virus" 2.
In the Email Firewall main menu, click Policies to open the Policies page.
3.
In the Policy column, type the name of the new policy in the field. For this example, type Melissa Virus.
4.
In the Action column, click Create to open the Policies page where you select the policy type. 4a. In the Basic row, Applies To column, use the drop-down arrow to
select Recipient. 4b. In the Action column, click Create to open the Policies > Edit
Catch Conditions page. 5.
In the Message contains words heading, mark the Subject contains checkbox. 5a. Use the drop-down arrow in the adjacent field and select this sequence of words.
5b. Verify the radio button beside the field is marked. 5c. In the adjacent field, type an important message from. 6.
At the top or bottom of the page, click Summary to open the Policies > Edit Summary page.
7.
Review the policy, then click Action to open the Policies > Edit Actions page.
8.
In the Policies > Edit Actions page, under the Deliver heading, mark the Quarantine with (select tags) radio button.
9.
Click select tags to open the Select Tags page. 9a. In the Tag column, type Melissa Virus in the field. 9b. In the Action column, click Create. 9c. In the Select tags page, locate your new Melissa Virus tag and
mark the checkbox beside it. See Figure 6.18. 9d. Click Select Checked Tags to close the page.
306
Chapter 6: Creating and Editing Policies
Figure 6.18: Selecting a Quarantine Tag
10. In the Policies > Edit Actions page, click Summary to open the Policies >
Edit Summary page. See Figure 6.19. 11. Review your policy, then click Save to commit the new policy to the
database and close the Policies > Edit Policies page. 12. In the Policies page, verify your new policy appears in the list of policies.
6.9 Policy Protection Against New Viruses
307
Figure 6.19: The Melissa Virus Policy summary
Applying the New Policy to the Directory To apply the policy to all users in your organization: 1.
In the Email Firewall main menu, click Directory to open the Directory page.
2.
Click the All folder and then the Internal folder (or click to the folder that holds your organization’s users if you have modified the Email Firewall default directory structure).
3.
Beside the Internal folder, click Edit to open the Directory > Edit Folder page.
4.
In the Policies on this folder tab, click Add Policy to open the Select Policies page.
5.
In the Select Policies page, locate the Melissa Virus policy, and in the Melissa Virus row, Action column, click Add. Or, in the Melissa Virus row, mark the checkbox beside the policy, and at the bottom of the page, click Add Checked Policies.
308
Chapter 6: Creating and Editing Policies
6.
In the Directory > Edit Folder page, verify the Melissa virus policy now appears in the Policies on this folder tab.
7.
In the Melissa Virus row, click Lock so that the policy cannot be disabled at a lower directory level.
Testing the New Policy To test the new policy: 1.
In your email program, compose a message addressed to yourself.
2.
In the subject field, type an important message from .
3.
Send the message.
4.
In the Email Firewall main menu, click Quarantine to open the Quarantine queue page.
5.
Review the messages in the queue and verify your message is quarantined with the correct tag.
6.
Click Delete in the Action column to remove the test file from your system.
The distinct nature of the message containing the virus made this policy easy to define. Policies will vary according to the nature of the virus that you want to prevent: you might instead scan message body or header text, a file attachment name, or an attachment type, for example. Tumbleweed posts information about new viruses on the Technical support Bulletin Update site as soon as that information is available. To receive bulletins about viruses, patches, and other Email Firewall issues, visit Tumbleweed’s support page at www.tumbleweed.com/support.
6.9 Policy Protection Against New Viruses
309
6.9.2
Using Policies to Detect HTML Mobile Code Email Firewall can detect HTML code with embedded scripts. Policies that filter for or strip attachments of a specific type can check for the presence of scripts embedded within HTML attachments. Simply use an attachment list that scans for HTML with active content. To create the HTML with Active Content attachment list: 1.
In the left menu, click Attachments.
2.
In the Attachment List field, type HTML with Active Content, then click Create.
3.
In the Attachments > Edit Attachment List page, Specification Style column, use the drop-down arrow to select File Type.
4.
In the Attachment Name or Type column, use the drop-down arrow to select HTML with Active Content as the file type.
5.
Click Add.
6.
Click Save.
You can now use this attachment list in a policy to filter for and strip HTML with active content.
Catching Script Tags Mobile code embedded in HTML-formatted email can also be detected using a basic mail filtering policy. To do so, create a policy designed to catch the tag within an HTML body. Because Java and VB scripts need to be embedded using this tag, filtering for this tag will catch these mobile code scripts. As a policy action, you can quarantine these messages for review, or simply drop them. When filtering for mobile code, Email Firewall does not attempt to determine whether the mobile code content is malicious. Such a policy will block all mobile code identified by the tag.
310
Chapter 6: Creating and Editing Policies
6.9.3
Troubleshooting Virus Protection Even when using well-formed virus detection policies there are several ways that a virus can enter your organization, either through a misconfigured Email Firewall server or through other channels. This section describes the different ways viruses can inadvertently be allowed to bypass Email Firewall security, and provides suggestions on how to stop them.
Common Ways Email Firewall is Misconfigured There are a number of ways a misconfigured Email Firewall server could allow viruses to pass. •
•
•
Virus Engine or Pattern Files are not current. Email Firewall provides both automatic and manual updates for virus pattern files. Pattern files can and should be updated automatically. You should monitor the Tumbleweed Support Bulletin for information on both virus engine updates and virus pattern updates, as well as for information on how to protect your organization from new viruses. See 2.6 Setting Up Anti-virus and Anti-spam on page 80. Virus Policies are incorrect. A common mistake when configuring virus policies is to specify a policy action that forwards a copy of the virus to a user. There are two ways this can occur. The most common is to specify as a policy action the forward a clean copy of the message option, and also to process the original message normally. This combination of options results in two copies of a message: one is a clean copy, and the other is the original infected copy. The recipient of the message will receive both copies, one of which includes the virus. The correct option here is to forward a clean copy and drop the original. Another common mistake is that the policy can be configured to send a notification, which can include the original message. The original message in this case contains the virus. The correct option when specifying a notification action in a virus policy is to mark the include message header only checkbox; as this will avoid sending new copies of a virus infected message to other recipients. A desktop virus scanner is being run on the Email Firewall server. Unless you follow the precautions listed in the Email Firewall 6.1 Installation and Upgrade Guide, section titled Eliminate Third-Party AntiVirus Software Risks, you should not run a desktop virus scanner on the
6.9 Policy Protection Against New Viruses
311
•
Email Firewall server. You should however continue to run a desktop virus scanner on the workstations within your organization. Bypassing Email Firewall using MX preferences or other routing issues. Another misconfiguration, although not a misconfiguration of Email Firewall, is allowing mail to be routed around the Email Firewall server. This can be done using DNS. For example, you might have two MX records for your organization, a 10 preference which would route mail to your Email Firewall server, and a 20 preference which would route mail to your internal group mail server (bypassing Email Firewall) if Email Firewall is busy or unavailable. Although this might sound like a good idea from a failover perspective, it opens up another potential route for viruses and other undesired content to enter your organization.
Other Channels for Virus Infiltration • Floppy disk, network file transfer, or Internet download. These are the obvious, non-email channels that can introduce viruses, and these are the main reasons you should continue to run virus scanning software on your users’ workstations. • Internet Mail such as Yahoo Mail, AOL Mail or HotMail. Many organizations allow access to Web-based email systems such as Yahoo Mail, AOL Mail, or HotMail. Retrieving email from these sources bypasses the Email Firewall server and therefore does not provide virus detection. • Users accessing personal POP or IMAP accounts over the Internet. Most email clients can be configured to retrieve email from personal POP or IMAP mailboxes on the Internet. This practice is very dangerous because it bypasses the Email Firewall server, and therefore email that is downloaded to the client is not scanned for viruses by the Email Firewall server. The best way to stop users from accessing external mailboxes is to block port 110 on your corporate firewall for POP and port 143 for IMAP. One primary line of defense against viruses that are inadvertently allowed to bypass the Email Firewall system is to run desktop virus scanners on the workstations within your organization. This additional measure will stop viruses introduced through the channels that bypass the Email Firewall system. For more information about viruses and the Email Firewall server, you can search the Tumbleweed online knowledge base using the keyword “virus.” The Tumbleweed Technical Forum is also a good outlet for questions and general discussions on virus-related issues.
312
Chapter 6: Creating and Editing Policies
6.10 Using Headers Type Policies Message headers display information that an organization may want to scan for in messages or may want to hide from external view. Policies can be created with a Catch condition to catch messages with specified headers. Once caught, those headers can be removed, or other actions can be specified. A Headers policy type requires: • • •
selecting a Header Field, either an existing field or by creating a custom field. specifying the Condition: exists, contains or is. specifying the Value of the header. For example, for the Content-Type header filed, the value could be text/plain.
The Header Field policy conditions only consider the message headers. In other words, they only consider the headers at the top of the message. They do not consider any MIME headers that are part of the inner content of the message. Basic Mail policies can also be created to add specified X-headers to messages as a policy Action. The following example illustrates a catch condition Headers Type policy which removes identifying information from message headers. To create a message Headers Catch protection policy: 1.
In the left menu, click Policies to open the Policies page.
2.
In the Policy column field, type a name for the policy.
3.
In the Action column, click Create.
4.
In the Policies page, scroll down to Headers category, and in the row beside the Headers policy type you want to create, use the drop-down list to select to whom the policy should apply and click Create.
5.
In the Policies > Edit Catch Conditions page, in the Message contains ANY headers in list heading, click (select header list) to open the Select header list page.
6.
In the Select Header List page, type a name for the header list and click Create.
7.
In the Edit Header List page, use the drop-down arrow to make your header-type selections from the header types provided. Or, mark the radio
6.10 Using Headers Type Policies
313
button beside the field and type a custom header name in the field provided. Then click Add. 8.
Repeat the previous step until you have added all the header types desired. Then click Save.
9.
In the Select Header List page, mark the radio button beside the Header List you just created, and click Select Chosen Header List.
10. If you want Email Firewall to scan the entire message body, be sure the Scan the message body for embedded headers
checkbox is marked.
11. If you are creating a Remove Host Names and Subdomains from MIME
Headers type policy, or a Normalize Email Addresses in MIME Headers type policy, in the which makes reference to ANY domains in list heading, click (select domain list) to open the Select Domain List page. 12. In the Select Domain List page, type a name for the domain list and click Create.
13. In the Edit Domain List page, type the domain name in the field provided,
and click Add. 14. Repeat the previous step until you have added all the domain names
desired, then click Save. 15. In the Select Domain List page, mark the radio button beside the Domain
List you just created, and click Select Chosen Domain List. 16. In the Policies > Edit Catch Conditions page, click OK. 17. In the Policies > Edit Summary page, click Actions. 18. In the Policies > Edit Actions page, select the action Email Firewall should
take if the MIME headers or domain names or email aliases cannot be removed (or renamed, in the case of the Normalize Email Addresses in MIME Headers policy), then click OK. 19. Click Summary to review the complete policy. If it is defined correctly,
click Save. 20. Apply the policy to the appropriate directory object(s).
314
Chapter 6: Creating and Editing Policies
6.11 Using DAS Message Properties When a message is processed by the Email Firewall Spam Analysis Engine and the message is identified as spam, the engine adds one or more DAS-specific message properties to the message. You can check for these properties using the default DAS policies, or create your own policies. A configuration option in the Dynamic Anti-spam Service setup also allows the Spam Analysis Engine to add DAS X-headers to messages. This option can be enabled in the Set Up > Dynamic Anti-spam Service Settings page, DAS Settings tab, Add spam categories as X-Headers to scanned messages. See 7.5.3 Upgrades, X-Headers and Message Properties on page 342. Another way of using the Spam Analysis Engine properties is to allow recipients to create their own customized spam filtering using email client features that detect the Spam Analysis Engine properties. This option requires that recipients are given information about the content of these properties. The Basic Mail Filtering policy type also provides a policy action option that allows you to create a policy that adds custom X-headers to messages. Creating custom X-headers can be useful in catching certain messages meeting the policy’s catch and exclude conditions. The remainder of this chapter assumes that the Email Firewall administrator intends to manage spam with the Dynamic Anti-spam Service, before it reaches internal recipients.
6.11.1 Default Dynamic Anti-spam Service Policies There are three default policies that filter messages based on the message properties added by the Spam Analysis Engine. • • •
Spam - DAS: Adult Spam - DAS: High Confidence Spam - DAS: Moderate Confidence
These policies need only be enabled on the correct Email Firewall Directory object to begin enforcing the DAS policies. See 6.11.4 Applying the Anti-spam Policy to the Directory on page 319. Additional policies can be created to filter messages based on other properties added by the Spam Analysis Engine.
6.11 Using DAS Message Properties
315
6.11.2 What a DAS Policy Should Look For You can create a policy that looks for the DAS message properties specified in the Policy > Edit Catch Conditions and Policy > Edit Exclude Conditions pages, Spam Indicators heading. See Figure 6.20. You can also create a policy that looks for the DAS X-MMS-Spam-Confidence and X-MMS-Content-Rating headers listed in the Header Field. See Figure 6.21. Figure 6.20: Selecting DAS Message Properties
Figure 6.21: X-Header Selections
316
Chapter 6: Creating and Editing Policies
The header field is displayed on the bottom of both the Policy > Edit Catch Conditions and Policy > Edit Exclude Conditions pages. See Figure 6.21. These DAS policy conditions can also be combined with other policy conditions to further fine-tune your anti-spam policies. For a more detailed discussion of the Spam Analysis Engine, review 7.4 How the Engine Processes Messages on page 337. For more information about the content and confidence ratings, see 7.5 Message Categorization on page 340.
DAS Message Properties Added There are three DAS properties for Message Content Ratings and two for Spam Confidence Indicators that policies can specify as Catch or Exclude conditions: Message Content Ratings: • • •
Adult Scam Broadcast
Spam Confidence Indicators: • •
High Moderate
These properties are added singly or in combination depending on the content of the message. Using these combinations of spam message properties, a message is classified into the following categories: • • •
Regular non-spam mail: No properties are added. Non-adult, non-scam, non-broadcast spam: Confidence properties are added. Adult, scam, or broadcast spam: Confidence and Content properties are added.
Given these matrices, any message identified as spam by the Spam Analysis Engine will have at least one property.
DAS Message X-headers Added If DAS is configured to add spam categories as X-headers, there are multiple combinations that can be added to a message. When adding DAS X-headers is enabled, the X-MMS-Spam-Filter-ID header is always added, even for non-spam messages.
6.11 Using DAS Message Properties
317
Thus, we have the following cases: • •
If DAS is not configured to add spam categories as X-headers, no spam Xheaders are added. If DAS is configured to add spam X-headers, each message will contain at least one X-header (X-MMS-Spam-Filter-ID). Spam messages will contain additional headers for spam rating and spam confidence. The following additional X-header combinations are possible:
1.
X-MMS-Spam-Confidence: high
2.
X-MMS-Spam-Confidence: moderate
3.
X-MMS-Spam-Confidence: high X-MMS-Content-Rating: adult
4.
X-MMS-Spam-Confidence: moderate X-MMS-Content-Rating: adult
5.
X-MMS-Spam-Confidence: high X-MMS-Content-Rating: broadcast
6.
X-MMS-Spam-Confidence: moderate X-MMS-Content-Rating: broadcast
7.
X-MMS-Spam-Confidence: high X-MMS-Content-Rating: scam
8.
X-MMS-Spam-Confidence: moderate X-MMS-Content-Rating: scam
Using these combinations of spam message properties, a message is classified into the following categories: • • •
Regular non-spam mail: Only the X-MMS-Spam-Filter-ID header is added. Non-adult, non-scam, non-broadcast spam: Confidence header is added. Adult, scam, or broadcast spam: Confidence and Content headers are added.
Acting on Spam Messages When creating policies to use with these properties and X-headers, different message dispositions (policy actions) can be chosen based on the severity and classification of the spam. See Actions on page 204. When considering which message disposition to use, keep in mind that spammers frequently use invalid or “spoofed” sender addresses. If the message disposition chosen is “Return Message to Sender” or “Notify the Sender” then the message will likely appear as an undeliverable message in the Dead Letter queue. Also, if the message is
318
Chapter 6: Creating and Editing Policies
deliverable and is returned to the spammer, then the Email Firewall Notifier address will be added to the spammer’s list. Other ideas to more effectively manage spam messages include: • • •
use the Quarantine action with a unique tag applied by each anti-spam policy to facilitate easy queue filtering in Web Admin. use the PQM to notify recipients about their quarantined spam messages. use queue aging to automatically remove messages from quarantine after a period of time.
6.11.3 Using the Broadcast Content Rating in Policies Unlike the adult and scam content ratings, which strongly indicate spam content, the broadcast content rating indicates a message that is probably legitimate, such as a newsletter or listserv message. These messages are considered non-spam even though they are sent (broadcast) to a very large mailing list. The availability of the broadcast content rating allows administrators to create policies that recognize and pass broadcast emails that might otherwise be categorized and blocked as spam. Administrators can still continue to block broadcast spam, but the broadcast content rating allows exceptions for legitimate newsletters and listservs. Email Firewall policies defined to block spam can use policy exceptions so that when the broadcast value is present in the message property or X-MMS-SpamContent header, the message disposition is to pass the message to the recipient, even though the message also contains a spam property and X-MMS-SpamConfidence header and confidence rating. See 6.11.6 Creating a Broadcast Exception Policy on page 321.
6.11.4 Applying the Anti-spam Policy to the Directory Like all policies, anti-spam policies must be applied to folders, domain records, or user records in the Email Firewall Directory in order to create the policy coverage and exception cases required by your organization. For this example, we assume that the organization would want to quarantine for review all adult-content messages. These messages contain business-
6.11 Using DAS Message Properties
319
inappropriate language. It is also assumed that the organization would want this policy applied to the All folder. Apply the policy to the appropriate directory object: 1.
In the Email Firewall main menu, click Directory.
2.
Click the All folder.
3.
Click Edit.
4.
In the Directory > Edit Folder page, click Add Policy.
5.
In the Add Policies page, mark the Adult content checkbox and click Add.
6.
In the Directory > Edit Folder page, verify the Adult content policy appears in the Policies on this folder tab.
6.11.5 Testing the Anti-spam Policy Once you have selected a policy that checks for the presence of a Spam Analysis Engine message property or X-header and applied the policy to an Email Firewall directory object, you should test the policy. One way to do this is to send an SMTP message addressed to a mailbox in your internal domain, sent from an external SMTP client if you have enabled the service to bypass internal messages. As explained in 7.4.2 Messages Not Analyzed by the Service on page 338, the Spam Analysis Engine can be configured to not analyze messages sent from internal networks. To perform this test, one option is to use a Web-based email account (e.g., Hotmail, Yahoo). Another option is to temporarily change the Email Firewall SMTP Relay's Network Connections table to designate a local IP address as an external host, and then send the mail directly to the Email Firewall SMTP Relay using an SMTP client (e.g., Outlook Express, Netscape Messenger) running on the local host. To test the Spam - DAS: Adult policy:
320
1.
Type $Adult_Content$ in the main body of your test message. This phrase is specially identified by the engine and will trigger the Anti-spam Content Adult property.
2.
Send the message to an Internal recipient.
Chapter 6: Creating and Editing Policies
Special Test Keywords for Testing an Anti-spam Policy Special test keywords can be used in conjunction with a policy that checks for the anti-spam Confidence or Content message properties or the X-MMS-SpamConfidence or X-MMS-Content-Rating headers, to verify that the SAE is operating properly. You must create a policy to look for the specific anti-spam property or X-header, and apply it to the correct Directory object to test. The text keywords to use in a message to trigger the catches are: • • •
X-MMS-Spam-Confidence: high:
$High_Confidence_Spam$ X-MMS-Content-Rating: adult: $Adult_Content$ X-MMS-Content-Rating: scam: $Scam_Content$
6.11.6 Creating a Broadcast Exception Policy This section provides an example of how to create a policy to catch, quarantine and tag messages that receive the moderate spam confidence rating, unless the message receives the broadcast content rating or the sender is on an address list called Approved Senders. This policy is intended to block spam messages but permit exceptions for legitimate newsletters or legitimate mass mailings. To create a broadcast exception policy: 1.
In the left menu, click Policies to open the Policies page.
2.
In the Action column, click Create.
3.
In the Policies Category and Policy Type selection page, Policy Name field, type a name for the policy. For this example, type Approved Broadcasts.
4.
In the Basic Category row, select Applies to Sender, then click Create.
5.
Scroll down to the Spam Indicators heading and under the Spam Confidence heading, mark the Moderate checkbox.
6.
Click Exclude to open the Policies > Edit Exclusion conditions page.
7.
Under the Sender heading, mark the Any sender or reply address on this message is checkbox. Leave the default value in.
8.
Click Select Address List.
9.
In the Select Address List pop-up, create an address list of approved broadcast email message senders. For this example, name the list Approved Broadcast Senders. (If such a list has already been created for other purposes, you could also select and edit it.)
6.11 Using DAS Message Properties
321
10. Add the addresses of senders whose messages might otherwise be tagged
as moderate or high confidence spam. Senders of broadcast newsletters and listservs are prime examples. 11. When the address list is created, select it and click Select Chosen Address List.
12. Scroll down to the Spam Indicators heading and under the Message Content Rating
heading, mark the Broadcast checkbox.
13. Click Actions to open the Policies > Edit Actions page. 14. Under the Deliver heading, select the action Email Firewall should take if
the message triggers the Spam Confidence Indicator with Moderate value, and the message is not from a sender on the Approved Sender list or the message does not contain the Message Content Rating with Broadcast value. For this example, mark the Quarantine radio button and select the quarantine queue in which to place the message. 15. Click Select Quarantine Tags to open the Select tags page. 16. In the Tag field, type Spam-Sender Not Approved, then click Create. 17. Mark the Spam-Sender Not Approved checkbox, then click Select Checked Tags.
18. In the Policies > Edit Actions page, click OK. 19. In the Policies > Edit Summary page, review the complete policy. See
Figure 6.22. If the policy is defined correctly, click Save. Like all Email Firewall policies, this policy must be applied to an appropriate record in the Email Firewall directory to create the policy coverage and exception cases required by your organization. See 6.11.4 Applying the Antispam Policy to the Directory on page 319 for additional instructions if needed.
322
Chapter 6: Creating and Editing Policies
Figure 6.22: Broadcast Exclusion Policy Summary
6.11 Using DAS Message Properties
323
6.12 Troubleshooting Policy Enforcement This section contains a checklist of Email Firewall basic functions and features that you can double-check if your policy is not being enforced or if it does not work as expected.
6.12.1 Policy Configuration Errors Policy Applied to Wrong Folder Users in your internal domain, for example, will be affected by per-user policies, policies applied to the Internal folder, policies applied to the domain record, and, under the default directory structure, policies applied to the All folder. They will not be affected by policies applied to the default domain record or the External folder unless they have no matching record in the Email Firewall Directory. Use the Show Where Used button to check where policies are applied.
Policy Enabled at Wrong Directory Level In order for a policy attached to a user to be invoked over a folder-level policy, the inherited folder policy must be disabled at the user level.
Policy Disabled Check the status of the policy in the directory object that inherits the policy.
Conditions Not Configured Properly Check all specified conditions. You might think your policy scans attachments, for example, but it scans only the subject and body.
Directory Object Has Not Inherited a Policy An object must be contained within another object to inherit its policy set. Note that user records do not inherit policies from domain records.
324
Chapter 6: Creating and Editing Policies
Exclude Conditions Not Configured Properly • Check specified policy exclusion conditions. • Check whether directory objects are excluded from an inherited policy, for example, if the policy is disabled at the lower level. Two Similar Policies Specify Different Actions A quarantine action, for example, will take precedence over a defer action. All policies that apply to a message will be invoked, regardless of the specified actions. See 5.4.1 Hierarchy of Message Actions on page 233 for more information.
Policy Should Be Recipient (or Sender) Make sure that you know whether your policy applies to the user who sends a message (sender policy) or the user who receives a message (recipient policy). This designation varies according to where the policy is applied: a recipient policy applied to the Internal folder usually affects inbound messages sent to your users; a recipient policy applied to the External folder usually affects outbound mail sent to users not in your internal organization.
Address List Uses Non-Word Characters In Email Firewall, address lists are converted to regular expressions by the Policy Engine. If the character before the matched address string is a non-word character (for example, a hyphen or a period), the list may catch unintended addresses. For example: • • •
List contains zoo.com. Also blocked is sf-zoo.com. List contains
[email protected]. Also blocked is
[email protected]. List contains
[email protected]. Also blocked is
[email protected].
For more information about how Email Firewall uses regular expressions, see Appendix C, Using Regular Expressions.
Annotations Not Skipped In order for a policy to skip annotation text, the policy must use a weighted word list when checking for content in the message.
6.12 Troubleshooting Policy Enforcement
325
Signed Messages Not Being Caught Attempting to catch signed messages using a basic mail filtering policy with the catch condition File Type = multipart/signed may not work properly. Instead, create a Client Encryption and Signature Security policy. See 9.14.4 Creating a Client Encryption and Signature Policy on page 528 for instructions.
6.12.2 Other Problems Virus Pattern File Needs to Be Updated It is recommended that you keep the default configuration in which the virus pattern files are updated automatically on an hourly basis. The regular virus pattern updates are your primary means of protection. Less frequently, a patch called extra.dat is released. This patch offers protection only from a few additional viruses that are not yet in the regular pattern files. For this reason, you should always have both on your system.
Virus Scan Engine Needs to Be Updated The virus scan engine is the actual software that does the checking. This is different from the virus pattern files, which tell the engine what viruses to check for. Virus engine updates, as available, are provided in Email Firewall patch releases.
SMTP Relay Service Is Stopped Open the Services Control Panel and make sure that the Email Firewall SMTP Relay service is started.
Policy Enforcement Not Enabled The Email Firewall Policy Engine must be enabled before Email Firewall can enforce policies. The SMTP Relay must also be enabled.
326
Chapter 6: Creating and Editing Policies
To enable the Email Firewall Policy Engine: 1.
In the Email Firewall main menu, click Set Up.
2.
Click Relays.
3.
On the Basic tab, verify the Policy Engine: route messages through Policy Engine checkbox is marked. If it is not, mark it, then click Save.
List Not Configured Correctly Double-check the address, word, or attachment lists to make sure they are complete. For a word list that uses keyword weighting, check the set threshold and the weights assigned to words and phrases.
Notification Address Is Incorrect If users are not receiving notifications as expected, check the Notification message for the policy. In the Email Firewall main menu, click Notifications to open the Notifications page.
Queue Backups Full SQL Server file groups can cause the Policy Engine to stop processing messages from the queues. The Policy Engine service checks for available space in seven of the file groups configured for the Email Firewall database. These file groups are: MMSBodyChunk MMSBodyChunkStatic MMSEventData MMSMessageData MMSMessageDataStatic MMSMessageDataPropertiesStatic MMSTransactionLog
If the Policy Engine service detects that the used space of any of these file groups is greater than 90%, the Policy Engine service will temporarily stop processing messages from any of the message queues until the used space goes below 85%. A warning will be logged with the list of file groups and the percentage of space used.
6.12 Troubleshooting Policy Enforcement
327
This problem can be solved by increasing the file size of the file group. Before doing so, you need to determine which file group size needs to be increased. For instructions on how to check file groups, see 3.6.1 Troubleshooting Inbound Queue Backups -- Full File Groups on page 139.
328
Chapter 6: Creating and Editing Policies
7
Dynamic Anti-Spam Service
This chapter describes the Dynamic Anti-spam Service (DAS) and how to use it. It also describes strategies to protect your organization from unwanted email communications. When DAS is installed, the Status page shows the Email Firewall Spam Analysis service in the list of Email Firewall services.
Engine
The information in this chapter builds on the information and procedures described in the previous chapters. You should also review the Tumbleweed EMF Anti-spam Best Practices Guide for additional information. This chapter contains the following sections: 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10
Introduction to Stopping Spam ............................................... 330 Dynamic Anti-spam Service Overview ................................... 332 Dynamic Anti-Spam Service Architecture............................... 334 How the Engine Processes Messages ..................................... 337 Message Categorization ......................................................... 340 Dynamic Anti-spam Service Administration........................... 343 Dynamic Anti-spam Filter Downloads ................................... 351 Download Service Maintenance ............................................. 353 The Tumbleweed Message Protection Lab ............................. 355 The Anti-spam Toolbox ........................................................... 360
329
7.1
Introduction to Stopping Spam “Spamming” refers to the Internet version of junk mail. If your site is being “spammed,” it is the recipient of unwanted, usually large volumes, of advertisement or other bothersome email, generically called “spam.” Enterprises have a number of legitimate reasons to be worried about spam entering their organizations: • • •
Employees receiving email containing offensive content may give rise to hostile work environment claims against the employer. Employees receiving spam email in their desktop inboxes can result in a substantial drain on workplace productivity. Enterprise IT and computer resources are being over-extended due to the incremental traffic volume that is not adding value to the business.
Spam is very dynamic and changes rapidly, often on a message-by-message basis. Spammers routinely investigate new and innovative ways to avoid having their emails blocked. The best solution is one that presents a flexible approach combining multiple strategies and countermeasures, giving you a series of options that allow you to customize an anti-spam arsenal to control and limit spam. While there is no way to permanently stop your site from being spammed because spammers continuously vary their techniques, you can take appropriate countermeasures. Spam can and must be defended against on a number of fronts. Once identified, spam messages must be acted upon. A varied approach is required. Tumbleweed’s gateway-based anti-spam solution combines a powerful, service-based spam identification capability with configurable antispam tuning and disposition. This section briefly describes this gateway-based approach, and where the Dynamic Anti-spam Service fits into the Email Firewall solution. For a more detailed discussion of Tumbleweed’s approach to anti-spam product design and the tools available using Tumbleweed’s antispam products, see the Tumbleweed Anti-spam Best Practices Guide.
330
Chapter 7: Dynamic Anti-Spam Service
7.1.1
At-the-Relay Protection While scanning email for spam is one way to address the spam problem, the first step in managing spam effectively is to practice good email hygiene. This includes ensuring that spammers are not able to use your email relay to forward spam to other targets. You can do this by ensuring that external-to-external routing is blocked. See Configuring Email Firewall To Prevent Open Relaying on page 59. You should also avoid situations that could result in Open Relay Blacklisting. In this case, messages sent by spammers or open relay testers use non-standard address formats to trick your mail server into thinking the message is addressed to an internal user. To prevent this, you can define illegal address formats to be rejected by the Email Firewall SMTP Relay. Once these illegal characters are specified, Email Firewall will refuse the message. See Specifying Illegal Characters in Email Address Formats on page 43. Finally, by verifying that each recipient of an email actually exists in your corporate directory, you can block directory harvest attacks that are probing for confirmation or denial of valid email addresses. These checks also help ensure that your organization does not become the source of spammer attacks, or the target of denial-of-service (DoS) attacks. For more information about at-the-relay protection, see 2.5 Setting Up Relays on page 32.
7.1.2
Incoming Message Classification Once a message has passed the Email Firewall SMTP Relay gate, the Dynamic Anti-spam Service (DAS) Spam Analysis Engine can be enabled to inspect the email and classify it as normal email or dubious email. Dubious email is assessed for high or moderate spam Confidence Level, and if it meets the confidence qualification, it is further analyzed to determine whether it merits a Content Rating for adult content, scams, or broadcast emails. These classification dimensions provide a granular and fully automated approach to spam identification. Following this classification step, the email is passed on to the Email Firewall Policy Engine, which applies any anti-spam policies you have created, as well as any additional policies that you may have defined, including anti-virus scanning, exclusions, or industry-specific policies.
7.1 Introduction to Stopping Spam
331
7.1.3
Acting on Spam Messages Once a message has been classified as suspected spam, Tumbleweed provides the industry’s most extensive set of actions (dispositions) to handle it. These actions may include dropping the message, returning it to the sender, quarantining it, delaying it, annotating it, sending it on as an attachment to a warning notification, or sending it along normally. This flexibility and breadth of alternatives is particularly important for enterprises that have different standards for how to treat various types of suspected spam. The Personal Quarantine Manager feature introduces an additional way to reduce administrative costs of spam. By allowing recipients to review potential spam messages held in the Quarantine queues and forward the messages to themselves if desired, administrators no longer have the burden of reviewing every individual email to determine whether it should be released from quarantine. For more information about setting up the Personal Quarantine Manager, see 3.7 Using Personal Quarantine Manager on page 142.
7.2
Dynamic Anti-spam Service Overview The Dynamic Anti-spam Service works by processing email messages after they have been accepted by the inbound Email Firewall SMTP Relay service, but before they are processed by the Email Firewall Policy Engine. The Tumbleweed Message Protection Lab™ provides data for the Dynamic Anti-spam filter updates. The Spam Analysis Engine uses this filter data in message analysis. Anti-spam filter data downloads are handled by the Email Firewall Download service. For instructions on setting up the Dynamic Anti-spam Service, see 2.6 Setting Up Anti-virus and Anti-spam on page 80.
7.2.1
Email Firewall Spam Analysis Engine Message processing is performed by the Email Firewall Spam Analysis Engine. The Spam Analysis Engine uses multiple heuristics to generate a multidimensional categorization for each message processed, and applies these heuristics and statistical analysis to identify and categorize spam. The Spam Analysis Engine is extensible over time, using the Email Firewall Download
332
Chapter 7: Dynamic Anti-Spam Service
service, as new techniques and categorizations are created. This process ensures that the system maintains a high capture rate and low false positive rate, even as spam tactics evolve. For more detailed information about the Spam Analysis Engine, see 7.4 How the Engine Processes Messages on page 337.
7.2.2
Email Firewall Download Service The Email Firewall Download service obtains the data that keeps the Spam Analysis Engine service up-to-date with the latest spam filtering techniques. The Download service is an Internet-based service that downloads to the Spam Analysis Engine the new heuristics published by the Tumbleweed Message Protection Lab. This service automates the process of anti-spam administration. Subscribers receive updates from Tumbleweed’s dedicated FTP server both automatically and on an as-needed basis. The service can be configured to check for updates automatically, but you can also manually check for updates as often as desired. When a new update is detected, it is downloaded automatically. The automatic update feature requires no additional administration or policy management once it is set up. Updates are integrated by the Spam Analysis Engine service on-the-fly, with no system configuration changes or service restarts required. For more information about the Download service, see 7.7 Dynamic Anti-spam Filter Downloads on page 351.
7.2.3
Tumbleweed Message Protection Lab The Message Protection Lab is a Tumbleweed research facility established to analyze spam and study SMTP messaging security and protection. The lab analyzes emerging spam methods and patterns by working with Tumbleweed’s Spam Capture Network and Tumbleweed’s enterprise customers. The Tumbleweed Message Protection Lab provides data for the Spam Analysis Engine service processing and publishes new anti-spam filter data on a regular basis. The lab applies a variety of methods and heuristic techniques to identify and categorize new spam, and publishes them for retrieval by the Email Firewall Download service. The lab also helps to design new anti-spam technologies that extend the Spam Analysis Engine service’s capabilities.
7.2 Dynamic Anti-spam Service Overview
333
For more information about the Tumbleweed Message Protection Lab, see 7.9 The Tumbleweed Message Protection Lab on page 355.
7.3
Dynamic Anti-Spam Service Architecture The Microsoft SQL Server architecture integral to Email Firewall allows the Installer to make a simple configuration change that allows incoming messages to be placed into the Spam Analysis queue for processing by the Spam Analysis Engine. When processing is complete, the messages are placed into the Email Firewall Inbound queue for normal processing. The only difference between mail flow with and without the Dynamic Antispam Service is the placement of messages in the Spam Analysis queue for Spam Analysis Engine service processing before delivery to the Email Firewall Inbound queue. During processing by the Spam Analysis Engine, when the engine identifies a message as potential spam, it adds pre-defined properties that allow Email Firewall to specially identify the message. Email Firewall recognizes the Spam Analysis Engine properties and, based on policies that you define, applies the dispositional action(s) specified in the policy.
7.3.1
Mail Flow with the Dynamic Anti-spam Service Figure 7.1 shows the Email Firewall architecture after Dynamic Anti-spam Service installation. The numbers in the diagram show typical SMTP mail flow with the Dynamic Anti-spam Service installed. Numbers in red (1-4) indicate message flow before processing by the Spam Analysis Engine and Email Firewall; numbers in blue (5-6) indicate message flow after processing. Mail is seen flowing:
334
1.
From the Internet to the Email Firewall SMTP Relay service for incoming messages.
2.
From the Email Firewall SMTP Relay service to the Email Firewall SQL Server database Spam Analysis queue.
3.
From the Email Firewall SQL Server Spam Analysis queue to the Email Firewall Spam Analysis Engine for processing. After processing, messages are placed in the SQL Server Inbound queue.
Chapter 7: Dynamic Anti-Spam Service
4.
From the SQL Server Inbound queue to the Email Firewall Policy Engine for processing. After processing, messages are acted upon and placed in the various SQL Server queues based on the dispositional action(s) required by the Email Firewall policies.
5.
From the SQL Server Outbound queue to the Email Firewall SMTP Relay service for outbound messages, if the message is approved for normal delivery. Email Firewall policies may require alternate delivery, or no delivery. See Actions on page 204 for a list of Email Firewall delivery options.
6.
From the Email Firewall SMTP Relay service to the recipient, if normal delivery is allowed. Delivery may be over the Internet, or internally to another SMTP Relay or email client.
7.3 Dynamic Anti-Spam Service Architecture
335
Figure 7.1: Dynamic Anti-spam Service Flow
Email Firewall Policy Engine
Email Firewall Web Admin
4
3 Email Firewall SMTP Relay Service
6
5
Email Firewall Archive Service
2
1
Internet SMTP Email FTP Server
336
SQL Server Database Message Queues
Chapter 7: Dynamic Anti-Spam Service
Email Firewall Spam Analysis Engine Service
Secure Redirect Secure Response Services
Download Service
7.4
How the Engine Processes Messages The Spam Analysis Engine reads messages from the Spam Analysis queue created in the Email Firewall database. When processing is complete, the message is moved to the Inbound queue for processing by the Email Firewall Policy Engine. If the Spam Analysis Engine determines that a message is potentially a spam message, it inserts new properties into the message indicating its opinion about the message. This is the only action taken by the Spam Analysis Engine; the service will never delete, detain or quarantine a message.
7.4.1
What the Engine Looks For The Spam Analysis Engine parses MIME messages for the purpose of locating the inline message body parts. The MIME parser is needed for decoding base64 or quoted-printable text and converting character sets to Unicode, which is required by the lexical analyzer. When a message has inline HTML, in addition to the extracted plain text, any URLs referenced will also be included in the text that is filtered. In this way it is possible to analyze URLs, IP addresses, domain names, etc. URLs are extracted from HTML A (anchor) tags href attributes and from IMG (image) tags src attributes. The key component for spam detection is comparison of the message subject and inline message text against Tumbleweed’s proprietary set of preconfigured heuristics. With the Email Firewall Download service setup, the Spam Analysis Engine always uses the most recent set of heuristics available. Although the Spam Analysis Engine technology is proprietary, following are a few examples of the techniques employed: • • •
Pattern recognition: for example, messages containing g.a.p.p.y-t.e.x.t is often spam. Lexical analysis: e.g., messages containing spam-like subjects like “$$GET COMPLETELY F*R*E*E VIP ACCESS$$”. Links to or reply addresses in known spammer domains are matched to a list.
The Spam Analysis Engine flags each message with its classifications, and passes it on to the Email Firewall Policy Engine.
7.4 How the Engine Processes Messages
337
7.4.2
Messages Not Analyzed by the Service There are three types of messages that by default are processed but only optionally analyzed by the Spam Analysis Engine: • • •
Messages larger than 200 KB. Messages received from the Email Firewall Secure Response service. SPN (secured) or encrypted message body text. Although SPN (secured) or encrypted message body text is not analyzed, the subject and sender are still analyzed.
Message attachments are also not analyzed. The Spam Analysis Engine does not consider personal but non-business-related messages between employees and/or recipients on the Internet, with no other indicators, as spam.
Internal messages are processed and analyzed by default by the Spam Analysis Engine; however, this analysis is optional. For performance reasons, you may want to omit internal message analysis. For more information, see7.4.3 Internal Message Analysis on page 339. For information on how to enable the option to omit internal message analysis, see 2.6.1 Setting Up Anti-virus and Anti-spam Downloads on page 82.
Large Messages By default, messages that are larger than 100KB are not analyzed by the Spam Analysis Engine. This large message bypass is an optimization which assumes that most spam messages are relatively small in size, and research by the Message Protection Lab supports this assumption. If this assumption is not valid for your organization, or if you want the message analysis performed for all messages regardless of size, this limit value is configurable. For more information, see 7.6.6 Adding Large Messages to Engine Processing on page 346.
Secure Response Service Messages Messages received from the IME-generated Secure Response service bypass the Spam Analysis Engine queue. This is true even when the Spam Analysis Engine is configured to scan all messages, including messages from internal SMTP networks. This is because Secure Response messages are not processed by the 338
Chapter 7: Dynamic Anti-Spam Service
Email Firewall SMTP Relay. The Secure Response service places messages directly into the Email Firewall Inbound queue. The Secure Response message bypass is an optimization which assumes that very little, if any, spam is sent to recipients using the Secure Response service. The Secure Response message bypass is not user configurable.
SPN or Encrypted Messages The Spam Analysis Engine cannot scan secure or encrypted message body text because the engine does not decompose messages. However, although the body text is not analyzed, the subject and sender are analyzed. Therefore, analysis of the subject or sender could result in an SPN or encrypted message being identified as spam. However, in practice it is not very likely that spam messages would be encrypted.
7.4.3
Internal Message Analysis The Dynamic Anti-spam Service internal message bypass feature is an optimization which assumes that no spam messages will originate from within an organization, and that no Email Firewall policies will be defined to look for DAS properties on messages where the sender address is in an internal domain. However, by default, messages received via SMTP from internal networks are analyzed by the Spam Analysis Engine. The primary reason for this default behavior is that Tumbleweed has found that in many organizations, the email network is configured in such a way that there is mail originating outside of the organization and relayed to Email Firewall, but from hosts that are designated as “internal” in the organization’s SMTP Relay configuration settings. The determination whether a network is internal or external is made in the Email Firewall Web Administration Setup > Relays > Network Connections page. Understanding Internal vs. External Networks on page 50 provides an explanation of how and when a network should be designated as internal vs. external. See 2.5.11 Setting Up Network Connections on page 54 for details and instructions on setting up your network connections. The Email Firewall SMTP Relay service places a message property on each message to indicate whether the message was received from an internal or an external SMTP client. The Spam Analysis Engine uses this property to bypass messages originating from within the organization.
7.4 How the Engine Processes Messages
339
There is a Spam Analysis Engine setup option to exclude internally-originating messages from Spam Analysis Engine analysis. This option is provided to increase system performance. When the option to exclude internal messages is enabled, messages received via SMTP from internal networks are not analyzed by the Spam Analysis Engine. They are immediately passed by the Spam Analysis Engine to the Inbound queue without modification.
7.5
Message Categorization The Spam Analysis Engine categorizes potential spam messages so that each dubious message is initially analyzed to determine whether there is high or moderate confidence that the message is spam. If so, then the message is further assessed to determine whether the message contains certain kinds of spam content. These spam content values include adult content, scam content, and broadcast content. Whenever the Spam Analysis Engine determines that a dubious message is spam, Tumbleweed-specific message properties are inserted into the message before it is moved to the Email Firewall Inbound queue. Using the names of these properties and the expected values they might contain, you can create Email Firewall policies to check for the presence of those properties or to compare the value of the properties against one or more string constants. See 6.11 Using DAS Message Properties on page 315. The Spam Analysis Engine takes no other actions on a message other than the possible insertion of message properties and headers. Messages are never dropped, quarantined, or detained by the Spam Analysis Engine. If a message causes an internal error in the Spam Analysis Engine, it is passed to the Email Firewall Policy Engine with no changes. To review why this behavior was adopted, see 7.6.8 Error Handling in the Spam Analysis Engine on page 347.
7.5.1
Message Assessment and Properties Added The Spam Analysis Engine first analyzes each dubious message for assignment of a Confidence level. This assessment determines the likelihood that a message is a spam message. A confidence assessment of High or Moderate classifies the message as spam. Once a message is identified as spam, an additional analysis
340
Chapter 7: Dynamic Anti-Spam Service
is performed for Content Rating to determine whether it contains adult, scam or broadcast content. When a message is processed by the Spam Analysis Engine and the message is determined to be spam, the Spam Analysis Engine adds an Email Firewallspecific message property to the message. A message may be given a Confidence property, or a Confidence and a Content property if the content rating is warranted. Policies that check for spam content using DAS message properties can specify these properties in the Policy Catch and Exclude conditions, under the Spam Indicators heading. See 6.11.2 What a DAS Policy Should Look For on page 316 for more information.
What the Spam Confidence Rating Means When the Spam Analysis Engine determines that a message is probably a spam message, it inserts the Confidence property into the message. There are two possible values, corresponding to the confidence level associated with the Engine's analysis: High or Moderate. The first property indicates that the Spam Analysis Engine has high confidence that the message is spam. The second indicates that the Spam Analysis Engine has moderate confidence that the message is spam. These two indicators provide flexibility when defining policy actions based on how much confidence the Message Protection Lab has that the message really is spam.
What the Spam Content Rating Means When the Spam Analysis Engine determines that a message is probably a spam message, it further analyzes the message to determine whether it contains certain kinds of spam content. The spam content ratings include: •
• •
Adult: is pornographic, sexual, or shocking in content, or advertises products, services, or Web sites that are pornographic or adult-oriented (even if the message itself contains no obscene language, pornographic images, etc.). Scam: is intended to scam or defraud (phishing attacks or other fraudulent messages). Broadcast: is a broadcast email such as a newsletter that may be from a legitimate business but which may represent an inappropriate or unauthorized use of email in some enterprises (e.g., frequent flyer account updates, news digests, etc.).
7.5 Message Categorization
341
If the analysis reveals that the message falls into one of the spam content categories, an additional property is added. Only one content property value is added. If a message meets multiple spam content criteria, the content property is added in this priority: • • •
Broadcast Adult Scam
The reason that the content property priority is ordered this way is because Tumbleweed Message Protection Lab testing has found that there is a high possibility that newsletters contain adult content, especially medical and legal newsletters. If the adult content rating we given a higher priority, these types of newsletters would not be recognized as such. At the same time, testing has found that the possibility that newsletter-type content is also found in adult messages is very low. In other words, while many broadcast messages include content that could trigger the adult content rating, the opposite is rarely true. So there is very little risk that adult messages are missed or improperly categorized with the current priority ordering.
7.5.2
Catching Dubious Messages You can use the default DAS policies, or define and deploy your own policies to take action on messages marked as spam. When you do this, the Email Firewall Policy Engine applies any additional company-specific or industryspecific policies or exceptions, and then handles the message based on your policy dispositions. You can choose different policy actions based on the severity and classification of the spam. Details about creating policies for use with the Dynamic Anti-spam Service are described in 6.11 Using DAS Message Properties on page 315.
7.5.3
Upgrades, X-Headers and Message Properties Previous versions of the Dynamic Anti-spam Service relied on inserting Xheaders rather than message properties into dubious spam messages. If you have upgraded to EMF 6.0 from a previous version of MMS with DAS installed, on upgrade, the configuration option to add DAS X-headers is enabled by default so that existing policies that rely on these headers continue to work properly.
342
Chapter 7: Dynamic Anti-Spam Service
In new installations of Email Firewall 6.1, DAS message properties are used and the DAS configuration option to add X-headers is not enabled by default. See 7.6.4 Enabling DAS X-headers on page 345. However, these X-headers can be used in policies when the option is enabled. See 6.11.2 What a DAS Policy Should Look For on page 316.
7.6
Dynamic Anti-spam Service Administration The Dynamic Anti-spam Service has been developed so that once installed, very little is required of administrators to keep the anti-spam services effective, active and up-to-date. After installation and configuration, the Spam Analysis Engine automatically processes all incoming messages that are routed through the Email Firewall SMTP Relay. Most messages are then analyzed, and if a message is determined as likely to be spam, then the Spam Analysis Engine also categorizes the message by adding specified properties to the message. The Spam Analysis Engine is described in detail in 7.4 How the Engine Processes Messages on page 337. The types of messages that are processed, but not analyzed, by the Spam Analysis Engine are described in 7.4.2 Messages Not Analyzed by the Service on page 338. The Download service automatically and regularly checks for and downloads the latest Spam Analysis Engine filters, and applies them on-the-fly, without the need for a system or services restart. The automatic download features are described in 7.7 Dynamic Anti-spam Filter Downloads on page 351. Instructions for manually acquiring an update should that need ever arise are found in 2.6 Setting Up Anti-virus and Anti-spam on page 80. For the administrator, then, the primary task is to create appropriate Email Firewall anti-spam policies, and apply them to the proper directory objects in the Email Firewall directory. The procedure for creating and applying Email Firewall policies using the DAS properties is provided in 6.11 Using DAS Message Properties on page 315. Alternately, you can create policies with Catch and Exclude conditions that look for spam message properties instead of X-headers.
7.6 Dynamic Anti-spam Service Administration
343
However, there may be occasions when you will need to perform initial setup and maintenance tasks.
7.6.1
Spam Analysis Engine Maintenance The Spam Analysis Engine is designed to need little administrator interaction. However, there may be occasions when you will need to disable and re-enable the service, bypass the service, widen the service, or add new license information. Information about Spam Analysis Engine error handling is provided for additional assistance in troubleshooting. See 7.6.8 Error Handling in the Spam Analysis Engine on page 347.
7.6.2
SMTP Relay Routing Option Behavior When the Dynamic Anti-spam Service is installed, on the Setup > Relays screen, the checkbox for Route messages through Policy Engine (and Spam Analysis Engine if installed and running) is marked. This means that new messages are placed in the Spam Analysis queue, instead of directly into the Email Firewall Inbound queue as it would be if the Dynamic Anti-spam Service were not installed. If you had previously unmarked the Route messages through Policy Engine checkbox (in order to bypass the Email Firewall Policy Engine), after installation of the Dynamic Anti-spam Service, messages will flow to the Email Firewall Spam Analysis Engine and then to the Email Firewall Policy Engine.
7.6.3
Enabling and Disabling the Service The Dynamic Anti-spam Service is enabled and disabled on the Set Up > Dynamic Anti-spam Service Settings page. On the DAS Status tab, the Enable/ Disable button is a toggle button between the two settings. When Disabled, all messages bypass the Spam Analysis Engine. This means that messages will be passed to the Inbound queue without Spam Analysis Engine analysis or header modification.
344
Chapter 7: Dynamic Anti-Spam Service
Moving All Messages Out of the Spam Analysis Queue If messages remain in the Spam Analysis queue after disabling the service, they can be moved from the queue by using the queue’s Reprocess option to route them to the Policy Engine. Attentively, they could also be deleted. It is not recommended that probable spam messages be returned to the sender.
7.6.4
Enabling DAS X-headers In previous versions of MMS with the Dynamic Anti-spam Service installed, the Spam Analysis Engine add X-headers to messages to identify them as possible spam. See 7.5.3 Upgrades, X-Headers and Message Properties on page 342. In new installations of Email Firewall, message properties, not Xheaders, are added to identify them as possible spam. However, the option to have the Spam Analysis Engine add X-headers to messages can be a useful tool for fine-tuning policies and setting message dispositions. To enable the Spam Analysis Engine to add DAS X-headers: 1.
On the Set Up > Dynamic Anti-spam Service Settings page, DAS Settings tab, mark the Add spam categories as X-Headers to scanned messages checkbox.
2.
Click Save.
To disable adding X-headers, unmark the checkbox and click Save. When adding X-headers is disabled, you can optimize spam detection using the properties in the policy Catch and Exclude conditions, under the Spam Indicators heading.
Spam Filter Version Identifier When the Add spam categories as X-Headers to scanned messages option is enabled, whenever the Spam Analysis Engine processes a message, it adds the header X-MMS-Spam-Filter-ID. The value of this header is the version string associated with the spam filter data being used by the Spam Analysis Engine at the time that the message was analyzed. See 7.5.3 Upgrades, X-Headers and Message Properties on page 342 for more information.
7.6 Dynamic Anti-spam Service Administration
345
7.6.5
Removing Internal Mail From Engine Processing The Spam Analysis Engine is configured by default to process messages from both external and internal senders. In previous versions of the Dynamic Antispam Service, the Spam Analysis Engine was configured by default to only process messages from external senders. To understand why the default behavior was changed to process both types of messages even though there is a slight performance cost, see 7.4.3 Internal Message Analysis on page 339. If your environment is correctly configured so that no internal messages might be regarded by the relay as coming from an external network, and you are reasonably confident that no spam would be originating from your internal users, then consider disabling screening of internal messages. To prevent the Spam Analysis Engine from scanning messages received from internal networks: 1.
On the Set Up > Dynamic Anti-spam Service Settings page, DAS Settings tab, mark the Do not scan messages received from internal networks checkbox.
2.
Click Save.
To re-enable scanning of internal messages, unmark the checkbox and click Save.
7.6.6
Adding Large Messages to Engine Processing By default, messages that are larger than 100KB will not be analyzed by the Spam Analysis Engine. If you want to change this limit, on the Set Up > Dynamic Anti-spam Service Settings page, DAS Settings tab: 1.
Mark the checkbox beside the Do not scan messages larger than 200 KB in and change the value in the field.
size
2.
Click Save.
To enable scanning of all messages regardless of size, unmark the checkbox and click Save.
346
Chapter 7: Dynamic Anti-Spam Service
7.6.7
License Changes And License Events If the Spam Analysis Engine service has been running without a valid license, a valid subscription license must be entered using Web Admin. If this occurs while the Dynamic Anti-spam Service is running, the new license may not be updated for up to fifteen minutes. This is due to how the Spam Analysis Engine checks the license status. The Spam Analysis Engine service checks the license status at service start-up every time. The license status is thereafter checked at fifteen minute intervals, but only when a message is retrieved from the Spam Analysis queue. This means that a change in license status may not be noticed for up to fifteen minutes if messages are regularly being sent through the Spam Analysis Engine. If no messages are being sent through the Spam Analysis Engine, then no license status change will be noticed until either the service is restarted or at least one message is processed from the Spam Analysis queue. If the Dynamic Anti-spam Service is running with an expired evaluation license or no license at all, a major Error event is logged to the Email Firewall Event Log. If the service is running with a license that is soon to expire, a major Warning event is logged starting ten days before the license expiration date and again every eight hours afterwards until the license has expired.
7.6.8
Error Handling in the Spam Analysis Engine The Spam Analysis Engine service has been designed and implemented for high reliability. In its design it was assumed that the Email Firewall Policy Engine analysis is critical to enterprise security, but that the failure to identify a few inbound spam messages is highly unlikely to result in a major problem for an organization. Consequently, the service was designed to process and pass without modification any “problem messages” that cannot be successfully analyzed. In contrast, the failure to apply security policies in the Policy Engine might have more serious consequences, so Tumbleweed has taken a more conservative approach in the behavior of that service. The Spam Analysis Engine service has implemented a “three-strikes rule,” which is similar to a feature implemented by the Email Firewall Policy Engine service. If the same message is seen by any Spam Analysis Engine service more than twice, the message is immediately bypassed with no further analysis. Thus, if a particular message were to cause the service to crash, it would be allowed to do so no more than twice. On the third attempt, the message would be passed to the Policy Engine immediately. 7.6 Dynamic Anti-spam Service Administration
347
The Spam Analysis Engine service has also implemented a form of selfmonitoring. There is a thread running within the service that monitors the message processing threads. If any message processing thread appears to be hung, the service will immediately terminate itself, killing any threads that don't terminate cleanly within a few seconds. When combined with the Windows 2000 service auto-restart feature and with the three strikes rule mentioned above, the chances that the Email Firewall Spam Analysis Engine service will be the cause of any email processing backlogs is minimized. The Email Firewall Installer sets the recovery option on the Spam Analysis Engine service so that it is automatically restarted following an unexpected termination of the service process. The error-handling scheme for the Spam Analysis Engine is critically dependent upon this feature, so this option should not be disabled. The self-monitoring feature depends on the Windows automatic service restart feature. This option should not be disabled for the Spam Analysis Engine.
A configuration parameter for the Spam Analysis Engine indicates the maximum number of seconds allowed for processing any single message. The default is 120 seconds. A thread running inside the Email Firewall monitors the amount of time that each of the message processing threads spends processing a message. If any message is taking longer than the limit allows, the monitor thread causes the service process to shut itself down. The Windows service control manager should automatically restart the service following this unexpected shutdown. If the same message is being processed during two self-imposed service shutdowns, the three-strikes rule will immediately pass the message to the Email Firewall Policy Engine on the next run of the Spam Analysis Engine.
7.6.9
Performance Counters The number of messages processed by the Spam Analysis Engine can be reviewed by checking the performance counters. The following sections describe how to setup and use these counters.
348
Chapter 7: Dynamic Anti-Spam Service
Preliminary Steps Required for Log Mode In order to use Email Firewall Performance counters in Log mode, the account for the “Performance Logs and Alerts” service must be changed. By default on Windows 2003 this account is NetworkService and must be changed to LocalSystem in order to work properly. These steps must be performed only when using counters to log information to files on disk. When using counters to view information in real time there is no need to perform these preliminary steps.
To change the “Performance Logs and Alerts” service: 1.
Use Start > Administrative Tools > Services to open the Services window.
2.
Double-click Performance Logs and Counters.
3.
Click the Log On tab.
4.
Mark the LocalSystem account radio button.
5.
Click OK.
Setting Up a Spam Analysis Engine Counter To set up a Spam Analysis Engine counter: 1.
Open the Microsoft Windows Performance Monitor Tool using the Start > All Programs > Administrative Tools > Performance series of commands.
2.
Expand Performance Logs and Alerts.
3.
Select Counter Logs.
4.
From the Action menu, select New Log Settings.
5.
Enter a log name and click OK.
6.
Click Add to add a counter.
7.
On the new log’s General tab, verify that the Select counters from computer radio button is marked and use the drop-down list to select the machine name (\\hostname format) on which the Spam Analysis Engine is installed.
8.
From the Performance object drop-down list, select the Spam Analysis Engine.
7.6 Dynamic Anti-spam Service Administration
349
9.
Verify the Select counters from list radio button is marked, and select the Message Throughput counter from the list.
Only the Message Throughput counter is available to select.
10. Click Add. 11. After the counter is added, click Close. 12. Under the Sample data every section, set the log interval and units to a
desirable log interval. 13. Click the Log Files tab and click Browse to set the location and name of the
log file for your preferred location and name. 14. Click the Schedule tab to schedule the Start and Stop of the log file for
your preference. 15. Click OK to complete the Performance Counters setup.
Starting a Spam Analysis Engine Counter To start the log file of the performance counters, perform one of the following steps:
• • •
Select the log file and go to Action and select Start. Select the log file and right-click, and in the pop-up menu click Start. Select the log file and click the right-arrow button (looks like a “Play” button on a tape player).
Stopping a Spam Analysis Engine Counter To stop the log file of the performance counters, perform one of the following steps:
• • •
350
Select the log file and go to Action and select Stop. Select the log file and right-click, and in the pop-up menu click Stop. Select the log file and click the square button.
Chapter 7: Dynamic Anti-Spam Service
7.6.10 Spam Analysis Engine Event Log Events The Event Log supports Error, Normal, Debug and Trace logging levels for the Spam Analysis Engine. For information about the report generated using the Normal events, see 11.2.8 Spam Volume Report on page 621.
7.7
Dynamic Anti-spam Filter Downloads The goal of the Dynamic Anti-spam Service is to respond to new spam techniques, not to new instances of randomized messages. Because new spam techniques do not emerge extremely rapidly, the update period is modulated accordingly. Whenever the Message Protection Lab identifies a high priority new spam technique, it is quickly made available. The Download service checks for filter data updates hourly. When new filter data is obtained, it is loaded into the Email Firewall database. The database tables named AntiSpamFilters and AntiSpamFilterData contain the filter data. The Spam Analysis Engine watches for new filter data being loaded into the Email Firewall database and will automatically begin using the new filter data when it becomes available. It is not necessary to restart the Spam Analysis Engine service to get the Engine to start using the new filter data. The Download service automatically deletes older filter versions from the database when there are five filter versions in the database. The Download service issues a warning if the filter being used is more than five days old. This warning is to alert you that there may be a problem with downloads or that the Download service is not operating correctly.
7.7.1
Downloading Filter Data From the FTP Server The Download service is an automated process that downloads filter data and heuristics from the Tumbleweed Email Firewall FTP Server. The FTP Proxy configuration data is shared for Anti-Virus and Anti-Spam updates. The filter data is downloaded with the compressed filename AYYYYMMDDXX.zip, where YYYY is year, MM is month, DD is day, and XX is the
7.7 Dynamic Anti-spam Filter Downloads
351
version number of the DD day if there is more than one version of filter data published the same day. Each .zip file contains information for the Spam Analysis Engine. For information on setting up the Updates, see 2.6 Setting Up Anti-virus and Anti-spam on page 80.
7.7.2
Updating the Email Firewall Database Tables After the FTP data is downloaded, the compressed files are inserted into the database (AntiSpamFilterData) to save space. The result of loading the filter files into the tables is: •
•
One new row is added to the AntiSpamFilters table with the version column being the name of the downloaded zip file without the extension, e.g., A2003021001. New rows are added to the AntiSpamFilterData table with the matching filterID column from the AntiSpamFilters table; fileName is the name of the filter file indicated above.
The new database rows are added in a single transaction, with no partial updates. An Event is logged on the status (successful/failed) of the download and loading to the database. After download, the Download service cleans up intermediate files at the end of the process, whether the update was successful or failed. In the case of a download failure or database failure, there are retries between preconfigured intervals. The default is three tries each with five minute intervals. Both settings are configurable, as described in 2.6.1 Setting Up Antivirus and Anti-spam Downloads on page 82. A finite number of old filters are left in the table to allow rollback to an earlier filter set. At least five sets of filter data are always left in the tables (five rows in AntiSpamFilters and the corresponding rows in AntiSpamFilterData).
352
Chapter 7: Dynamic Anti-Spam Service
7.8
Download Service Maintenance The Email Firewall Download service requires little or no administrator intervention. However, the tasks described in this section may be used for additional tuning or for system recovery.
7.8.1
Manually Checking for Updates The Download service checks for the latest update based on the initial download configuration interval. The service is implemented such that it checks for an update shortly after the service is started. The default update check is every hour. You can also manually initiate an update. See 2.6.1 Setting Up Anti-virus and Anti-spam Downloads on page 82. If the Download service determines that the filters in the database are in sync with the filter version on the FTP server, nothing is downloaded.
7.8.2
Rolling Back To An Earlier Filter Data Version The Spam Analysis Engine service always uses the filter version from the AntiSpamFilters table with the most recent lastUpdate column value. To force the service to use a specific filter version, you can modify the lastUpdate column in the row corresponding to the desired filter version.
7.8.3
Removing A Corrupted Filter Version You can remove a filter that has become corrupted using two SQL Server queries. Assuming that the filter version identifier is “A2003031401,” execute the following two SQL queries: DELETE AntiSpamFilterData WHERE filterID = (SELECT filterID FROM AntiSpamFilters WHERE version = 'A2003031401')
and DELETE AntiSpamFilters WHERE version = 'A2003031401' 7.8 Download Service Maintenance
353
7.8.4
Increasing MMSConfigData Filegroup Size As described in the Email Firewall 6.1 Installation and Upgrade Guide, you may need to increase the space allocated for the MMSConfigData filegroup so that multiple versions of the filters can be stored. To increase the space allocated for the MMSConfigData filegroup:
7.8.5
1.
Open SQL Server Enterprise Manager.
2.
Navigate to the EMFMail database (or the name of your Email Firewall database).
3.
In the left pane, right-click EMFMail and select Properties.
4.
Select the Data Files Property tab.
5.
In the Database Files table are the database files associated with the MMSConfigData filegroup. (The “filegroup” is the rightmost column shown in the table.) Normally, there will be one file with file name MMSConfigData_01 associated with the MMSConfigData filegroup.
6.
Edit the size of the database file by selecting the value in the space allocated (MB) column of the table. SQL Server will not let you reduce the file size from here; it will only let you increase it.
7.
Click OK to save your changes.
Troubleshooting Updates There are two known situations in which a Download service filter update may fail: • •
The MMSConfigData filegroup is low on space. The database transaction log is low on space.
If the MMSConfigData filegroup is low on space, use the procedure in 7.8.4 Increasing MMSConfigData Filegroup Size to increase the amount of space in the filegroup. Even if you have increased the amount of space in the MMSConfigData filegroup, anti-spam filter updates can fail if you do not have adequate space in your database transaction log.
354
Chapter 7: Dynamic Anti-Spam Service
If the database transaction log is low on space, you can perform either of the following tasks: • •
Increase the transaction log size. Perform a database backup to free up space in the transaction log.
When a filter update is not successful, SQL Server logs an event in the Windows Application Event Log. The event logged by the Download service indicates that the failure is probably due to lack of space in the MMSConfigData filegroup or low space available in the transaction log. You should verify you have sufficient space in both the MMSConfigData filegroup and the database transaction log before the next filter update. Once you have created additional space, you can use the procedure in 7.8.1 Manually Checking for Updates on page 353 to perform the update.
7.9
The Tumbleweed Message Protection Lab The Message Protection Lab uses the Tumbleweed Spam Capture Network (SCN) to identify current and emerging spam tactics and trends. This network includes an extensive set of “honey pots” for gathering samples of spam emails from the open Internet, and a network of Tumbleweed’s enterprise customers who provide enterprise-specific and industry-specific samples of both spam and non-spam email. The Lab uses all of this data to tune the existing set of heuristics, and to develop new heuristics that improve the effectiveness of Tumbleweed’s solution. These new and updated heuristics are published through the Email Firewall Download service. See 7.7 Dynamic Anti-spam Filter Downloads on page 351 for more information. Two dedicated mailbox addresses are available for you to send feedback about spam messages that were not caught, and about non-spam messages that were incorrectly identified as spam. For instructions on submitting samples, see 7.9.2 Submitting Examples To the Lab on page 356. Messages received from these addresses are used to continually fine-tune the filter data and heuristics.
7.9 The Tumbleweed Message Protection Lab
355
7.9.1
Message Protection Lab Tools The Message Protection Lab creates and maintains tools to: • • • •
Create and prepare the filter data heuristics. Monitor the filter data heuristics’ effectiveness (both catch rate and falsepositive rate). Maintain the test message archives. Extract candidate spam from the test message archives.
In addition to using the Tumbleweed Spam Capture Network to identify current and emerging spam tactics and trends, the Message Protection Lab scours public archives of messages and categorizes them into its mail archive. Categorization is done manually with the help of custom-built tools for message preprocessing. This tool splits mail archives that contain multiple messages per file, performs basic MIME processing, gathers statistical information from processed messages, performs message categorization, and produces uniquely identified messages for the Message Protection Lab message archive.
7.9.2
Submitting Examples To the Lab The Message Protection Lab uses samples of customer messages, both spam and non-spam, to add to the existing set of filters and to develop new data and heuristics that improve the effectiveness of our solution. As a subscriber to the Dynamic Anti-spam Service, you can assist the Tumbleweed Message Protection Lab in its goal of catching the maximum amount of spam with the lowest possible false positive rate. There are ways that you can help. • •
Submitting unmarked spam -- messages that should have been marked as spam by the Spam Analysis Engine, but were not. Submitting false positives -- messages that are incorrectly marked as spam by the Spam Analysis Engine.
If you determine that a spam or adult content message was not identified as such, or was not identified as expected, you should send the message to the Message Protection Lab. The Message Protection Lab is aware that spam messages that you forward may contain beacons. The Lab will make every effort to avoid activating beacons contained in the spam submissions.
356
Chapter 7: Dynamic Anti-Spam Service
How To Forward Unmarked Spam The Message Protection Lab strongly prefers that unmarked spam messages be submitted as an attachment to a new email message. This is so that the message header information is maintained. It is okay to attach several spam messages to a single message. Messages that are forwarded with only the inline text from the spam message are less useful, but are still accepted. For instructions on how to submit as an attachment when using specific email clients, see Microsoft Outlook and Netscape Users on page 357. The email address to which unmarked spam should be sent is
[email protected]. This address should only be used for missed
spam messages. Do not send questions or comments to this address. You will not get a reply to any message sent to this address.
Microsoft Outlook and Netscape Users This procedure is not possible when using the Outlook Web Access client.
To submit a spam message to the spamlab: 1.
Create a new email addressed to
[email protected].
2.
Depending on your client: • Outlook: Use the Insert > Item command and navigate to the folder where the messages are saved. Select each message and click OK to add your new message as an attachment. • Netscape and Outlook: Drag and drop each problem message from its stored location and add to your new message as an attachment.
3.
Send.
Automating Spam Submittal For Your Users You may want to set up an email address in your domain to which users can forward spam messages. You may also want this address to forward or copy all of the mail it receives to
[email protected]. If you do this,
7.9 The Tumbleweed Message Protection Lab
357
Tumbleweed requests that you also take the following steps to ensure that spam is submitted correctly. Some email clients (e.g. Microsoft Outlook Web Access) do not allow recipients to forward messages as attachments. If you have a significant number of users who normally use clients with this restriction, the policy described here should not be deployed. 1.
Create an attachment list that contains a single entry with Specification Style Standard MIME Type and Attachment Type message/rfc822. In this example, the attachment list is named Message Attachments.
2.
Create a notification to be sent to your spam message sender. The text of this notification should explain that spam messages must be submitted as an attachment. You may want to use the instructions in Microsoft Outlook and Netscape Users on page 357, step 2, for how to send as an attachment. In this example, the notification is named Please Submit As An Attachment.
3.
Define a policy to drop any message that does not contain a message attachment. The summary of the policy should look like this, when viewed in Email Firewall Web Admin: Policy Type: Basic Mail Filtering Applies To: Recipient Summary of Policy, ready to save: But exclude messages where… contains attachments in the attachment list “Message Attachments” Take the following actions… Drop the message and send the notification “Please Submit As An Attachment”
358
4.
Create a user record in the External folder of your Email Firewall directory for the address
[email protected].
5.
Apply the policy directly to this user record.
Chapter 7: Dynamic Anti-Spam Service
Submitting False Positives Messages that are incorrectly marked as spam or other categorization errors should be forwarded to
[email protected]. False positives may be submitted by: •
•
marking the Upon release, notify the Message Protection Lab that this message was inaccurately categorized as spam checkbox in the Queue > Message view page. When this checkbox is marked, the false positive address will be submitted automatically when the message is released. (This option is only available if the Spam Analysis Engine has tagged the message.) forwarding the message as an attachment as described in How To Forward Unmarked Spam on page 357. However, if you follow the procedure in Automating Spam Submittal For Your Users on page 357, you should not apply the message attachment policy if you create a user record for the false positive reporting address.
Submitting False Positives Using Email Firewall Web Admin Email Firewall administrators reviewing the Quarantine queue using Email Firewall Web Admin should submit the message by clicking the SMTP Recipients button. This opens a pop-up window in the browser that allows you to add another SMTP recipient to the message. This is where you should add
[email protected] just prior to releasing the message to the recipients. Adding a recipient here affects the envelope of the message only. The new recipient is added as a BCC recipient of the message. The original recipients will be unaware that the Message Protection Lab address has been added to the message. The alternative solution is to save the false positive messages to disk files using the Save Message to File button in Web Admin. These files can then be attached to a new email message (using any SMTP client application) and submitted to
[email protected].
7.9 The Tumbleweed Message Protection Lab
359
7.10 The Anti-spam Toolbox The following table identifies the variety of anti-spam tools available using the Dynamic Anti-spam Service in combination with Email Firewall. Additional information on stopping spam can be found in the Tumbleweed Email Firewall Anti-spam Best Practices Guide. Table 7.1: Anti-spam Detection and Defense Tools Spam Identification Tool
Address Lists
Comments
Allow you to check inbound traffic against address lists of known valid (or bad) recipients. Prevents spammers from performing dictionary attacks to find valid addresses, and from penetrating the corporate email system.
HTML Tag Filtering A common tactic used by spammers to circumvent filtering engines is to bury content below the surface of the HTML. The HTML presented in the email appears innocent, but when the links/buttons are invoked, many times they take you to advertising sites, pornography sites, etc. Lexicons
Content filtering based on weighted and un-weighted lexicons has proven to be a very effective weapon in catching spam. Allows fine-tuning to meet specific needs.
Dynamic Anti-spam Spam is a moving target and you must be able to Filter Data Updates dynamically adapt to the changes that take place. A dynamic updating service allows you to be proactive in spam categorization and blocking. The service provides updates on a routine basis with new filters and heuristics to provide a highly accurate, proactive, and low administrative overhead approach to handling spam. Spam Analysis Engine
360
Ability to categorize potential spam messages as “adult spam” (i.e. pornographic and other clearly offensive material), “high spam,” and “moderate spam” (i.e. marketing newsletters). This capability allows you to setup different actions based on the classification of the message.
Chapter 7: Dynamic Anti-Spam Service
Table 7.1: Anti-spam Detection and Defense Tools (Continued) Spam Identification Tool
Comments
Policy creation flex- Augments spam blocking capabilities. Messaging is ibility and fine-tun- dynamic and varies across industries, so you will want to ing create industry/company specific policies for spam in addition to out-of-the-box functionality and services. Throttle up or down spam blocking mechanisms because one size does not fit all. Regular Expression Engine
Related to Lexicons and Lexical analysis, a powerful regular expression engine gives you an additional layer that is proactive at blocking Spam. An example of a simple regular expression policy would be one that blocks any message that contains text where the letters are S P A C E D A P A R T like this. This is a common Spam tactic so words/messages are not recognized by scanners.
Relay and Server Protection Heuristics
Attack detection and blocking capabilities are needed both at the relay and server level to prevent Denial of Service attacks, email born threats, and Directory Harvesting (DH) attacks.
Reporting and Auditing
Detailed reports that show volume characteristics, trends, and audit information. Ability to create custom reports.
Spam Auditing Ser- Optional spam Quickstart service to assist with upfront vices setup and ongoing system tuning and maintenance. Support for DNSBL Option to use public or private DNS-based Blackhole or other IP-based Lists (DNSBL) as part of the anti-spam arsenal used in Blacklists conjunction with custom blacklists and whitelists. Variable Match Lexical Analysis
Combining the Exact Match Lexical Analysis with Variable Matching capability allows you to catch spam by evaluating a number of variables within the message. If any of these variables or a combination of variables appear in a message, you can decide what disposition to place on the message. This also lets you establish exceptions so that something you classify as valid email is not accidentally dropped/deleted.
Whitelists
Allows you to establish a whitelist of domains or email addresses that will always be accepted regardless of the message content from these addresses.
7.10 The Anti-spam Toolbox
361
Table 7.1: Anti-spam Detection and Defense Tools (Continued) Spam Identification Tool
End-User Empowerment
362
Comments
In addition to applying extensive gateway-based heuristics and policies to messages, it is important to allow the organization to choose from a number of actions to be taken against the message depending on the content. In some cases--especially when the message falls into the gray zone--the organization might want to enable the end-user (recipient) to make the final decision as to whether the message is truly spam. The system should be flexible and intelligent enough to do this on a message-by-message basis. Of course, you would not want this to be the action 100% of the time because then there is no employee productivity or network resource benefit. In the case where the message is delivered to the end-user the system should be savvy enough to apply the appropriate legal disclaimers/warnings to help mitigate legal liability issues.
Chapter 7: Dynamic Anti-Spam Service
,
8
Email Encryption and Authentication Overview
Email Firewall can encrypt, decrypt, digitally sign, and verify incoming and outgoing messages using policies and security integration features. The security settings protect senders and recipients of email sent to and from the SMTP Relay. Email Firewall allows you to manage local, external, and root certificates; manage local and external PGP keys; create Secure Public Network (SPN™) links between different Email Firewall systems; establish an email gateway in S/MIME Gateway (SMG) mode; create TLS message exchange links with partners; and provide proxy security for users with desktop encryption. These security features allow businesses to automatically and transparently secure and manage communications with partners, suppliers and customers. This chapter contains the following sections: 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13
Introduction to Email Encryption and Authentication in EMF364 S/MIME and OpenPGP Overview .......................................... 365 Email Firewall Gateway-to-Gateway Security ....................... 369 Email Firewall Security using TLS......................................... 373 Email Firewall Server-to-Client Proxy Security..................... 375 Email Firewall Client-to-Client Security................................ 385 The Sender Signature Policy Type.......................................... 391 Understanding Certificate Harvesting.................................... 394 Understanding Certificate and PGP Key Responders............ 395 Third-Party Certificates and Email Firewall ......................... 397 Third Party PGP Keys and Email Firewall ........................... 400 Understanding Certificate Rollovers ...................................... 401 The PGP Trust Model............................................................. 408
363
8.14 8.15 8.16
8.1
Trust and Interoperability of S/MIME Certificates ................ 408 Frequently Asked Questions ................................................... 422 Commonly Used Security Terms ............................................ 424
Introduction to Email Encryption and Authentication in EMF While many organizations want the benefits of secure email across the enterprise, most existing security applications require each user to follow complicated procedures to encrypt and decrypt their messages. Few organizations can afford the time or expense required to train every end user how to send and receive secure mail. Moreover, the thought of maintaining potentially disparate desktop clients for different end users is equally problematic. Tumbleweed’s security solutions solve this problem by allowing administrators to secure all email that flows within the organization, and email that flows in and out of the organization. Email Firewall uses S/MIME and OpenPGP Internet security standards and the SMTP over Transport Layer Security standard to secure mail on behalf of users who sit behind its email firewall. This server-based approach shifts the responsibility away from the end user to an automated process managed by one or more administrators or compliance officers. End users do not need to take any special actions. Email Firewall manages all the security details for them. Email Firewall provides everything an administrator needs to establish and maintain: •
• •
364
An S/MIME Gateway (SMG) mode of communication for S/MIME protected messages, where all mail that flows between the local Email Firewall and an external SMG-compliant domain is automatically encrypted and optionally digitally signed in accordance with the SMG profile of the S/MIME v3.1 specification. Support for the existing Gateway-to-Gateway S/MIME communications with other Email Firewall installations or non-SMG compliant gateways is also provided using Secure Public Network (SPN) mode. Encryption of SMTP traffic over TLS, between Email Firewall and other internal or external email servers. Encryption/decryption by proxy, where all mail that flows to an external S/MIME or OpenPGP client user is automatically encrypted and signed and all mail that flows from the external user is automatically decrypted and verified.
Chapter 8: Email Encryption and Authentication Overview
• • • •
8.2
Encryption-detection policies that require encrypted mail be made available to the Policy Engine for scanning. A certificate store with certificate validation and revocation checking. Certificate Revocation information through use of CRL downloads and CRL distribution points. Sender signature capability to provide digital signatures on behalf of senders.
S/MIME and OpenPGP Overview Email Firewall provides the capability to send secure email using the S/MIME protocol and the OpenPGP protocol. This section provides an overview of these protocols and highlights the differences between them. The S/MIME and OpenPGP protocols consists of two elements: digital signing, and encryption. These work together to provide cryptography. Secure mail can be viewed as providing four functions: • • • •
Privacy Authentication Integrity Non-repudiation
Encryption provides the privacy element of cryptography. Digital Signature relates to the authentication, integrity, and non-repudiation components of cryptography. While a message can be digitally-signed only or encrypted only, most commonly, a message that is important enough to secure with one is important enough to secure with both. Although S/MIME and OpenPGP provide similar security services, the two protocols use different formats to provide these services. Furthermore, the keys/certificates employed in each protocol also use different formats, which make these two protocols incompatible. S/MIME is based on the PKCS #7 data format for the messages, and the X.509v3 format for certificates. OpenPGP uses the PGP message and keys formats. The PGP message and key formats use simple binary encoding.
8.2 S/MIME and OpenPGP Overview
365
Table 8.1 provides a comparison of mandatory features within each of these two protocols. This table shows the many differences and the similarities between the two protocols in regards to the listed mandatory features. Table 8.1: Differences and Similarities between S/MIME and OpenPGP
8.2.1
Mandatory Features
S/MIME v3
OpenPGP
Message format
Binary, based on CMS Binary, based on previous PGP
Certificate format
Binary, based on X.509v3
Binary, based on previous PGP
Symmetric encryption algorithm
AES DES TripleDES (DES EDE3 CBC) RC2
AES BLOWFISH CAST5 IDEA TripleDES (DES EDE3 Eccentric CFB) TWO FISH
Signature algorithm
Diffie-Hellman (X9.42) with DSS
ElGamal with DSS
Hash algorithm
SHA-1
SHA-1
MIME encapsulation of Choice of multisigned data part/signed or CMS format
multipart/signed with ASCII armor
MIME encapsulation of application/pkcs7encrypted data mime
multipart/encrypted
Email Firewall and S/MIME Email Firewall is an S/MIME-compliant, secure email solution that is interoperable with S/MIME email products from other vendors. The S/MIME specifications contain recommendations for combining the MIME message format with the cryptographic standards defined in the Public Key Cryptography Standards to provide security for MIME messages S/MIME specifies a combination of symmetric and public key (asymmetric) encryption to ensure message confidentiality. The message itself is encrypted
366
Chapter 8: Email Encryption and Authentication Overview
using a symmetric key algorithm. The symmetric key is encrypted using the RSA public key algorithm and the public key of the recipient. Combining symmetric and public key encryption takes advantage of the strengths of both. Symmetric encryption is faster than public key encryption, while public key encryption solves the problem of transporting the symmetric key to the recipient for decryption. For interoperability among vendors, the S/MIME specification requires support for the 40-bit RC2 algorithm and recommends support for Triple-DES (3DES). When configured in SMG mode, the symmetric key cipher used will always be 3DES. Other symmetric algorithms can be supported, but they might not be interoperable. Email Firewall supports both 3DES and 40-bit RC2, as well as DES and RC2 with longer keys. It is recommended that you do not use the encryption algorithm 40-bit RC2 as it can be easily broken with a brute force attack. S/MIME also requires support for the SHA1 algorithm. Email Firewall supports SHA1 and MD5. S/MIME uses digital signatures for data integrity, sender authentication, and sender non-repudiation. To create a digital signature, the S/MIME application creates a unique, fixed-length representation of the message, called a message digest, that can be reproduced only by applying the same algorithm to exactly the same message. It then encrypts the message digest using the private key of the sender. The recipient uses the public key of the sender to decrypt the message digest to determine whether the message has been altered. One of the challenges of a public key encryption model is distributing and establishing the validity of public keys. S/MIME addresses this issue by requiring support for X.509 certificates. The X.509 format is a widely accepted standard for digital certificates and is supported by Email Firewall. A digital certificate contains a public key that has been signed by a party who will vouch for its authenticity.
8.2 S/MIME and OpenPGP Overview
367
8.2.2
Email Firewall and OpenPGP Email firewall is an OpenPGP compliant product (as specified in RFC 2440 and RFC 3156) that is interoperable with OpenPGP email products from other vendors. The OpenPGP specifications contain recommendations for combining the MIME message format with the cryptographic standards implemented in PGP to provide the security for MIME messages PGP like S/MIME specifies a combination of symmetric and public key (asymmetric) encryption to ensure message confidentiality. The message itself is encrypted using a symmetric key algorithm. The symmetric key is encrypted using a public key algorithm and the public key of the recipient. As with S/MIME, combining symmetric and public key encryption takes advantage of the strengths of both. For interoperability among vendors, the OpenPGP specification requires support for the Triple-DES (3DES) algorithm. Other symmetric algorithms can be supported, but they might not be interoperable. OpenPGP also requires support for the SHA1 algorithm. OpenPGP uses digital signatures for data integrity, sender authentication, and sender non-repudiation in a similar way to that used for S/MIME. PGP does not use X.509 certificates, but instead uses PGP key pairs. These are not compatible with X.509 certificates and also have a different trust model. For PGP keys, there is typically no external party who vouches for authenticity, but rather a direct trust established between the sending and receiving parties.
368
Chapter 8: Email Encryption and Authentication Overview
Email Firewall Gateway-to-Gateway Security Email Firewall provides facilities to encrypt and decrypt email as it travels between an EMF gateway and another email gateway on the internet. This is referred to in Email Firewall as a Secure Public Network (SPN), and can either be setup in SPN mode or S/MIME Gateway (SMG) mode. Often you will want to set up an SPN between a local Email Firewall server, and an external server which is either an Email Firewall or SMG compliant gateway. When an SPN is in place, the Email Firewall servers automatically encrypt, decrypt, sign, and verify all messages that flow between them. Server-to-server encryption is also referred to as S/MIME SPN. Figure 8.1 illustrates an SPN. When using SMG mode, interoperability between domains is ensured by adherence to the standards promulgated by the Open Group, which provides secure messaging gateway certification. Additional information about the group can be found at http://www.opengroup.org/messaging/sm/smgdev/. The Open Group document entitled S/MIME Gateway Profile defines the profile of the S/MIME Version 3.1 Message Specification to support gatewayto-gateway S/MIME protected messages. This document is used as the basis for the Certification Program to ensure the interoperability of products from different vendors which confirm to the profile. Email Firewall is certified as an S/MIME gateway. Figure 8.1: A Secure Public Network, or Server-to-Server Encryption
Internet
Tumbleweed Email Firewall Server
Email Client
Tumbleweed Email Firewall Server
Email Client
8.3 Email Firewall Gateway-to-Gateway Security
0122
8.3
369
An SPN works as follows: • • • • •
Two sets of people at two different organizations wish to send encrypted/signed messages to each other. Both of their companies have Email Firewall servers configured for SPN, or SMG compliant servers. The sender composes a message and sends it. The Email Firewall server encrypts/signs the message and sends it over the Internet as secure email. The server at the recipient’s company decrypts/verifies the message and sends it on to the recipient. While some interoperability with other vendors has been shown with the Email Firewall using the normal SPN configuration, Tumbleweed recommends using the product in SMG mode when configuring new remote domains for S/MIME to ensure the best chance of interoperability.
8.3.1
Understanding Local Secure Domains A local secure domain represents the internal domain you want to protect with Email Firewall security measures. The name of the internal domain defined during Email Firewall installation is created automatically as a local secure domain. This local secure domain is the primary local secure domain, and it cannot be deleted or removed. However, no certificates are automatically associated with the initial local secure domain. You must create a certificate to associate with the local secure domain, and it is this certificate that you exchange to create an S/MIME SPN and/or establish proxy security. You can also create additional local secure domains with which to establish S/MIME SPNs, such as for your internal departments and for external locations. Once you have created a new local secure domain, you can either associate the primary local secure domain certificate with the new local secure domain, or you can create a new certificate to associate with the new local secure domain. For an example of how to create a new local secure domain and associate a certificate with it, see 9.6.1 Defining and Associating Local Secure Domains on page 458. To create a certificate, follow the procedure outlined in 9.2 Setting Up Key Pairs and Certificates for S/MIME on page 433.
370
Chapter 8: Email Encryption and Authentication Overview
You can also use an external certificate from Entrust or VeriSign as the SPN domain certificate. See 8.10.1 Supported Third-Party Server S/MIME Certificates on page 398.
8.3.2
Setting up SPN Links After you have created a certificate for your local secure domain and associated a server certificate with it, you can begin to establish SPN links for secure exchange of email with external Email Firewall domains or other domains which use an SMG certified product. Before exchanging secure mail between domains, you must first exchange certificates. Requesting an SPN link is one way to do this. For instructions on how to request a link, see Requesting an SPN Link From External Email Firewall Servers on page 461. You can also set up your local Email Firewall system to automatically respond to SPN link requests from others. When a link is requested, Email Firewall will send a digitally signed message that includes its certificate to the external Email Firewall server, where it can then be imported. If the external Email Firewall domain that you are requesting an SPN link from is configured to automatically respond to the SPN link request, it: • • •
•
Receives the request. Imports the certificate into its S/MIME database. Sends a digitally signed message back to the local Email Firewall domain. This message includes the certificate of the external Email Firewall domain. When the local domain receives the message from the external Email Firewall domain, it imports the external domain’s certificate. If the external Email Firewall domain is not configured to automatically respond, an administrator must perform these tasks manually. In this case, response time will be substantially increased, and the process is not automatic. When requesting an SPN link with an external domain that is operating in SMG mode (using an Email Firewall or other vendor's product), an automatic response containing the domain's certificate and encryption key is guaranteed.
Once certificates have been exchanged you can begin creating Email Firewall SPN policies to implement secure messaging.
8.3 Email Firewall Gateway-to-Gateway Security
371
8.3.3
Certificate Import and Export The Open Group interoperability standards require that the Email Firewall running in SMG mode supports the import and export of certificates using the certificate management message (.p7c) format as defined in S/MIME Version 3.1, Certificate Handling. S/MIME Gateway certificates are generated, imported to and exported from Email Firewall using the Setup Security features. See 9.2 Setting Up Key Pairs and Certificates for S/MIME on page 433 and 10.6 Using the PrivateKeyWizard Tool on page 568.
8.3.4
The Email Firewall SPN-Type Policies SPN policies recognize SPN messages and specify the actions to take when security problems in correspondence with SPN domains are encountered. These SPN policies also apply to messages sent in SMG mode.
Non-SPN Message Received From SPN Domain (Inbound) Use this policy to specify what actions to take when Email Firewall receives an unencrypted, unsigned message from a domain from which you require secure messages.
Imperfect SPN Message Received (Inbound) Use this policy to specify what actions to take when Email Firewall receives a secure SPN message that cannot be decrypted or verified.
Unable to Encrypt and Sign to SPN Domain (Outbound) Use this policy to specify what actions to take when Email Firewall cannot encrypt and sign an outgoing SPN message. For instructions on how to create policies generally, see Chapter 6, Creating and Editing Policies. For more information about SPN-type policies, see 9.6 Setting Up a Secure Public Network on page 458.
372
Chapter 8: Email Encryption and Authentication Overview
8.4
Email Firewall Security using TLS Transport Layer Security (TLS) is the official Internet standard name for the proprietary standard that was known as SSL. The Secure Sockets Layer (SSL) protocol was originally developed by Netscape. There are three major revisions of this protocol; the most recent version is 3.0. Beginning in 1996, SSL protocol development became the responsibility of the Internet Engineering Task Force (IETF). When this happened, the name was changed to Transport Layer Security. Despite the change in names, TLS is just a new version of the SSL protocol. There are very few differences between SSL 3.0 and TLS 1.0 (published as RFC 2246). Consequently, where the acronym “TLS” is used in this document without any specific version number, SSL is implicit. RFC 3207– “SMTP Service Extension for Secure SMTP over Transport Layer Security” describes TLS as “an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers.” http://www.ietf.org/rfc/rfc3207.txt
The Email Firewall implementation complies with RFC 3207 and therefore should be interoperable with other vendor's implementations of this standard. Email Firewall supports remote hosts using both SSL 3.0 and TLS 1.0. TLS interoperability with clients and servers using older versions of SSL is not supported. The Email Firewall implementation uses OpenSSL. TLS can be used for a variety of purposes. For use with Email Firewall, these include: •
•
to secure communications with a specific external domain. For example, to secure all SMTP communications with an external business partner (using server-to-server security). to encrypt internal mail sent to (or from) the Email Firewall SMTP Relay. For example, to ensure that all SMTP traffic is encrypted between the internal mail systems and the Email Firewall Relay.
8.4 Email Firewall Security using TLS
373
The Email Firewall implementation of TLS is introduced to support two objectives: •
•
to secure SMTP sessions between cooperating domains. In operation it is similar to a Tumbleweed SPN, but it enables interoperability with other email server products that might not support the S/MIME Gateway or SPN protocols. to support encryption of SMTP traffic between Email Firewall and internal mail servers.
One must keep in mind that security is not guaranteed by the use of TLS between two SMTP hosts. In particular, there are no guarantees that the “previous hop” was secure when an inbound message was received by Email Firewall, nor are there any guarantees that the “next hop” will be secure when an outbound message is forwarded. For a comparison of Email Firewall SPN and TLS in messaging security, see Table 9.1 on page 432. How SMTP over TLS Works - In a Nutshell: 1.
SMTP servers may advertise the STARTTLS keyword in their EHLO response.
2.
A client that wants to use TLS issues the STARTTLS command.
3.
The server typically replies: 220 Ready to start TLS.
4.
The client and server then execute a TLS handshake as per the TLS protocol standards. • Same network connection, no change of port. • Unlike HTTPS, client authentication may be required at this time.
5.
If the handshake result is satisfactory to both sides, the SMTP session starts over under a TLS secured connection. Otherwise, either side may refuse to continue.
TLS Certificate Requirements Because encryption is used in TLS communications, the certificate used to represent the local Email Firewall server in all TLS negotiations and the private key that is associated with this certificate must exist in the Email Firewall database. Exactly one certificate and key pair is needed. The Email Firewall Relay does not support the use of multiple local server certificates for TLS. The same certificate and key pair is used by all Email Firewall Relay services that are using the same configuration database. TLS certificates are equivalent to Web Server certificates. For more information on TLS certificate requirements, see 8.10.2 Third Party TLS Certificate Requirements on page 399. 374
Chapter 8: Email Encryption and Authentication Overview
When setting up TLS, you must have a certificate even if you plan to use TLS only for outgoing mail. After the TLS server certificate has been imported, TLS must be enabled on the Set Up > TLS Setup page before it can be used in the relay configuration pages. After TLS has been enabled, the SMTP Relay must be configured to specify where TLS is permitted or required. These configurations are made in the Relay Network Connections and Routing Rules. See 2.5.11 Setting Up Network Connections on page 54 and 2.5.13 Setting Up Mail Routing Rules on page 60. After the Relay Network Connections and Routing Rules are configured for use with TLS, policies can be written to create a “TLS Message Exchange”. See 9.4.1 Creating a TLS Message Exchange Policy on page 448 for instructions.
8.5
Email Firewall Server-to-Client Proxy Security Email Firewall provides proxy security to users in your organization by encrypting, decrypting, signing, and verifying mail on their behalf. This allows users within your organization to send secure messages to external users who are using a desktop security system (S/MIME or OpenPGP client users). This server-to-client encryption is also referred to as S/MIME by Proxy or OpenPGP by Proxy depending the protocol used. Figure 8.2 illustrates proxy security.
8.5 Email Firewall Server-to-Client Proxy Security
375
Figure 8.2: Proxy Security
Internet
Tumbleweed Email Firewall Server
Email Client
Email Client
0122
Tumbleweed Email Firewall Server
The Email Firewall key pair and/or certificate are used to represent the users in your organization. While some email clients allow users to associate any key or certificate with any correspondent, many do not. Therefore, most external users who use S/MIME or OpenPGP clients will not be able to use the Email Firewall certificate or PGP key to encrypt mail for your local users. However, Email Firewall can generate proxy certificates or proxy PGP keys that associate the Email Firewall public key with the local user’s email address. When external users encrypt mail for your users with proxy certificates or proxy PGP keys, Email Firewall can decrypt it. Before a local user can exchange secure mail with an external user, you can exchange certificates/keys with the external user and then associate the certificates/keys with their user records in the Email Firewall Directory. With S/MIME, you can also configure Email Firewall to look up an external user’s certificate from an LDAP server using the Automatic Certificate Lookup functionality. See Automatic Lookup of User Certificates on page 381 for more information. With OpenPGP, you will have to manually associate the external users’ keys to their records. When using a trusted Certificate Authority, Email Firewall can be configured to allow the automatic association of S/MIME certificates to user records.
376
Chapter 8: Email Encryption and Authentication Overview
Figure 8.3 illustrates the Server-to-Client encryption process. Figure 8.3: Server-to-Client Encryption Using Proxy Security
• • • • • •
8.5.1
Two sets of people at two different organizations wish to encrypt/sign messages to each other. The sender’s company has an Email Firewall server. The recipient’s company uses desktop encryption. The sender composes a message and sends it. The Email Firewall server encrypt/signs the message and sends it over the Internet as secure email. The recipient receives the encrypted/signed message and must use the S/MIME or OpenPGP client to decrypt/verify
How Email Firewall Performs Proxy Security A user behind Email Firewall does not need to generate a key pair to receive encrypted messages. When an external user requests a secure link, Email Firewall either responds to the request by sending a signed message to the correspondent that includes the Email Firewall certificate, or a message including the PGP key used by Email Firewall. The sender then associates the Email Firewall certificate or key with the local user and uses it to encrypt mail for the local user. When Email Firewall receives the encrypted message, it decrypts the message using its private key, passes the plain text to the Policy Engine for processing,
8.5 Email Firewall Server-to-Client Proxy Security
377
annotates the message to say it was encrypted, and sends the message to the recipient. A user behind Email Firewall does not need to manage correspondents’ certificates or PGP keys in order to send encrypted messages. Instead, the certificates and PGP keys are stored in the Email Firewall database. When a local user sends a plaintext message, Email Firewall checks the external user's record for a certificate or PGP key, and encrypts the message using either the certificate or PGP key (depending on the type of proxy security the user is configured to use.) To set up server-to-client proxy security, the following steps must be completed: • • • •
• • •
378
Enable Proxy Certificate Usage. (Only applicable to S/MIME proxy security.) Create a Proxy Decrypt and Verify policy. Create a Proxy Encrypt and/or Sign policy. The external user performs a cert-query or pgp-key-query operation. Or for S/MIME proxy security only, send a signed and encrypted message to the external user to provide the proxy certificate. Trust the external user’s certificate. (Only applicable to S/MIME proxy security.) Create a user record for the external user and associate their certificate or PGP key. Optionally, if the external user wants to trust a number of users from the internal domain, send the external user the Email Firewall Root Key (or publish it where the external user can obtain it). (Only applicable to S/MIME proxy security.)
Chapter 8: Email Encryption and Authentication Overview
•
Optionally, if the external user wants to trust a number of users from the internal domain, send the external user the Proxy PGP Domain key associated with the protected Local Secure Domain. Another option is to have the external user requests this Proxy PGP Domain key by sending the appropriate key query to the pgp-key-query address. (Only applicable to OpenPGP proxy security.)
After an external user associates the Email Firewall proxy certificate or PGP key with the local user, that external user and the local user can seamlessly exchange secure mail. When you use proxy security, you should make sure your relay is not configured as an open relay, so that external sources cannot use Email Firewall as a relay host to send nonsecure or nonauthentic mail to your secure correspondents. You should also make sure that none of your internal hosts are automatically forwarding external mail to Email Firewall.
Email Firewall can perform the following proxy security services. When it cannot properly execute the operation, it performs the alternative actions you specify in your security policies.
Proxy Encryption To encrypt messages to a specific recipient, Email Firewall finds a user record in the Email Firewall Directory that corresponds to the recipient, and encrypts the message with the certificate or PGP key associated with that record. For the operation to be successful, all of the following must be true: • • • •
The message recipient must have a user record in the Email Firewall directory. The recipient’s user record must be associated with a certificate or PGP key. The certificate or key must be valid. A Proxy Encrypt and/or Sign policy must be in effect on the external recipient’s user record.
8.5 Email Firewall Server-to-Client Proxy Security
379
For S/MIME proxy security, Email Firewall can also be configured to automatically look up the recipient’s certificate from an LDAP server. See Automatic Lookup of User Certificates on page 381. When a certificate is associated with the user record directly in the directory, that certificate will always override any certificate associated with that user that results from using the LDAP lookup.
Proxy Decryption To decrypt messages addressed to Email Firewall users, Email Firewall uses the private key (stored encrypted in the Email Firewall database) that corresponds to the public key used to encrypt the message. If the message is encrypted for any private key in the Email Firewall database, the message is successfully decrypted. A Proxy Decrypt and Verify policy must be in effect.
Proxy Signature To digitally sign outgoing messages on behalf of Email Firewall users, Email Firewall signs the message with its own private key and for S/MIME uses the proxy certificate in the digital signature. In the case of OpenPGP, Email Firewall will sign with the imported internal user's PGP private key or generate a new proxy PGP private key if the internal user does not have one imported. A Proxy Encrypt and/or Sign policy must be in effect on the external recipient’s user record.
Proxy Verification To verify a digital signature on an incoming message, Email Firewall finds a user record in the Email Firewall Directory that corresponds to the sender. If the record exists, Email Firewall verifies that the incoming certificate or signing PGP key is associated with the sender’s user record and uses the certificate or key to verify the digital signature. For the operation to be successful, all of the following must be true: • • •
380
The message sender must have a user record in the Email Firewall directory. The sender’s user record must be associated with a certificate or PGP key. The e-mail address associated with the PGP key must match the e-mail address associated with the external user's record.
Chapter 8: Email Encryption and Authentication Overview
• •
The certificate or key must be valid. A Proxy Decrypt and Verify policy must be in effect on the internal recipient’s user or domain record.
Automatic Lookup of User Certificates
This section is only applicable to S/MIME proxy security.
Email Firewall provides real-time lookup of end-user certificates for server-toclient encryption, or proxy security. This lookup is defined on a per-policy basis, and is enabled by identifying the directory location or LDAP source where Email Firewall should look for the recipient’s certificate. This lookup is enabled as part of the Proxy Encrypt and/or Sign policy type. To use this feature with S/MIME encryption, the Auto Certificate Lookup of End User Certificates purpose must be enabled for the Trusted Root Certificate that the looked-up certificates chain to. When automatic certificate lookup is enabled, if a policy triggers the lookup, Email Firewall will use the encryption certificate specified in the LDAP source. However, you can override the automatic certificate lookup on a per-user basis by manually associating a different certificate with that user’s user record. If a certificate is manually associated with a user record, even if LDAP lookup is specified in the Proxy Encrypt and/or Sign policy assigned to the user or domain record, the certificate associated manually in the user record will be used.
Similarly, the manual association of a certificate may cause the proxy encrypt and sign policy to fail if the manually associated certificate is not enabled for automatic association or if that certificate becomes invalid. Care must also be taken when applying this automatic lookup feature because a user record for a particular user may not be in the same location in the Email Firewall directory hierarchy as a domain record for users of that domain. If this is the case, and the policy using this feature is only added to the domain record or to a superior folder of the domain record, the policy may not be applied to the user.
8.5 Email Firewall Server-to-Client Proxy Security
381
8.5.2
Email Firewall and Automatic Certificate Association This section is only applicable to S/MIME proxy security. Automatic certificate association can be configured for a trusted X.509 Certificate Authority. As such, it is not relevant to OpenPGP encryption. This Email Firewall policy provides automatic certificate associations between user records and the certificates used to sign email from the user. For autoassociation to work, the user record must already exist in the Email Firewall directory. For information on adding user records to the directory, see 5.3.4 Adding New Directory Objects on page 224. For information on importing LDAP-compliant user records into the Email Firewall directory, see 10.2 Setting Up LDAP Directory Imports on page 534. The Auto Certificate Association with End User Records option must also be enabled in the Root Key Purpose Certificate Properties to use this feature. See 9.8.8 Enabling Automatic Certificate Association on page 490. If a certificate is received that does not chain to a root with the Auto Certificate Association purpose set, the certificate will be imported, but will not be associated to the user.
Policy Usage The most common use for this policy is where an organization’s partner, customer or client has S/MIME enabled at the desktop, and communication between the Email Firewall-enabled organization and the external organization is with a select set of people. In this case, the Email Firewall administrator can create a folder for that external partner with this policy applied. The administrator can then import the root certificate for the external partner’s CA. The administrator then creates user records in this folder for the set of users for which secure communication is required. Those external users are then required to send a signed message to Email Firewall, and the certificate association is automatically made. Care must be taken when applying this policy because a user record for a particular user may not be in the same location in the Email Firewall directory hierarchy as a domain record for users of that domain. If this is the case, and the
382
Chapter 8: Email Encryption and Authentication Overview
policy is only added to the domain record or to a superior folder of the domain record, the policy may not be applied to the user.
New Certificates The policy will reset the default encryption certificate if a new appropriate certificate is found. However, it will not remove any of the current certificate associations. When a certificate is received that meets the proxy certificate criteria (i.e., chains to trusted root, appropriate purpose enabled), when other certificates are already associated with a user record, the new certificate is associated to the user and becomes the default certificate. This allows external users to change certificates without any intervention by the Email Firewall administrator.
Policy Limitations This policy has several limitations. • •
•
•
The policy set that is selected must be the result of finding a user record from the email address in the mail message being processed. Only the primary email address for the Email Firewall user record is used in certificate auto association; none of the configured alternate aliases are used.Therefore, the primary email address must match the email address in the certificate for the policy to succeed. The email address in the certificate can be specified in either the subject field or in the subjectAltName certificate extension. Email Firewall will search for a valid certificate. i.e., one that is suitable for encryption, that has not expired and that has not been revoked. If no valid certificate is found, then no association is made. Automatic certificate association can be used for user records only, not for domain records.
Root Key Purpose Automatic certificate association is only supported for a specific set of roots. This is to prevent an attack where an incorrect certificate is associated with a user record resulting in messages that are encrypted in a way that prevents the recipient from reading them, and so prevent an attack that allows a man-in-themiddle to decrypt them. The Root Key Certificate Properties tab shows the purposes for which a root key can be used.
8.5 Email Firewall Server-to-Client Proxy Security
383
8.5.3
The Email Firewall Proxy Security Policy Types Proxy Decrypt and Verify Use this recipient policy to decrypt and verify incoming secure messages for recipients who do not have S/MIME or OpenPGP clients on their desktops.
Proxy Encrypt and/or Sign Use this recipient policy to encrypt and digitally sign outgoing messages on behalf of users who do not have S/MIME or OpenPGP clients on their desktops. For encryption to work, Email Firewall must be able to find the recipient’s encryption certificate or key. For S/MIME, you can configure Email Firewall to look for the encryption certificate in either the recipient's user record, or in a specified LDAP Data source. For OpenPGP, you can configure Email Firewall to look for the encryption key in the recipient's user record. If the proxy encryption is successful, Email Firewall delivers the encrypted copy of the message normally. If Email Firewall is unable to encrypt the message, you can instruct Email Firewall to handle the original clear text message with any of the standard policy actions, for example, send the message to quarantine.
Automatic Certificate Association (for S/MIME only) Use this sender policy to automatically associate the certificate used to sign an email (or an encryption certificate, if present) with a user record in the Email Firewall Directory, for the purposes of message encryption. The following must be true in order for this policy to succeed: 1.
The certificate must be a valid certificate enabled for encryption.
2.
A user record must exist in the Email Firewall directory which contains the same email address as the one specified in the subject field or the subjectAltName of the signing (or encryption) certificate.
3.
The root certificate of the signing (or encryption) certificate must exist in the Email Firewall Certificate Database as a Trusted Root and be enabled for Automatic Certificate Association.
If the association is successful, Email Firewall delivers the message normally. If unsuccessful, Email Firewall delivers the message normally and logs an event. See 8.5.2 Email Firewall and Automatic Certificate Association. on page 382 for more information about this feature.
384
Chapter 8: Email Encryption and Authentication Overview
Unencrypted Message Filter Use this sender or recipient policy to detect messages that should have been, but were not, encrypted by Email Firewall or by an S/MIME or OpenPGP client. This policy is useful for preventing non-secure messages from being sent over the Internet. For example, you might define an encryption policy stating that all messages to a specific domain must be encrypted. The Unencrypted Message Filter policy will detect messages that are not encrypted and determine their disposition.
Client Encryption and Signature Use this sender or recipient policy to detect messages based on their state of security, such as “signed,” “encrypted and not signed,” “not encrypted,” or “signed but revoked.” This policy is useful for enforcing uniform message security across your organization.
8.6
Email Firewall Client-to-Client Security Client-to-client security involves encryption between two individual S/MIME or OpenPGP users whose email is passing through an Email Firewall system. The main difference between client-to-client encryption and server-to-server or server-to-client encryption is that Email Firewall is not doing any encryption. In this scenario the users are encrypting/decrypting to each other while Email Firewall is responsible for scanning the email. This form of security uses an Email Firewall policy in which encrypted traffic between two clients can be checked by the Policy Engine prior to delivery or receipt because the Email Firewall server also holds the appropriate keys for decrypting and verifying signatures. Client-to-client security requires that policies be written so that all mail, including the encrypted email flowing
8.6 Email Firewall Client-to-Client Security
385
between two clients, can be fully scanned by the Policy Engine. Figure 8.4 illustrates the Client-to-Client encryption process. Figure 8.4: Client-to-Client Encryption Using Email Firewall Policies
• • • • •
•
Two sets of people at two different organizations wish to encrypt/sign messages to each other. The sender’s company uses desktop encryption, however they also have an Email Firewall server to scan for content and viruses. The recipient’s company uses desktop encryption. The sender composes a message and encrypts and signs the message for the recipient as well as for the Email Firewall server. The Email Firewall server decrypts the message and scans it for possible policy violations. If no violations are found the message is sent over the Internet. The recipient receives the encrypted/signed message and must use the S/MIME or PGP client to decrypt/verify.
The client-to-client policies can be grouped into two categories: •
•
386
Policies that allow encryption between two parties so long as each message is fully scanned by Email Firewall. These include: • Plaintext Access • Allow Security Stripping Policies that require encryption between two parties. These include: • Unencrypted Message Filter • Client Encryption and Signature
Chapter 8: Email Encryption and Authentication Overview
8.6.1
“Allow” Client-to-Client Security Policies The following policy types allow client-to-client security so long as the Policy Engine can scan the message.
Plaintext Access Plaintext access policies are useful when you do not want email users to send or receive encrypted mail that cannot be reviewed by Email Firewall for content scanning for sensitive information, viruses, spam, etc. If Email Firewall receives an encrypted message that requires a private key that it cannot access (for example the private key of a particular user), then it cannot decrypt the message and none of the email scanning policies can be applied. A Plaintext Access policy is used to ensure that mail is encrypted not only for the sender and recipient, but also for Email Firewall. This type of policy is applied when the message is encrypted but the Email Firewall server does not have the key to decrypt it, and can apply to either sender or recipient. Use this sender or recipient policy to ensure that messages are encrypted for Email Firewall in addition to the intended recipients. Encrypting a message for Email Firewall means that security policies can decrypt them. Once decrypted, the Policy Engine can process them and apply any other policy actions the message may invoke. With a plaintext access policy in place, when an S/MIME or OpenPGP sender encrypts a message to an S/MIME or OpenPGP recipient on the opposite side of the Email Firewall Server but does not include the Email Firewall server as a recipient of the message, the message is received by Email Firewall and, because the plaintext access policy is enabled, it automatically returns the message with instructions on how to send encrypted email through Email Firewall. These instructions explain that the message must also be encrypted for Email Firewall and the Email Firewall secure server’s email address (in the format
[email protected]) is provided. This address must be identical to the Email Firewall secure server address; it cannot be changed by the administrator. The Email Firewall public key certificate and/or details of how to obtain the server’s PGP key are also included for the user to associate to the Email Firewall secure server email address. At this point the sender now understands the corporate encryption policy and can send encrypted email to the intended recipient as before, but now also cc: the Email Firewall Server email address. When the message is received, Email Firewall can hold the message, decrypt its copy, process the plaintext through 8.6 Email Firewall Client-to-Client Security
387
the policies and if it passes, the originally encrypted message is forwarded to the intended recipient. The recipient would decrypt as usual.
Understanding Plaintext Access This is what happens when there is no plaintext access policy in place: 1.
External Client sends encrypted mail to: and the message is encrypted using certificate).
2.
Message is routed through Email Firewall. Email Firewall cannot decrypt the message so it is processed normally to and no scanning is performed on the message.
3.
Roel at tmwd.com gets the message on his Outlook 2000 client. The Outlook client has the Private Key for the certificate and so he is able to open the message.
With a plaintext access policy in place, when an S/MIME or OpenPGP sender encrypts a message to an S/MIME or OpenPGP recipient on the opposite side of the Email Firewall server but does not include the Email Firewall server as a recipient of the message, the message is received by Email Firewall and, because the plaintext access policy is enabled, Email Firewall automatically quarantines the message and sends instructions to the sender on how to send the encrypted email through Email Firewall so that it can be delivered to the intended recipient.
Allow Security Stripping Use the sender or recipient Allow Security Stripping policies to strip encryption and digital signatures from messages when other policies need access to it, for example, to modify the message contents, or to remove infected attachments. This is a “backup” type policy to the Plaintext Access policy. Security stripping leaves recipients with nonsecure messages; you may want to restrict this policy to internal recipients only.
By default, Security policy types preserve the security of the message. In other words, they will allow other policies to examine the contents of an encrypted message (provided you have a plaintext access policy in place), but not modify them. If you want other policies (such as virus policies) to be able to modify the contents of secure messages, you must explicitly create an Allow Security Stripping policy for both the sender and the recipient. 388
Chapter 8: Email Encryption and Authentication Overview
It is important to understand that if a secure message is modified, the encryption is destroyed, and the recipients will not receive a secure message even though the message was originally signed and encrypted. You must weigh the relative importance of retaining message security against facilitating the immediate delivery of text that does not violate your policies. Both the sender and the recipient must have a securitystripping policy in place before the policy will take effect. In addition, to strip encryption, Email Firewall must have access to the message. Creating a Plaintext Access policy ensures that messages are encrypted for Email Firewall, allowing Security Manager to decrypt them.
8.6.2
“Require” Client-to-Client Security Policies The following policy type requires client-to-client security.
Unencrypted Message Filter Policy Use an Unencrypted Message Filter policy to catch mail that is not encrypted when it should be. Imagine the following scenarios: Suppose you allow security stripping, and have plaintext access and virusstripping policies in place. Suppose further that Email Firewall receives an encrypted message, decrypts the message, and a virus policy strips an infected attachment from the message. At this point, you have a message that is no longer secure, but is about to be delivered over the Internet. What if that message contains sensitive information? You can filter out and act upon such messages by creating an Unencrypted Message Filter policy. The policy examines nonsecure messages for specific conditions that you specify when you create the policy. Keep in mind that the policy ignores all encrypted messages and it does not distinguish between encryption performed by Email Firewall and encryption performed by a desktop S/MIME or PGP client. These policies can apply to either sender or recipient, and will catch messages that have not been encrypted by the sender and will not be encrypted by the Email Firewall server.
8.6 Email Firewall Client-to-Client Security
389
8.6.3
The Client Encryption and Signature Policy The Client Encryption and Signature policy is used to monitor or act upon messages based on their state of security, such as “signed,” “encrypted and not signed,” or “not encrypted.” If you want to detect and act upon messages based on the state of their security or lack of security, and any additional criteria, create a Client Encryption and Signature policy. For example: • • • • • • •
Is a given message signed? Signed but not encrypted? Encrypted but not signed? If so, does it contain a specific word? Was it sent or received on a specific date? Does it have a particular type of attachment? Has the certificate been revoked?
In all of these cases, you could write a policy to catch these conditions and require actions based on how you want to handle these types of messages. Figure 8.5 shows the encryption and signature catch condition selections. Figure 8.5: Client-to-Client Encryption and Signature Catch Selections
390
Chapter 8: Email Encryption and Authentication Overview
The “Signed by a non-trusted CA” option is not applicable to PGP signed messages.
8.7
The Sender Signature Policy Type This policy type is only applicable to signing messages with S/MIME digital certificates. Equivalent (proxy signing) can be achieved using PGP keys by importing the PGP key for an individual user using the PrivateKeyImport Wizard tool and using a Proxy Encrypt and Sign policy. Email Firewall allows Security Manager to decrypt them.
This policy Sender Signature Policy type provides digital signatures on behalf of message senders. Digital signatures provide the highest level of email sender authentication possible. By deploying policies that use this feature, an organization can provide an authenticate email to its email recipients. The organization can thus protect itself from spammers and phishers who spoof their domain in their attacks.
8.7.1
Background Email Firewall has always supported signing of outbound messages. However, the Proxy Encrypt and/or Sign policy type that supports this feature is a recipientbased policy. In order for this policy to be used to sign all outbound mail, an administrator would have to create a user record for all recipients. In addition, the signature applied by this policy type can only be one that uses a proxy certificate that is chained to the root certificate associated with the Email Firewall server. These types of proxy certificates do not chain to the root certificates of well-known certificate authorities (CAs) such as VeriSign Class 1, 2, or 3 or GTE Cyber Trust. These limitations are addressed by the Sender Signature policy type.
8.7 The Sender Signature Policy Type
391
8.7.2
Conceptual Overview The Sender Signature policy is a sender-based policy type that supports signing outbound messages to arbitrary recipients. When a Sender Signature policy is applied to a sender, the message will be signed if an appropriate certificate and the corresponding private key data are available in the Email Firewall database. Otherwise, the policy's failure action will be taken. This signing policy allows organizations to use an digital signature that positively identifies the sender of an email message. The Proxy Encrypt and/or Sign policy provides no optional catch or exception conditions. The Sender Signature policy is similar, although it does provide an optional catch condition that distinguishes Internal senders. The purpose of this option is to allow flexibility in message dispositions if a message that normally would require signing is sent from an internal source/sender. In this case, the signing requirements and policy action may be more lenient. The Proxy Encrypt and/or Sign policy is triggered when a message is not encrypted and the recipient's encryption algorithm and certificate are known to the Email Firewall Server. The Sender Signature policy is triggered when a message is not signed and the sender's signing certificate and private key data are found in the Email Firewall database. The failure action options provided in the Sender Signature policy are the same set provided in the Proxy Encrypt and/or Sign policy. In contrast to the Proxy Encrypt and/or Sign policy, the Sender Signature policy will never generate a proxy certificate for a user. The Sender Signature policy always uses the standard S/MIME algorithm for generating a clear-signed message. The policy does not provide the option to generate opaque-signed messages. The policy is not triggered if message already has a digital signature. In other words, the policy only applies to messages that are not already signed. The certificate used by the Sender Signature policy must be obtained from a third party Certification Authority (CA) and imported into Email Firewall before it can be used by the Sender Signature policy. See 9.5.1 Administrator Actions Required on page 451.
392
Chapter 8: Email Encryption and Authentication Overview
8.7.3
Email Firewall Signing Certificate Validation Before Email Firewall uses an imported certificate for signing, the certificate is validated according to the “Trust Level” chosen for the certificate. If an administrator selects Trust unconditionally for a certificate, Email Firewall does not perform any validation on the certificate before using the certificate to sign a message. The success action (deliver normally) is still taken as long as the signing operation is successfully completed. If an administrator selects Trust according to certificate status for a certificate, Email Firewall performs validation checks on the certificate before using the certificate to sign a message. Enabling Email Firewall validation checking on the certificate helps to ensure that the email client receiving the message is able to verify the signature on the message. However, for Email Firewall to successfully validate the signing certificate, the following setup is required: 1.
The Root CA certificate of the CA that issued the certificate must be imported as a trusted root certificate under the Trusted Root section in the Setup > Security page.
2.
The certificate's trust level must be set to Trust according to certificate status.
3.
Any Intermediate CA certificates of the CA that issued the certificate must be imported under the S/MIME Certificates section in the Setup > Security page.
When Email Firewall has successfully validated the certificate, Web Admin will show the status of the certificate as Trusted in the Local Certificates section of the Setup > Security page. When attempting to apply a signature to a message with a certificate that is the Policy Engine validates the signing certificate for: Trusted according to certificate status,
• • • •
Expiration Key usage Revocation Chains to a trusted root
8.7 The Sender Signature Policy Type
393
If at the time of signing any of these tests indicate an invalid or inappropriate certificate, the Sender Signature policy triggers a failure action and an event is logged describing the reason. A failure action is taken in any of these cases: •
• •
When there is no signing certificate available in the Email Firewall database that matches the sender (FROM header) address on the message, or when the sender's private key data for the signing certificate is not available. When the message has no FROM header. When any other unexpected error conditions prevent the message from being signed.
For more information about setting up the Sender Signature policy type environment, see 9.5 Setting Up for Sender Signature Policies on page 451.
8.8
Understanding Certificate Harvesting 8.8.1
S/MIME Certificate Harvesting When an email message sent with an S/MIME digital signature is constructed, the message will also contain the public key of the certificate used to signed the message. Where such a message is received, Email Firewall will automatically harvest the public key associated with the message, so that it can be associated with a user record and used for S/MIME proxy encryption. Often organizations will publish the cert-query address for outside parties to volunteer their certificates to.
8.8.2
OpenPGP Key Harvesting The RFC 3156 specification defines a format for distributing PGP keys. This defines the application/pgp-keys MIME content type. EMF supports the harvesting of PGP keys from this type of message into the EMF database. A single message can contain multiple PGP keys. EMF imports all the keys in a message and stores each single PGP key in the EMF database. To allow for clients that do not create messages of an appropriate format (MIME message with the application/pgp-keys MIME content type), EMF provides a well known email address, pgp-keys@, to which key
394
Chapter 8: Email Encryption and Authentication Overview
distribution messages can be sent to be harvested. The message must have an ASCII armored transferable Public Key Packets as defined in RFC 2440. Keys harvested via the well-known address are automatically trusted for cryptography purposes (encryption, authentication, etc.), but the administrator is still required to associate each of the keys to a user record in the EMF directory.
8.9
Understanding Certificate and PGP Key Responders Before you can send and receive secure messages, both the sender and recipient must exchange certificates or PGP keys. To assist with this process, the Email Firewall Certificate Responder and PGP Key Responder provides a means for external users to query for and obtain certificates from the Email Firewall server automatically. Both server certificates for an SPN, and proxy certificates and PGP keys for server-to-client security, can be obtained using this feature. For more information about proxy security, see 8.5 Email Firewall Server-to-Client Proxy Security on page 375. The Certificate Responder is invoked by an external user sending an email message to the special email address: cert-query@. The value of the Subject field specifies whether the query invokes the proxy certificate or the server certificate. The PGP Key Responder is invoked by an external user sending an email message to the special email address: pgp-keyquery@. The value of the Subject field specifies whether the query invokes the proxy certificate or the server certificate.
8.9.1
Certificate Responder and Server Certificates If the Subject field in the email to cert-query contains a domain name corresponding to a local secure domain, the Certificate Responder in the Email Firewall Server will automatically reply to the query with a signed message. The signed message is from the email address
[email protected] but it is signed using the corresponding local secure domain's proxy signing certificate (
[email protected]).
8.9 Understanding Certificate and PGP Key Responders
395
If the external S/MIME email client accepts a message which has a different signer and sender, then the external user can extract the signer certificate, save it, and import the certificate into the external email client's Trusted Root Certificate Authorities list or Trusted Signers list. In a typical scenario, however, the external S/MIME email client will not accept a message which has a different signer and sender. In this case, the external user should follow the instructions on how to import the server certificate into her S/MIME email client's Trusted Root Certificate Authorities list or Trusted Signers list. See Publishing the Certificate as a Root Key on page 436.
8.9.2
Certificate Responder and Proxy Certificates If the Subject field in the email to cert-query contains the email address of a local proxy user, the Certificate Responder will automatically reply to the query with a signed message. The signed message is from the email address of the local proxy user and is signed by the proxy certificate of the local proxy user. If the external user digitally signs the email sent to certquery, the certificate used to sign the email will be automatically imported to the Email Firewall Certificate database.
If the proxy certificate is available, it will be returned to the external user as a reply message. If a proxy certificate is not available, the Certificate Responder will automatically create the proxy certificate on the fly. The external user can then extract the signer's certificate from the reply message and install the signer’s certificate in the certificate store of her S/MIME email client. The Certificate Responder will return the proxy certificate (in the form of a signed reply) only if the local proxy user is identified in the Email Firewall Directory.
8.9.3
Understanding PGP Key Responder EMF has a PGP equivalent to the certificate responder called the PGP Key responder. The key responder provides a means for external users to query for and obtain Domain PGP Keys and proxy PGP user keys. The PGP Key Responder uses the special email address pgp-keyquery@. The value of the subject field specifies
396
Chapter 8: Email Encryption and Authentication Overview
whether the query returns a Domain PGP Key or a user PGP key. If a domain name is specified as the value, then a Domain PGP Key, if available for that domain, will be returned. The PGP Key that is returned is returned as a plain ASCII text in the body of the response, as defined in RFC 3156. If a query requests a PGP key for a proxy user (i.e. a user that has a Proxy Decrypt and Verify policy applied) and a PGP Key does not currently exist for that user, then EMF will generate a PGP Key for the user, sign it with the Domain PGP Key, and return this PGP Key to the requestor.
8.10 Third-Party Certificates and Email Firewall The PrivateKeyWizard tool allows you to import a third-party key pair and the associated server certificate into the Email Firewall database. This tool imports certificates and the corresponding private keys that represent the domain or domains that are protected by Email Firewall. See 9.2.4 Importing Third-Party Server Certificates on page 438 for instructions on how to use the tool. The input to this tool is a file that contains the certificate and the private key of a server. This file must be formatted according to the industry standard PKCS#12 specification. The PKCS#12 file typically uses the extension .p12 or .pfx. For example, Microsoft tools use the .pfx extension, while Netscape, Entrust and other tools use the .p12 extension. The certificates imported using the PrivateKeyWizard are displayed in the Email Firewall Setup > Secure Domains & Local Certificates page Local Certificates tab. When certificates are imported using this tool, the local secure domains are not created automatically. They must be created separately and the certificates imported using this tool must then be manually associated with the local secure domains. See 9.6.1 Defining and Associating Local Secure Domains on page 458 for instructions. Multiple local secure domains can share the same certificate. Email Firewall does not prevent such usage. Whether using Email Firewall-generated certificates or thirdparty certificates, Email Firewall allows using the certificate of one domain for a different domain.
8.10 Third-Party Certificates and Email Firewall
397
8.10.1 Supported Third-Party Server S/MIME Certificates Tumbleweed has done explicit testing with Entrust and VeriSign certificates for use with SPN and supports the following server certificates issued by Entrust and Verisign Certificate Authorities: • • •
For Entrust, only Entrust Certificate Authorities that are based on the Entrust/PKI 6.0 version software are supported. For Entrust certificates, only single keys are supported. The single key option must be configured properly to be used with Email Firewall. For VeriSign, the public VeriSign Class3 Certificate Authority is supported.
Additionally, the following general information is provided about how Email Firewall uses and interacts with a Server certificate: •
•
The Email Firewall Server Certificate should be an S/MIME server certificate, although a certificate obtained for use with a secure Web server (HTTPS) may also be used. To enroll for a VeriSign certificate, use the same procedure used to obtain a certificate for a secure web server. Refer to the web server documentation for instructions on how to obtain the certificate. If the server certificate will be used for Client-to-Client security and plaintext access policies, then the server certificate must have an email address (must have an E attribute in the Distinguished Name) for the subject. In this case, the email address must be in the form Security page, Trusted Root Keys tab. This enables Email Firewall to automatically trust the certificates issued by these VeriSign root certificates. Any intermediate CA certificates must be available (and if not available, must be imported) under the S/MIME Certificates tab.
8.10.2 Third Party TLS Certificate Requirements The domain name in the TLS server certificate should match the MX host name that clients will be using to locate the SMTP server. There will be complications with Email Firewall deployments using multiple inbound SMTP relay hosts with different names in the DNS. The corresponding root certificate may need to be imported and then trusted for use in TLS operations. The option to require strong encryption is enabled by default. For instructions on setting up TLS certificates for use in Email Firewall, see 9.4 Setting Up Certificates for TLS on page 445. Before a certificate is allowed to be used for TLS, Email Firewall will check to verify that the settings are valid for TLS.
8.10 Third-Party Certificates and Email Firewall
399
8.10.3 SMG Mode Certificates Email Firewall has implemented the Open Group’s standards-based requirements for creating an S/MIME Gateway with SMG mode certificates. SMG mode certificates are called “Domain Certificates” and have the same format as S/MIME Version 3 certificates. Certificate naming and other considerations for SMG mode-compliant encryption and signing certificates include: • •
Inclusion of a commonName (CN) attribute in the Subject Distinguished Name (DN) of the certificate containing the value domain-authority. The Subject DN or a subjectAltName extension must list at least one Internet mail domain of the form domain-authority@domain.
Additional requirements are listed below, and the differences between Email Firewall SPN certificates and SMG mode certificates are also explained: •
•
•
The email address in the SMG mode certificate’s subjectAltName is domain-authority@. In an Email Firewall SPN certificate, the email address in the subjectAltName is Secure-Server@. When a certificate is selected for SMG mode use, the RSA key length is hard-coded at 1024-bits. In an Email Firewall SPN certificate, the key length may be selected from among a number of lengths. The SMG mode certificate’s symmetric key cipher will always use 3DES. In an Email Firewall SPN certificate, the symmetric key cipher can be selected from among a number of types.
8.11 Third Party PGP Keys and Email Firewall The PrivateKeyWizard tool allows you to import a third-party PGP key pair into the Email Firewall database. Unlike S/MIME, there is no concept of importing a domain key, as Email Firewall does not use PGP for gateway-to-gateway encryption. The PrivateKeyWizard is therefore used only to import PGP key pairs for individuals, where Email Firewall is to take over encryption/signing on their behalf using an existing PGP key pair. The input to the tool is an ASCII armored Key File, usually with a .asc file extension.
400
Chapter 8: Email Encryption and Authentication Overview
Once a user’s private PGP key has been imported, Email Firewall is able to perform encryption and signing operations on behalf of that user at the gateway using a Proxy Encrypt and/or Sign policy.
8.12 Understanding Certificate Rollovers An S/MIME server certificate represents one or more domains in an Email Firewall environment. These domains are called local secure domains and their certificates are managed as described in 9.2 Setting Up Key Pairs and Certificates for S/MIME on page 433. The certificates can be self-generated, or can be issued by supported third-party certificate authorities. S/MIME certificates are required for both SPN (secure server-to-server) links and proxy (secure server-to-client) links. However, on occasion these certificates can become invalid. A server certificate can become invalid for a number of reasons: •
•
•
The certificate has expired. Self-generated certificates are valid for 10 years. In some previous versions of Email Firewall the self-generated certificates were valid for two years. These certificates may have been migrated to Tumbleweed Email Firewall 6.1. The validity period of certificates issued by third-party CAs will vary depending on the CA. The certificate has been revoked, and Email Firewall has access to the relevant CRL from the certificate issuer. See 9.10 Downloading Certificate Revocation Lists on page 500. The certificate has been compromised, and the Email Firewall administrator wants to replace the certificate.
When a certificate becomes invalid, it is unusable for security purposes and must be replaced. The replacement process for updating the certificate is called a certificate rollover. The rollover of the server certificates must be coordinated with all SPN partners and proxy partners with whom the Email Firewall server has exchanged the old certificate. This section describes the certificate rollover preparation and process. You should carefully review this section before attempting to roll over any S/MIME certificates, especially if you use proxy security. When you understand the rollover process, see 9.9 Rolling Over S/MIME Certificates on page 497 for instructions for the rollover procedure.
8.12 Understanding Certificate Rollovers
401
8.12.1 Server Certificate Expiration and Proxy Security When a server certificate used for proxy security expires, all the proxy certificates issued by that server certificate become invalid and unusable. This is because proxy certificates inherit the validity period of the issuing server certificate. There is an important distinction between server certificates and proxy certificates in this regard: a self-generated server certificate is Explicitly trusted in the Email Firewall server and is therefore deemed valid and usable by Email Firewall even after it expires. Proxy certificates, in contrast, are Trusted according to certificate status, and so are treated as expired and invalid when the server certificate expires. In other words, when a server certificate used for proxy security expires, both Email Firewall and the email client used by the external user will consider the expired proxy certificate invalid and unusable. When this happens: • • • •
Email Firewall will fail to process incoming mail to the internal user because decryption using the proxy certificate will fail. Email Firewall will fail to process outgoing mail from the internal user because signing using the proxy certificate will fail. The email client used by the external user will fail to encrypt using the proxy certificate. The email client used by the external user will fail to verify the signature using the proxy certificate.
Whenever a server certificate used for proxy security must be rolled over, it should be rolled over so that the transition for both internal and external proxy security users is graceful.
402
Chapter 8: Email Encryption and Authentication Overview
8.12.2 Certificate Rollover Coordination Required Rollover of the server certificate must be coordinated with all SPN partners and proxy partners. For the Email Firewall administrator, this means: • • •
New server certificates must be distributed to all SPN partners with a request that they use the new certificate instead of the old certificate. Proxy partners must be informed that the server certificate and all the proxy certificates issued by the server certificate will become invalid. Proxy partners must be requested to obtain the new server certificate and new proxy certificates issued by the new server certificate, for each of the internal users with whom they exchange S/MIME email.
If there are multiple SPN and proxy partners, it may be difficult to coordinate the certificate rollover with all partners simultaneously. For this reason, the server certificate rollover period can occur over a period of time, to allow the SPN and proxy partners to gradually replace the old certificates with the new certificates. During this time, both the old and the new certificates can be used and both should be valid. During the rollover period, the new server certificate is generated (or imported) and distributed to SPN partners, but you can continue to use the old server certificate to sign outgoing messages. SPN partners can then use either the old server certificate or the new server certificate to send S/MIME messages to internal users. Both the old and the new server certificates should be valid during this time. Likewise, during the rollover period, the new server certificate is distributed to proxy partners, so they can prepare for the certificate rollover. Proxy partners can continue to use the old server certificate and proxy certificates during the rollover period. They should migrate to the new server certificate and new proxy certificates by the end of the rollover period. By the end of the rollover period, the new server certificate is used for the local secure domain(s).
8.12 Understanding Certificate Rollovers
403
8.12.3 Certificate Rollover Preparation Checklist Following are general preparedness items for certificate rollovers: 1.
Check monthly to see whether any server certificate will expire in the next six months. The Set Up > Security page Local Certificates tabs show the expiration date for certificates.
2.
If a certificate in the Local Certificates list will expire in the next six months, plan for certificate rollover.
3.
Decide the start and end date of the certificate rollover period. The end date must be before the old certificate expires and the start date can be a month or two before the end date. During the rollover period, both the old and the new certificates must be valid.
4.
If the reason for the update is that the certificate has been revoked, then you may want to perform the update immediately, without an extended rollover period. The old local server certificate should not be deleted until all SPN and proxy partners have switched to use the new certificate. Otherwise Email Firewall will be unable to decrypt mail from that partner.
5.
Begin the certificate rollover process.
8.12.4 Certificate Rollover Process Concepts A successful certificate rollover process requires an understanding of the steps and consequences of replacing an old S/MIME certificate with a new one. The following sections explain the concepts behind the process and the reasons for taking each step.
Generate or Import the New Certificate At the start of the certificate rollover period, the Email Firewall administrator must generate or import the new server certificate. This certificate will not immediately be associated with the local secure domains. This means that the old server certificate will continue to be used to sign all S/MIME emails going out to SPN and proxy partners.
404
Chapter 8: Email Encryption and Authentication Overview
Distribute The New Certificate During the certificate rollover period, the new server certificate is distributed to all SPN partners with a request that they migrate to the new server certificate. During the rollover period, Email Firewall should be able to process (decrypt) email from SPN partners who have migrated to the new certificate and also from SPN partners who use the old certificate. When sending S/MIME email to SPN partners, you continue to use the old certificate for signing so that any SPN partner not yet using the new certificate will still be able to process (verify signature on) inbound S/MIME email. Because the old certificate will continue to be used, you should advise all SPN partners to keep the old certificate until the end of the rollover period. During the rollover period, proxy partners will continue to use the proxy certificates issued by the old server certificate. They cannot obtain the proxy certificates issued by the new server certificate until it is associated with the local secure domain(s) as the proxy signing certificate. However, it is still useful to distribute the new server certificate to all proxy partners during the rollover period, and ask them to import the new certificate as a Trusted Root in their email client. The benefit of distributing the new server certificate to proxy partners in advance is that once the new certificate is used for proxy signing (at the end of the rollover period), proxy partners will be able to receive S/MIME email signed by proxy certificates issued by the new certificate.
Associate the New Certificate with the Local Secure Domain At the end of the rollover period, the new server certificate must be associated as both the SPN-signing certificate and the proxy-signing certificate for the required local secure domains. After the new server certificate is associated as both the SPN signing certificate and the proxy-signing certificate for the required local secure domains: •
Email Firewall starts signing all outbound email to SPN partners with the new server certificate. An SPN partner who has not migrated to the new certificate will not be able to process (verify signature on) inbound S/MIME email signed by the new certificate. To enable S/MIME processing, the SPN partner should associate the new certificate with your domain record in their Email Firewall database.
•
Email Firewall starts signing all outbound email to proxy partners using proxy certificates issued by the new server certificate. 8.12 Understanding Certificate Rollovers
405
Any proxy partners who have not imported the new server certificate as a Trusted Root in their email client may not be able to open S/MIME email from their internal proxy correspondents, because their email client does not trust the new proxy certificate. To enable S/MIME processing, the proxy partner must import the new server certificate as a Trusted Root in their email client. •
•
Email Firewall continues to process (decrypt) any S/MIME email from an SPN partner that is encrypted using the old server certificate until the old server certificate is deleted. Email Firewall continue to process (decrypt) any S/MIME email from a proxy partner that is encrypted using proxy certificates issued by the old server certificate until the old server certificate and the proxy certificates issued by the old server certificate are deleted.
Complete the Rollover To ensure successful completion of the certificate rollover, the Email Firewall administrator must: • •
•
Encourage any remaining SPN partners to migrate to the new server certificate. Inform proxy partners to obtain and use proxy certificates issued by the new server certificate for each of the internal users with whom they exchange S/MIME email. This information can be communicated: • out-of-band, or • by setting up a policy that adds an annotation or sends a notification informing the proxy partners that they should obtain and use the new proxy certificates issued by the new server certificate. After confirming that all SPN partners have migrated to use the new server certificate, and that all proxy partners have migrated to use the new server certificate and proxy certificates issued by the new server certificate, the old server certificate can be deleted. When the old certificate is deleted from the Local Certificates list it is automatically deleted from the Trusted Roots list as well.
406
Chapter 8: Email Encryption and Authentication Overview
Certificate Rollover Completion Wrap-Up and Consequences After the old server certificate is deleted: • •
Email Firewall cannot process (decrypt) any S/MIME email from an SPN partner that is encrypted using the old server certificate. Email Firewall cannot process (decrypt) any S/MIME email from a proxy partner that is encrypted using proxy certificates issued by the old server certificate.
After the old server certificate is deleted, the Email Firewall administrator should: • Inform all SPN partners to delete the old server certificate from their Email Firewall database. • Inform all proxy partners to delete the old server certificate and the proxy certificates issued by the old server certificate from the certificate store used by their email client.
8.12.5 Proxy PGP Key Rollover The general concepts and steps involved in rolling over a PGP key are similar to those for an S/MIME certificate. The process is somewhat simpler as PGP keys are used only for proxy encryption and so there is no need to consider gateway-to-gateway encryption when rolling over the key. The PGP Keys generated by Email Firewall have a default expiration of three years. This expiration cannot be changed. It will be necessary to roll over the domain PGP key when the key has expired, or if it is believed that the key has been compromised. To enable key rollover, a new Domain PGP Key should be generated and associated with the Local Secure Domain. EMF will detect this change, and will start to generate new Proxy PGP Keys. PGP Key rollover requires that remote PGP users re-acquire the PGP key for the internal user and the Domain PGP Key.
8.12 Understanding Certificate Rollovers
407
8.13 The PGP Trust Model PGP has a very flexible trust architecture that allows for direct trust and can be configured to support a form of hierarchical trust. This architecture also allows a “web of trust” to be established, whereby a determination is made based on the trust associated to many different keys as to whether to trust a particular key. EMF only supports direct trust for PGP keys. The trust is not based on the digital signatures associated with a PGP key, but on the association of the PGP key to an EMF directory record. However if configured, EMF signs all proxy PGP keys with the Domain PGP Key to allow external PGP users to associate trust to the Domain PGP Key. This allows them to trust all PGP keys that are generated by EMF.
8.14 Trust and Interoperability of S/MIME Certificates Before you can send and receive secure messages, both the sender and recipient must generate and/or exchange unique key pair and server certificates. Server certificates are required for all secure email exchange using Email Firewall server-to-server Secure Public Networks (SPNs), SMG mode communications, or server-to-client SPN-proxy security. You may need to provide the server certificate as a root key for server-to-server SPNs. If you use proxy security, you are likely to need proxy certificates as well. A key pair consists of two parts: • •
A private key that you keep secret and use to decrypt inbound messages and sign outbound messages. A public key that you publish to the world so that others can encrypt messages for you and verify your signature.
In most cases, public keys are contained in certificates that are digitally signed by a certificate authority. The certificate verifies the identity of the key owner. Email Firewall acting as a Certificate Authority (CA) can generate key pairs and their corresponding certificates, exchange certificates with other servers, store
408
Chapter 8: Email Encryption and Authentication Overview
them in its database, and associate them with the appropriate domain records. You will also need to export your certificate to allow others to use it. Before generating a key pair, you must know the maximum key sizes that your correspondent’s software can process. See 8.14.1 Understanding Key Size Issues for more information.
Email Firewall certificates currently expire ten years after they are generated. Certificates generated by previous versions of Email Firewall may expire in two years, so those certificates need to be updated more often. Certificates imported from external PKIs will vary with regard to their expiration time. See 9.9 Rolling Over S/MIME Certificates on page 497 for information and instructions. Email Firewall has tested and supports use of certificates from two third-party vendors, Entrust and VeriSign. Their certificates are imported using the PrivateKeyWizard utility. See 10.6 Using the PrivateKeyWizard Tool on page 568 for more information. Use of third-party certificates is only supported for server-to-server SPNs and SMG mode; it is not supported for proxy usage. For Entrust certificates, only single keys are supported. The single key option must be configured properly to be used with Email Firewall. For more information, see 8.10.1 Supported ThirdParty Server S/MIME Certificates on page 398. A PGP Key has a public and a private key part. The Public Key is self signed, and can be signed by other parties that trust this key, to make the PGP equivalent of a certificate. This is known as the PGP Public Key.
8.14.1 Understanding Key Size Issues S/MIME specifies a combination of symmetric (private key) and asymmetric (public key) encryption. The size of the symmetric key is specified during message encryption. (In Email Firewall, it is specified ahead of time in the recipient’s Email Firewall Directory record.) The size of the public key is specified during key pair creation. The longer the key, the stronger the encryption. Before exchanging certificates or creating Email Firewall Directory records, you must determine the maximum key sizes that your correspondents’ software can process. In secure communication, if one party uses keys that are too long
8.14 Trust and Interoperability of S/MIME Certificates
409
for the other party, communication will fail. For SMG mode, the required key length is 1024-bits. Email Firewall can send and receive up to 256-bit private keys and 2,048-bit public keys. While there are currently no restrictions on exporting the Email Firewall product to non-terrorist nations, if you want to communicate securely with a correspondent outside of the US and EEU, you may want to ascertain the maximum key size your correspondent’s software can process before generating a certificate to use with that correspondent. Figure 8.6 shows the key pair length selections available when setting up a new key pair. SPNs are created by exchanging certificates. Before establishing an SPN with the external organization or domain, you must create a new key pair and certificate that will identify you to the external organization or domain. When you generate a key pair and server certificate, you specify the email domain for which they are being generated. Therefore it is best to generate one key pair and server certificate for each domain that is protected by Email Firewall. Proxy certificates are based on the server certificate that most closely matches the user’s domain. For instructions on generating a key pair and certificate, see 9.8.3 Generating a Key Pair and Certificate on page 476. Figure 8.6: Generating Keys
410
Chapter 8: Email Encryption and Authentication Overview
8.14.2 Understanding Root Key Purposes The root key shows the details extracted from the root certificate. It also shows the purposes that have been enabled for the root key. These purposes define what the certificate is trusted for. See Figure 8.7. When a root key is generated by Email Firewall or imported from a third-party, the Trusted For: S/MIME Operations option is enabled by default.You can specify the other purposes for which a root key may be used. Root key purposes include: • •
•
•
for regular S/MIME use (enabled by default). This purpose cannot be disabled. Auto Certificate Association with End User Records as specified in an Email Firewall policy. Mark this checkbox to enable this purpose if you will be using an Email Firewall policy to provide automatic certificate associations between user records and the certificates associated with those records for server-to-client encryption, or proxy security. See 8.5.2 Email Firewall and Automatic Certificate Association. on page 382. When the Auto Certificate Association policy is triggered, the Policy Engine associates the certificate with the appropriate user record only when the certificate chains up to a root certificate that has this purpose enabled. Auto Certificate Lookup of End User Certificates as specified in an Email Firewall policy. Mark this checkbox if you will be using an Email Firewall policy to specify real-time lookup of end-user certificates for server-toclient encryption, or proxy security. See Automatic Lookup of User Certificates on page 381. When the Auto Certificate Lookup policy (the Proxy Encryption and/or Sign policy with the Auto Certificate Lookup enabled) is triggered, the Policy Engine performs an automatic lookup of certificates only when the lookedup certificate chains up to a root key that has this purpose enabled. TLS as specified in the Email Firewall SMTP Relay setup. Mark this checkbox if you will be using this certificate for the purpose of TLS checking. This purpose may not be combined with the Auto Certificate operations; TLS requires a certificate enabled only for TLS and S/MIME Operations. See 8.10.2 Third Party TLS Certificate Requirements on page 399. S/MIME Operations
8.14 Trust and Interoperability of S/MIME Certificates
411
8.14.3 Understanding S/MIME Interoperability Issues Trust and association of certificates are handled differently by different S/MIME and applications, and issues of trust can arise when using proxy security. As a result, this sometimes requires additional configuration for S/MIME proxy certificates to be effective.
Trusting a Certificate Before an S/MIME application will use a certificate, it requires that the user establish trust of the certificate, to ensure that the certificate actually belongs to the person it is supposed to. There are two ways to establish trust: •
•
Trust According to Certificate Status, where the certificate is digitally signed by a certificate authority (CA) and the S/MIME application contains the CA’s root key. When an S/MIME application contains a root key, it trusts the root key and, by association, trusts all certificates issued by that CA. This is also known as chain trust. Direct Trust, where the user contacts the owner of the certificate and verifies the certificate fingerprint. Direct trust is useful when a certificate is self-signed, rather than signed by a certificate authority, or is signed by a certificate authority that you do not know.
The SPN server certificates generated and used by Email Firewall are selfsigned. For imported certificates, Trust According to Certificate Status is used.
Trusting Self-Signed Certificates While some applications allow direct trust, many allow only trust according to certificate status. In such applications, the only way to trust a self-signed certificate is to import the self-signed certificate into the application as a root key. Some applications require a special mechanism to import a root key. For example, an application might require the root key to be published on a Web page and then imported using a specific MIME type at the HTTP layer.
412
Chapter 8: Email Encryption and Authentication Overview
Associating an Email Address with a Certificate While some S/MIME applications allow the user to associate any certificate with any email address, other applications require that the email address in a certificate exactly match the email address with which the certificate is associated.
Associating Self-Signed Certificates Because the Email Firewall certificate represents multiple Email Firewall users, it does not contain individual users’ email addresses. Thus, in S/MIME applications that require the email address in the certificate to match the email address with which it is associated, the following incompatibilities exist: • • •
The Email Firewall certificate cannot be associated with a specific user in those S/MIME applications. Those S/MIME applications cannot encrypt mail to Email Firewall users. Those S/MIME applications cannot verify digital signatures in mail from Email Firewall users.
Email Firewall solves these interoperability issues. While server certificates address the incompatibilities of association, Email Firewall proxy certificates address the incompatibilities of trust.
Understanding Server or Role Certificates in Email Firewall Historically, S/MIME certificates have been either personal certificates, issued to individuals to secure email from one desktop to another, or root certificates, issued to certificate authorities to sign personal certificates. That model is very effective for a private individual isolated from corporate security policies. But it is impractical for the administrator who must secure mail across the enterprise for hundreds or thousands of people over multiple domains. To resolve the incompatibilities of association and better fit the security needs of the enterprise, Tumbleweed has refined and augmented use of the server certificate. An Email Firewall certificate is a certificate that is used for a specific role or purpose, and not necessarily or exclusively on behalf of a specific individual. Email Firewall generates a self-signed server certificate and uses it to perform S/MIME operations on behalf of users. The primary server certificates are also sometimes referred to as role certificates, because they represent the role of the secure server. These
8.14 Trust and Interoperability of S/MIME Certificates
413
certificates represent the server itself and contain the email address of the server, e.g., . If the server will be performing proxy security, then proxy certificates can be generated and used instead. Proxy certificates are issued on-the-fly, under the server certificate for a given domain.
Understanding Proxy Certificates in Email Firewall A proxy certificate is a certificate issued by the server certificate to associate a specific Email Firewall user’s email address with the issuing Email Firewall server certificate. The contents of the server certificate and the proxy certificates it creates are virtually identical. Proxy certificates contain the same information as the server certificate that they are issued under, except that they contain the email address of the proxy user. For example, a server certificate for company.com and a proxy certificate it issues for an employee named Casey Mann might be as follows: •
Server Certificate for company.com CN (Common Name) Company Inc. Secure Server (EA) Email Address
•
Proxy Certificate for a user named Casey Mann CN (Common Name) Company Inc. Secure Server (proxy) (EA) Email Address
[email protected]
[email protected]
An installation of Email Firewall typically has one server certificate for each domain, and each server certificate issues proxy certificates for email addresses in its domain. Once issued, a proxy certificate is stored locally and Email Firewall uses it to perform proxy S/MIME operations on behalf of the user with that particular email address. A proxy certificate appears as an individual user certificate whose issuing certificate was the Email Firewall server certificate. In S/MIME clients that require trust according to certificate status, the user can import the Email Firewall server certificate as a root key. Once the root key is imported, the S/MIME client user can trust the proxy certificate and use it to encrypt mail to the Email Firewall user.
414
Chapter 8: Email Encryption and Authentication Overview
For proxy security, note that: • •
•
Proxy certificates are not displayed in the Web Administration user interface. Proxy certificates cannot be generated when using a third-party certificate. The Certificate Practice Statement and business policies of external PKI vendors prohibit Tumbleweed from issuing additional end-user certificates for this purpose. Proxy certificates cannot be generated underneath a domain certificate issued in SMG mode.
Figure 8.7: Root Key Properties and Purposes Trusted For
8.14 Trust and Interoperability of S/MIME Certificates
415
8.14.4 Email Firewall S/MIME Certificate Verification In Email Firewall, all S/MIME certificates are verified by checking: 1.
That the certificate chains to a valid, trusted root certificate in the Email Firewall Database. Root certificates can be generated by Email Firewall, or they can be imported.
2.
That the revocation status of all certificates in the chain is valid. The revocation status is determined by searching: • Any imported Certificate Revocation Lists • Any CRL Distribution Points listed in the certificates
3.
That the expiration date is valid.
4.
That the Basic Constraints extension (as per RFC 2459) is valid. The basic constraints extension identifies whether the subject of the certificate is a CA and how deep a certification path may exist through that CA.
5.
That the X.509 Key Usage (as per RFC 2459) is valid. The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. The usage restriction might be employed when a key that could be used for more than one operation is to be restricted.
Email Firewall looks only at the Key Usage extension (OID value: 2.5.29.15). If there is no Key Usage extension in the certificate, it is assumed that the certificate is suitable for both encryption and signing.
8.14.5 Establishing Trust Relationships Setting up encryption depends on trust among users of the encryption system. There are two central issues relating to certificates in regard to trust: •
•
“How is the information in a certificate secured and how can I trust that the name and public key in a certificate actually belong to the certificate’s owner?” “Is the issuing Certificate Authority trustworthy?”
Two forms of trust exist to address these different types of problems. •
416
Direct Trust (Point-to-Point), which allows you individually to validate and to trust each certificate manually. This model was created specifically by Tumbleweed to easily enable two organizations to establish a secure (encrypted) email channel. In this
Chapter 8: Email Encryption and Authentication Overview
•
model an individual at each organization will validate and trust each certificate manually. No certificate verification is performed with this model. Trust According to Certificate Status (Trust Hierarchy), which allows you to trust certificates signed by authorities you trust, called Certificate Authorities (e.g. VeriSign, Entrust, etc.). This model is commonly used in the security industry, and allows organizations to establish a hierarchy of trust enabling both email domains and end-users to establish a secure (encrypted) email channel. In this model Email Firewall provides security with S/MIME compatible domains and “proxy” security to users in an organization by encrypting, decrypting, signing, and verifying mail on their behalf. This allows users within an organization to send secure messages to external users who are not using an Email Firewall SPN. The certificate verification steps described in 8.14.4 Email Firewall S/MIME Certificate Verification on page 416 are applied in this model.
8.14.6 Certificate Authorities The purpose of the Certificate Authority (CA) is to issue and revoke certificates. CAs are identified by root keys, some of which are pre-loaded into S/MIME software such as Outlook Express. Each CA has a “guarantee” called a Certificate Practices Statement (CPS), which is a set of guidelines developed by the American Bar Association that defines an organization’s policies and practices for operating a certification authority. The CPS provides the means for both defining the applicability of digital certificates within a business community, and for providing legal protection in the event of disputes. Certificates are critical since they help provide a framework for validating Public Keys, which are the basis for secure transactions. Email Firewall acts as a Certificate Authority. Email Firewall also supports use of certificates from third-party vendors Entrust and Verisign for use in creating an SPN. Email Firewall is certified under the S/MIME Gateway Certification program for S/MIME Gateway mode operations.
8.14 Trust and Interoperability of S/MIME Certificates
417
Figure 8.8: Certificate Authority
418
Chapter 8: Email Encryption and Authentication Overview
8.14.7 Certificate Revocation Lists Certificates are critical to providing a framework for validating Public Keys. For this reason it is important to know when a certificate has been revoked. A certificate revocation list (CRL) is a list of certificates that have been revoked before their scheduled expiration date. There are several reasons why a certificate might need to be revoked and placed on a CRL. For instance, the key specified in the certificate might have been compromised or the user specified in the certificate may no longer have authority to use the key. For example, suppose a company vice president named Amanda Sanchez is associated with a key. If Amanda left the company, her former company would not want her to be able to sign messages with that key, and so the company would place the certificate on a CRL. When verifying a signature, the relevant CRL must be examined to be sure the signer's certificate has not been revoked. Whether it is worth the time to perform this check every time a secure email is received depends on the importance of the signed document. A CRL is maintained by a Certificate Authority, and it provides information about revoked certificates that were issued by that CA. CRLs only list current certificates, since expired certificates should not be accepted in any case: when a revoked certificate's expiration date occurs, that certificate can be removed from the CRL.
Obtaining CRLs CRLs are usually distributed in one of two ways. In the “pull” model, verifiers download the CRL from the CA, as needed. In the “push” model, the CA sends the CRL to the verifiers at regular intervals. A hybrid approach can also be used, where the CRL is pushed to several intermediate repositories from which the verifiers may retrieve it as needed. For example of a site from which CRLs can be pulled, Verisign CRLs are public information and can be seen and downloaded from . Although CRLs are maintained in a distributed manner, there may be central repositories for CRLs, such as network sites containing the latest CRLs from many organizations. A large enterprise might establish an in-house CRL repository to make CRL searches on every transaction feasible. Email Firewall supports importing CRLs by allowing you to: • • •
specify the location from which to download CRLs store the CRLs in the Email Firewall database for reference schedule recurring, automatic CRL imports 8.14 Trust and Interoperability of S/MIME Certificates
419
See 9.10 Downloading Certificate Revocation Lists on page 500 for instructions on using the Email Firewall CRL download functionality.
Scheduling CRL Downloads Using Email Firewall Web Administration, you can specify that CRLs be downloaded automatically on a scheduled basis. You can also download CRLs from multiple locations. To download CRLs, you must be able to connect to a remote location on a periodic basis to download a file from an http server. This download may use an intermediate proxy server. The Email Firewall Download service is responsible for processing the scheduled CRL downloads. It periodically polls the configured schedules and downloads the CRLs according to the schedule. As is the case with CRLs obtained from a CRL Distribution Point, in order for Email Firewall to successfully check a CRL, Email Firewall must have the CA root certificate imported as a trusted root key. CRLs that Email Firewall imports which do not have the root certificate imported as a trusted root key will not be checked because they cannot be trusted to have been issued by the CA. However, in this case Email Firewall will still cache the CRL to prevent unnecessary downloads of CRLs. For instructions on using this feature, see 9.10 Downloading Certificate Revocation Lists on page 500.
8.14.8 Email Firewall and CRL Distribution Points Many Certificate Authorities currently support the CRL Distribution Point certificate extension. This allows CRLs to be partitioned into smaller entities in which the certificate itself includes a reference to where the CRL can be found that will include the certificate if the certificate is revoked. The reference to the CRL Distribution Point can be specified in the certificate extension in several ways. Email Firewall supports the following types of references: • • •
420
URI of type HTTP (identified in the Distribution Point extension using the identifier uniformResourceIdentifier) URI of type LDAP (identified in the Distribution Point extension using the identifier uniformResourceIdentifier) Distinguished Name (identified in the Distribution Point extension using the identifier directoryName)
Chapter 8: Email Encryption and Authentication Overview
When a certificate contains multiple references to CRL DPs, Email Firewall selects and uses only one reference, according to the precedence described in 8.14.9 Email Firewall and CRL Processing Precedence on page 421. When the CRL DP reference of type Distinguished Name is selected, the LDAP server in which to search the CRL DP is identified by a separate configuration. See 9.11 Specifying the CRL DP LDAP Lookup on page 503 for instructions. As is the case with CRLs obtained from a scheduled CRL download, in order for Email Firewall to successfully check a CRL, Email Firewall must have the CA root certificate imported as a trusted root key. Email Firewall caches the CRLs imported from CRL Distribution Point references in the Email Firewall database. These CRLs remain valid until the nextUpdate time specified in the CRL. Unlike the Email Firewall Server, the Email Firewall Web Administration service does not try to access a CRL from the CRL DP reference. It uses the latest cached CRL DP. This can lead to a rare situation when the Web Admin shows a recently revoked certificate as valid, whereas the Email Firewall Server deems such a certificate unusable.
8.14.9 Email Firewall and CRL Processing Precedence This section describes the order in which Email Firewall checks CRLs. 1.
If a scheduled CRL import is configured for a CA, and a certificate issued by that CA is received by Email Firewall, then Email Firewall will use the imported CRL.
2.
If no imported CRL is found, Email Firewall will check for a CRL DP reference in the certificate. Email Firewall checks in the following order: • first for an http URI in the CRL DP (e.g., http://crl.verisign.com/class1.crl)
• then for an LDAP URI in the certificate (e.g., ldap://ldap.tumbleweed.com/o=Tumbleweed,c=US)
• then for a DirectoryName reference in the CRL DP 3.
On finding an appropriate CRL DP, Email Firewall will use that information to find and import the CRL into the Email Firewall database.
8.14 Trust and Interoperability of S/MIME Certificates
421
4.
If a CRL is not successfully imported, Email Firewall will not try any of the remaining CRL DPs. It will consider the revocation status to be unknown. When Email Firewall encounters a certificate with an unknown revocation status, it considers the certificate a valid and usable certificate.
5.
Once a CRL is imported as the result of a CRL DP reference, Email Firewall will use the locally stored CRL until the nextUpdate time specified in the CRL.
8.15 Frequently Asked Questions Q: Do you support inline PGP? A: No, EMF only supports OpenPGP, as this is the IETF standard. Q: Can I do LDAP lookups to find OpenPGP keys? A: No, EMF would not be able to explicitly trust the PGP keys retrieved from an LDAP server without compromising security. In S/MIME this trust can be established by chaining to a trusted root key. Q: How are private keys stored? A: They are stored encrypted in the database. Q: Why can’t I see proxy certificates in the Security Set Up pages? A: You aren’t supposed to. Proxy certificates are internal to Email Firewall and do not require administrators to configure or manage them. Q: If an external user requests a certificate for a particular email address corresponding to one of my internal users, what certificate will the Email Firewall Certificate Responder return?
422
Chapter 8: Email Encryption and Authentication Overview
A: The Certificate Responder returns the requested certificate by sending an S/MIME response to the requester. The S/MIME response is signed and encrypted using the private key/certificate that the Certificate Responder is able to find in the following order: • •
A proxy certificate already created for the email address. A proxy certificate generated “on the fly” by the server certificate whose domain matches the domain of the email address. This occurs only if the Enable Proxy Certificate Usage checkbox is marked on the S/MIME Certificates tab.
If a user record is present for the email address and an external certificate is associated with the user record, the certificate is added in the response as an attachment named cert.p7c. Q: Can I use the same certificate for an Email Firewall SPN and TLS? A: No. A separate certificate for TLS must be obtained from a third-party CA and specifically enabled for TLS. Q: Is there a difference between an Email Firewall that sets up S/MIME to other domains in SPN mode versus SMG mode? A: Yes; the main difference is interoperability with other vendor’s gateways that support S/MIME. Setting up S/MIME in SMG mode guarantees interoperability with the other vendor's gateway if they are also SMG compliant. Setting up an S/MIME connection in SPN mode may provide interoperability with another vendor’s gateway, but is it not guaranteed. There are also several minor differences between SPN and SMG in the way certificates are generated and exchanged. See 8.3 Email Firewall Gateway-to-Gateway Security on page 369 for more information.
8.15 Frequently Asked Questions
423
8.16 Commonly Used Security Terms This section contains definitions for commonly used security-related words and phrases. A working knowledge of these terms will assist in understanding the sections following.
Certificate An electronic document that has been digitally signed by an individual or a certificate authority who will vouch for its authenticity, and which links a public key to a person or a company. Certificates help to ensure that the public key you are using to encrypt a message to an individual is actually the recipient’s public key, and that no one has tampered with it. The email address of the certificate holder is located in the SubjectAltName field of a typical certificate.
Certificate Authority An entity whose primary responsibility is issuing and signing public key certificates. A certificate is authentic to the extent specified by the certificate authority’s issuing policy.
Certification Practice Statement A document that details the criteria that a certificate authority uses to issue a certificate. Before you trust a certificate, you should read and understand the Certificate Practice Statement behind the certificate.
Certificate Revocation List (CRL) A digitally signed list of suspended or revoked certificates issued periodically by a certificate authority. The list contains the CRL issuer’s name, the date of issue, the date of the next scheduled CRL issue, the suspended or revoked certificates’ serial numbers, and the specific times and reasons for their suspension or revocation.
CRL Distribution Point A certificate extension that allows CRLs to be partitioned into smaller entities in which the certificate itself includes a reference to where the CRL is that will include the certificate if the certificate is revoked. The reference to the
424
Chapter 8: Email Encryption and Authentication Overview
certificate is given as a Uniform Resource Identifier (URI), with the common types being HTTP and LDAP.
Chain Trust, or Trust According to Certificate Status A method of establishing the trust of a given certificate by following a logical chain of valid certificate signatures to a trusted certificate authority’s root key.
Decryption The process of decoding information.
Digital Signature An algorithm applied to a file that gives correspondents a verifiable way to ensure that a file or a message they receive from you did in fact come from you and that it has not been altered.
Encryption The process of encoding information so that it is unreadable without a decryption key.
Fingerprint A unique hash value that identifies a certificate and can be used to verify its authenticity.
Key Random or pseudorandom strings, generated by an automatic process, that allow a user to encrypt and decrypt secure messages. A key is what locks and unlocks S/MIME and OpenPGP messages.
OpenPGP A standard for encrypting and signing e-mails using digital certificates based on PGP (Pretty Good Privacy) keys.
8.16 Commonly Used Security Terms
425
Private Key One of a pair of digital keys used to encrypt and decrypt messages. This is the key you keep secret to decrypt the messages that you receive and sign the messages that you send. Private keys are stored encrypted in the Email Firewall database.
Public Key One of a pair of digital keys that you use to encrypt and decrypt messages. This is the key you send to correspondents so that they can encrypt messages to you and decrypt your signature. The security of a message is determined by the length of the key used to encrypt the message. The longer the key, the more complex the algorithm. The more complex the algorithm, the more secure the message. While key lengths inside the United States are not restricted, the U.S. Government does not allow the export of some key lengths to listed terrorist nations.
S/MIME Secure Multipurpose Internet Mail Extension: A standard for encrypting and signing e-mails using digital certificates based on X.509v3.
SMG S/MIME Gateway (SMG) is the specification for interoperability among gateway-to-gateway S/MIME vendors - http://www.opengroup.org/smg/cert. When email domains have exchanged SMG mode-compliant, S/MIME Version 3.1 certificates, a secure messaging link is established between the two email domains. When an S/MIME Gateway is established, Email Firewall automatically encrypts and optionally digitally signs the mail that flows between the two domains. You should consider configuring the Email Firewall in SMG mode with all new domains for which an S/MIME encrypted link is desired.
SPN A Secure Public Network (SPN) is a secure messaging link between two Email Firewall domains or an Email Firewall domain and a non-SMG compliant domain that supports S/MIME at the gateway. When you establish an SPN, Email Firewall automatically encrypts and digitally signs the mail that flows between the two domains. SPN pre-dates the SMG standard and is the 426
Chapter 8: Email Encryption and Authentication Overview
preferable mode of operation for communicating with previous versions of Email Firewall on the Internet.
TLS Transport Layer Security (TLS) is a protocol that ensures privacy and optionally two-way authentication between communicating clients and servers on the Internet.
8.16 Commonly Used Security Terms
427
428
Chapter 8: Email Encryption and Authentication Overview
9
Security Configuration
This chapter describes how to set up and use cryptography, digital signatures, certificates, keys and Email Firewall policies to implement secure messaging policies in your organization. It provides instructions for configuring a serverto-server Secure Public Network (SPN™), a server-to-server S/MIME Gateway (SMG mode), server-to-client proxy security, client-to-client security, and a sender signature policy. It provides procedures for automating certificate associations with user records, automating certificate lookups, and managing Certificate Revocation Lists and accessing CRL Distribution Points. It also provides instructions for setting up certificates for use with Transport Layer Security (TLS). For overview information about S/MIME and OpenPGP security and SMTP over TLS in general, and about how Email Firewall implements these security features, see Chapter 8, Email Encryption and Authentication Overview. This chapter contains the following sections: 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11
Setting Up Email Firewall Security........................................ 430 Setting Up Key Pairs and Certificates for S/MIME ............... 433 Setting Up PGP Keys ............................................................. 442 Setting Up Certificates for TLS .............................................. 445 Setting Up for Sender Signature Policies............................... 451 Setting Up a Secure Public Network ...................................... 458 Setting Up for SMG Mode...................................................... 471 Setting Up S/MIME Proxy Security ........................................ 474 Rolling Over S/MIME Certificates ......................................... 497 Downloading Certificate Revocation Lists ............................. 500 Specifying the CRL DP LDAP Lookup................................... 503 429
9.12 9.13 9.14
9.1
Setting Up OpenPGP Proxy Security..................................... 504 Rolling Over OpenPGP Proxy Domain Keys ........................ 519 Setting Up S/MIME and OpenPGP Client-to-Client Security 521
Setting Up Email Firewall Security The Email Firewall Security Setup provides centralized administration for automating email security. Use Security Setup to: • • • • • • •
Define local secure domains. Generate key pairs and certificates for local secure domains. Generate PGP keys for local secure domains. Import and export local and external S/MIME certificates. Import local and external PGP keys. Import and export root keys. Establish an SPN with other Email Firewall servers so that all mail exchanged between your organization and another organization is automatically signed and encrypted. You can establish an SPN with other Email Firewall servers running previous versions of Email Firewall. In previous versions, these links may be known as VPNs.
• •
• •
Establish an encrypted and optionally authenticated connection with other SMG compliant domains. Establish S/MIME or OpenPGP proxy security to encrypt, decrypt, sign, and verify mail on behalf of your users when secure mail is exchanged outside of an SPN. Automate association of user records and the certificates associated with those records. Specify certificate revocation lists (CRL) sources and schedule CRL downloads.
Use security type policies to: • •
430
Automate certificate exchange and manage correspondents' certificates. Automate user certificate lookups to allow easy, transparent encryption between email users who are not part of an SPN.
Chapter 9: Security Configuration
• •
9.1.1
Maintain consistent email security across your organization and to ensure that Email Firewall policies have access to all email, even encrypted mail. Ensure that messages are signed before leaving or entering your organization.
Email Firewall Security Prerequisites Before beginning to set up Email Firewall security you should evaluate your current security setup and determine how you want to integrate Email Firewall security into your environment. If you are establishing email security for the first time, you should determine how you want to implement security in your organization. The information in Chapter 8, Email Encryption and Authentication Overview can help with these decisions. •
•
•
• • •
Will you be using a server-to-server SPN or SMG so that all email flowing between two Email Firewall domains is encrypted? If so, you will need to define your local domain and create an appropriate certificate to associate with it. You may also want to apply policies that recognize SPN or SMG messages and specify the actions to take when security problems in correspondence with SPN or SMG domains are encountered. Will you allow individual email users to send and receive encrypted mail where Email Firewall is encrypting, decrypting, signing, and verifying mail on their behalf? If so, you will want to automate the exchange of user S/MIME certificates and/or PGP keys as much as possible, using proxy security features. You may also want to apply policies that recognize proxy security issues and specify the actions to take when a proxy security issue with inbound or outbound email is encountered. Will you allow individual email users to encrypt and decrypt email to each other where Email Firewall is not doing any encryption but is responsible only for scanning the email? If so, you will want to apply policies so that the encrypted email flowing between two clients can be fully scanned by the Policy Engine, and specify the actions to take when it cannot be scanned. Will you require that email between specific users or specific domains be encrypted? That email containing specific content be sent securely? Will you require that email between specific users or specific domains be signed? Is it important that the certificates used for secure exchange with external users are valid and up to date? Then you will want to enable CRL downloads and perhaps automate access to CRL Distribution Points. 9.1 Setting Up Email Firewall Security
431
•
Will you be working with partners that use or require the TLS protocol be used in SMTP messaging? If so, you will need to set up a certificate for TLS usage, and set up the SMTP Relay Network Connections and Routing Rules to enable TLS communications. Table 9.1 shows a comparison between SPN and TLS security to help you decide which security method makes more sense for your environment.
When you have the answers to these questions, you are ready to begin setting up Email Firewall security. Table 9.1: S/MIME SPN, SMG and TLS Compared
9.1.2
Characteristics
SPN
SMG
TLS
Interoperable with many other vendors’ products
Some
Yes
Yes
Content encrypted for messages on the wire
Yes
Yes
Yes
SMTP envelope encrypted for messages on the wire
No
No
Yes
Content encrypted when mes- Yes sage is stored on an intermediate server
Yes
No
Guarantees message integrity Yes between domains
Yes, digital No signatures are applied
Using the Email Firewall Security Setup In the left menu click Set Up to open the Set Up page. Under the Security heading, click the TLS Setup, SPN Setup, Secure Domains & Local Certificates, S/MIME Certificates, PGP Keys or CRL Download links to access the security setup pages. Use the functions on the following tabs and pages to create and manage Email Firewall security: •
•
432
Setup > Security > TLS - Enable TLS, select the Local TLS Certificate, and specify the TLS Encryption key size. By default, all TLS sessions are required to use 128 bit (or larger) encryption keys. Local Secure Domains - Create, view, edit and remove your current local secure domains.
Chapter 9: Security Configuration
•
Local Certificates
- Generate, view, export and remove local S/MIME
certificates. •
• • • • •
9.2
S/MIME Certificates - Import, view, export, trust and remove S/MIME certificates created by an external source. You can also set up Email Firewall to automatically respond to requests for S/MIME certificates, and enable proxy S/MIME certificates usage. Trusted Root Keys - Import, view, export and remove S/MIME root keys. Pending SPN Links - Request, automatically respond to, forward, view and accept pending SPN links. PGP Keys - Import, view, and remove PGP keys created by an external source or by your Email Firewall. CRL Sources - Identify CRL sources and schedule CRL downloads. CRL Distribution Point LDAP Lookup - Specify the LDAP Data Source when the CRL Distribution Point host information is not specified in the certificate.
Setting Up Key Pairs and Certificates for S/MIME Exchanging secure mail is made possible by an exchange of certificates and keys. Before establishing TLS communication or an SPN or S/MIME Gateway with an external organization or domain, and before proxy security can be enabled, you must import or create a key pair and certificate that will identify you to the external organization or domain. For TLS, SPN, S/MIME Gateway and proxy security, you can either create one with Email Firewall or import a third-party certificate. When you generate a key pair and certificate using Email Firewall, you specify the email domain for which they are being generated. It is best to generate one key pair and server certificate for each domain that is protected by Email Firewall, because end user proxy certificates that you may want to generate later are based on the server certificate that most closely matches the end user’s domain. The external domains and end-users must manage their own certificates and key pairs.
9.2 Setting Up Key Pairs and Certificates for S/MIME
433
For more information on using third party certificates, see 9.2.4 Importing Third-Party Server Certificates on page 438.
9.2.1
Generating an Email Firewall Certificate and Key Pair To generate a certificate and key pair for an Email Firewall SPN or S/MIME Gateway: 1.
In the left menu, click Set Up to open the Set Up page.
2.
Under the Security heading, click Secure Domains and Local Certificates to open the Set Up > Secure Domains & Local Certificates (and SPN Setup) page.
3.
On the Local Certificates tab, click Generate to open the Generate Key popup.
4.
Type a name in the Organization Name field that will differentiate this certificate from others. The name of your organization is a useful name. However, if you will be establishing SPNs or S/MIME Gateways for different departments or for multiple locations, additional distinguishing information may be useful; for example, the location or department name.
5.
Type in the Email Domain information. The generated certificate will belong to this domain name. When the email domain information matches the local secure domain name, the generated certificate will be automatically associated with the local secure domain, and will appear under both the SPN Signing Certificate column and the Proxy Signing Certificate column of the Local Secure Domain tab.
6.
Select a Key Length using the drop-down arrow, and click Generate. If this certificate will be used for an S/MIME Gateway, the key length must be Commercial Grade 1024-bits. In this case, the Key Length option is greyed-out and cannot be changed. Depending on the key size, the key generation may take a few moments.
7.
434
Verify that the new certificate appears in the Local Certificates tab.
Chapter 9: Security Configuration
8.
In the row beside your new certificate, click View to open the Certificate Properties page to review the details of the certificate.
9.
Verify that the new key pair appears in the Trusted Root Keys tab.
10. Scroll to the Local Secure Domains tab. 11. Under the SPN Signing Certificate heading, verify the certificate is
associated with the local secure domain. 12. Under the Proxy Signing Certificate heading, verify the certificate is
associated with the local secure domain. Your server certificate is now associated with your local secure domain for SPN, and can be used for server-to-client proxy security as well. You can now begin to set up your SPN and proxy security. To do so, you must exchange your certificate with external organizations.
9.2.2
Sharing the Certificate and Root Key There are three ways to share your certificate and root key with others: • • •
Export and save them to your hard disk or some other location and then publish them on a website that uses SSL. Send by email using the cert-query feature. For an example of this, see Creating a Detect Cert-query Policy for the External Folder on page 482. Use the Email Firewall certificate responder. See 9.2.3 Enabling Email Firewall Certificate Responder on page 437.
Be sure to back up your security configuration and data on a regular basis.
9.2 Setting Up Key Pairs and Certificates for S/MIME
435
Exporting the Certificate and Root Key To export the certificate and root key: 1.
If you are not already viewing the Set Up > Security page, in the Email Firewall main menu, click Set Up. Under the Security heading, click Secure Domains & Local Certificates to open the Set Up > Secure Domains & Local Certificates (and SPN Setup) page.
2.
On the Local Certificates tab, locate the certificate you want to export, and in the row beside it, use the drop-down list to select PKCS7 (.p7c) then click Export to export the certificate.
3.
In the File Download pop-up, click Save and then select the folder in which you want to save the file. Click Close when the file save is complete. (If you selected Export PKCS7 the default extension is .p7c). This file serves as a root key for external users that need the root key in order to trust Email Firewall certificates. To enable Email Firewall to use certificates for server-to-client proxy certificates, be sure to mark the Enable Proxy Certificate Usage checkbox within the S/MIME Certificates page and save this configuration. (Under the Security heading, click S/MIME Certificates to open the Set Up > S/MIME Certificates page.) Once you have enabled the Proxy Certificate Usage feature, end user proxy certificates are then created automatically and on the fly as needed.
Publishing the Certificate as a Root Key Some S/MIME clients must contain a certificate authority’s root key before they can trust the certificates issued by that certificate authority. If external correspondents use these S/MIME clients to exchange secure mail with your users, you can give them the Email Firewall server certificate as a root key. When they import the root key, their clients will automatically trust both the Email Firewall server certificate and the proxy certificates that it issues. One way to provide the Email Firewall server certificate to external users is to publish it on your Web site. Create a Web page that explains the root key and provides the .p7c, .der, or .pem file that you export during the key generation. To inform external users how to obtain the root key, consider creating a policy that adds an annotation to all outbound signed messages. In the annotation, give instructions and the URL for the location of the root key.
436
Chapter 9: Security Configuration
To publish the certificate:
9.2.3
1.
If you are not already viewing the Set Up > Security page, in the left menu, click Set Up. Under the Security heading, click Secure Domains & Local Certificates to open the Set Up > Security page.
2.
On the Local Certificates tab, locate the certificate you want to publish, and in the row beside it, use the drop-down list to select PKCS7 (.p7c) then click Export to export the certificate.
3.
In the File Download page, click Save and then select the folder in which you want to save the file. Click Close when the file save is complete.
4.
Upload this file to your Web site.
5.
Once published to your Web site, this file serves as a root key for external S/MIME clients that need the root key to trust Email Firewall certificates.
6.
The published root key should be imported into the S/MIME external clients as a trusted root.
Enabling Email Firewall Certificate Responder The Certificate Responder allows external users to query for and obtain certificates from the Email Firewall Server automatically. Both server certificates and end user proxy certificates can be obtained using this feature. For conceptual information about the Certificate Responder, see 8.9 Understanding Certificate and PGP Key Responders on page 395. To enable Certificate Responder: 1.
1. 2.
If you are not already viewing the Set Up > Security page, in the left menu, click Set Up. Under the Security heading, click S/MIME Certificates to open the S/MIME Certificates page. Mark the Enable Certificate Responder checkbox. If this feature will be used for proxy certificates, mark the Enable Proxy checkbox also.
Certificate Usage
3.
Click Save.
What an External User Must Do to Invoke Certificate Responder When Certificate Responder is enabled it can be invoked by an external user sending an email message to the special email address: certquery@. The value of the Subject field specifies whether the query asks for the proxy certificate or the server certificate. 9.2 Setting Up Key Pairs and Certificates for S/MIME
437
See 9.8.7 Creating the S/MIME Proxy Security Policies on page 480 for information on creating a policy for email sent to the cert-query address. See 8.9 Understanding Certificate and PGP Key Responders on page 395 for background information.
9.2.4
Importing Third-Party Server Certificates Instead of or in addition to creating an Email Firewall key pair and certificate, you can use the PrivateKeyWizard tool to import third-party key pairs and associated server certificates into the Email Firewall database. See 8.10.1 Supported Third-Party Server S/MIME Certificates on page 398 and 10.6 Using the PrivateKeyWizard Tool on page 568 for more information. Imported key pairs/certificates are listed in the Setup > Security page, Local tab. They can be used by one or more local secure domains. However, in a typical Email Firewall environment, each local secure domain has its own certificate.
Certificates
Certificates with a private key longer than 2048 bits cannot be used with Email Firewall.
Do not manually import the certificate; it cannot be used without its associated key pair. Instead, import the key pair using the PrivateKeyWizard tool. Note that other applications, such as a browser, may use the term certificate to refer to a private key file (.p12, .pfx, or .key file). A server certificate should have an email address like secureserver@, where the secure-server@ specification is hardcoded. This is useful when Email Firewall plaintext access policies are used.
Entrust-Specific Requirements for Certificates The procedure for generating an Entrust Server certificate is essentially the same as for generating an Entrust certificate for a web server. However, Email Firewall requires that the Server certificates be generated with the following capabilities and characteristics:
438
Chapter 9: Security Configuration
•
• •
•
The certificate must have a single key pair so that the same certificate can be used for encryption as well as for signature verification. (Dual key pairs are not supported by Email Firewall for Server certificates.) The certificate must have the “PKCS#12 export” capability. The “Entity” should have the PKCS#12 export capability. In other words, the entity for which the certificate is issued should belong to a Role that has the PKCS#12 export capability. The PKCS#12 export capability is required because the only way to import the Server certificate and the corresponding private key into Email Firewall database is using a PKCS#12 file. If the Client-to-Client security feature will be used, you must add the email address in the format in the certificate’s subjectAltName field.
From Entrust Certificate and Private Key to PKCS#12 File For Entrust certificates, after the server certificate is issued with the appropriate capabilities, the profile for the server must be created. One way to do this is to use Entrust Desktop software. When creating the profile, and also after the profile is created, the Entrust Desktop software allows you to export the certificate and private key into the PKCS#12 format. All PKCS#12 files are protected by a user-supplied password, so all mechanisms to export the certificate and private key into a PKCS#12 file will require you to enter a password.
VeriSign-Specific Requirements for Certificates The VeriSign certificate request process is not related to the Email Firewall Web Admin, and you can use any Web server program supported by VeriSign, as long as you can generate the Certificate Signing Request (CSR) and export the certificate as a PKCS#12 file. The procedure for obtaining a VeriSign server certificate is provided on the VeriSign Website, on the Managed PKI for SSL - Buy page located at: https://www.verisign.com/cgibin/clearsales_cgi/leadgen.htm?form_id=3003&toc=w28860083553003000&ra=64. 243.10.130&email=
The instructions for purchase are explained in the VeriSign Website. When you perform the certificate purchase, the specific process depends on which web server you use to request the certificate.
9.2 Setting Up Key Pairs and Certificates for S/MIME
439
For example, if you use IIS to make the request and generate the PKCS#12: 1.
With IIS running on the machine where the primary internal mail server is running, create a Certificate Signing Request (CSR). Instructions are provided on the VeriSign site at http://www.verisign.com/support/csr/microsoft/v06.html
2.
On the VeriSign Website, submit a certificate purchase request with the CSR, at the location https://www.verisign.com/cgibin/clearsales_cgi/leadgen.htm?form_id=3003&toc=w28860083553003000&ra=6 5.205.251.51&email=
9.2.5
3.
When VeriSign sends you the certificate by email, import the certificate into IIS.
4.
From IIS, export the certificate as a PKCS#12 file.
Importing a PKCS#12 File Into Email Firewall The PrivateKeyWizard tool is used to import the certificate and private key contained in a PKCS#12 file into Email Firewall. To import a certificate and the corresponding private key from a PKCS#12 file:
9.2.6
1.
Obtain the PKCS#12 file using one of the techniques mentioned above, for example, export it to a private key file (.p12, .pfx, or .key file) file from the application where it is currently stored, such as a browser.
2.
Follow the procedure in 10.6 Using the PrivateKeyWizard Tool on page 568 to complete the import.
Obtaining Certificate Authority Root Certificates To use Entrust and Verisign Server certificates in an Email Firewall SPN, the root or the issuer CA certificate must be obtained and imported as a Trusted Root. This section provides information that may be helpful when obtaining the root or the issuer CA certificate for Entrust and Verisign infrastructures. A number of Verisign Root Keys are provided with the Email Firewall product. These can be viewed on the Set up > Security > Secure Domains & Local Certificates, Trusted Root Keys tab.
440
Chapter 9: Security Configuration
For importing these CA certificates as Trusted Root certificates into Email Firewall, see 9.2.4 Importing Third-Party Server Certificates on page 438.
Obtaining Entrust Root Certificates You can obtain Entrust root certificates using the Entrust GUI or the Entrust Master Control Command Shell. To use the Entrust Master Control Command Shell command to export the CA certificate: ca cert export -binary -x509 -pkcs7 “c:/program files/entrust/cacert.der” To obtain the Entrust Root Certificate from a user or server certificate issued by the Entrust Root Certificate: 1.
Obtain any user or server certificate issued by the Entrust CA in .p7c format.
2.
Open the certificate using Microsoft tools (typically by double clicking on the file).
3.
Go to Certification Path.
4.
Open the root certificate.
5.
Copy it into a file.
To use the Entrust GUI: 1.
In the Entrust/RA application, right-click the Certificate Authority item.
2.
Select Export CA Certificate.
Obtaining Verisign Root Certificates Since Verisign is a public CA, its CA certificate is available in popular web and email clients. For example, from Microsoft Outlook Express, all the popular public Root CA certificates can be seen using “Tools => Options => Security => Digital IDs => Trusted Root Certificate Authorities”. To obtain the Verisign Root Certificate from a user or server certificate issued by Verisign: 1.
Obtain any user or server certificate issued by the Verisign CA in .p7c format.
2.
Open the certificate using Microsoft tools (typically by double clicking on the file). 9.2 Setting Up Key Pairs and Certificates for S/MIME
441
3.
Go to Certification Path.
4.
Open the root certificate.
5.
Copy it into a file.
In addition to importing the CA root certificates into Email Firewall as Trusted the intermediate CA certificates, if any, must be imported into Email Firewall as S/MIME Certificates.
Roots,
9.3
Setting Up PGP Keys Exchanging OpenPGP secure mail using encryption is made possible by an exchange of PGP keys. Before establishing a secured communication with an external organization or domain, and before OpenPGP proxy security can be enabled, you must import or create a PGP key that will identify you to the external organization or domain. You can either create one with Email Firewall or import it. When you generate a PGP key using Email Firewall, you specify the email domain for which it is being generated. It is best to generate one PGP key for each domain that is protected by Email Firewall, because end user proxy PGP keys that you may want to generate later are signed by the domain-associated PGP Domain key. The external domains and end-users must manage their own PGP keys.
442
Chapter 9: Security Configuration
9.3.1
Generating a PGP Proxy Domain Key To generate a PGP proxy domain key for OpenPGP proxy security: 1.
In the left menu, click Set Up to open the Set Up page.
2.
Under the Security heading, click Secure Domains & Local Certificates to open the Set Up > Secure Domains & Local Certificates (and SPN Setup) page.
3.
On the PGP Keys tab, click Generate to open the Generate Key pop-up.
4.
Type a name in the Organization Name field that will differentiate this PGP key from others.
5.
Type the email domain in the Email Domain field that will be associated with this PGP key.
6.
Select the key length in the Key Length drop-down menu. The following are your key length options: • • • •
512 bits—Export Grade 768 bits—Low Grade 1024 bits—Commercial Grade 2048—Military Grade This option is only available if you select the RSA algorithm. If you select the DSA algorithm, the key length size is limited to 1024 bits.
7.
Select the PGP algorithm in the PGP algorithm drop-down menu. The following are your PGP algorithm options: • DSA—Digital Signature algorithm • RSA—RSA algorithm
8.
Click Generate. Depending on the selected key size and algorithm, the key generation may take a few moments.
9.
Verify that the newly generated PGP key appears under the PGP Keys ID heading within the PGP Keys tab.
10. In the row for the new PGP key, click View to open the PGP Key Properties
page to review the details of the key. 11. Scroll to the Local Secure Domains tab.
9.3 Setting Up PGP Keys
443
12. Under the Proxy PGP Keys heading, associate PGP keys with the local
domain. Click Edit in the row for local domain. In the Proxy PGP Keys drop-down menu, select the Proxy Domain Key to be associated with this local secure domain and click Update. Your server PGP key is now associated with your local secure domain for server-to-client OpenPGP proxy security. You can now begin to set up your OpenPGP proxy security. To do so, you must exchange your PGP key with external PGP users.
9.3.2
Enabling Email Firewall PGP Key Responder The PGP Key Responder allows external users to query for and obtain PGP keys from the Email Firewall server automatically. Both server PGP keys and end user proxy PGP keys can be obtained using this feature. For conceptual information about the PGP key responder, see 8.9 Understanding Certificate and PGP Key Responders on page 395. The PGP Key Responder will automatically be enabled after you create the Proxy Decrypt and Verify policy. It will be enabled for all domains, which have been configured with a Proxy Decrypt and Verify policy applied to them in the EMF Directory. You do not have to take additional steps to enable this feature.
What an External User Must Do to Invoke PGP Key Responder When the PGP Key Responder is enabled, it can be invoked by an external user sending an email message to the special email address: pgp-key-query@ where email_domain_name is the name of the email domain. The value of the Subject field specifies whether the query asks for the proxy PGP key or the server PGP key. See 9.12.5 Creating the OpenPGP Proxy Security Policies on page 507 for more information on creating a policy for email sent to the pgp-key-query address. See 8.9 Understanding Certificate and PGP Key Responders on page 395 for background information.
444
Chapter 9: Security Configuration
9.3.3
Importing PGP Keys Into Email Firewall The PrivateKeyImport Wizard supports import of end user PGP key-pairs. Use the PrivateKeyWizard tool to import an internal user’s PGP key into Email Firewall. To import an internal user’s PGP key: 1.
Obtain the ASCII armored file. In order to obtain the ASCII armored keypair, export both the public and the private key(s) into a single file. This operation depends on the used PGP client software. Email Firewall does not support the use of multiple key rings. If you need to import key pairs of multiple users, export each key-pair to a separate ASCII-armored file and import the files one by one.
2.
9.4
Follow the procedure in 10.6 Using the PrivateKeyWizard Tool on page 568 to complete the import.
Setting Up Certificates for TLS The Transport-Layer Security (TLS) extension allows secure (SSL) communication between the Email Firewall relay and other SMTP servers. This option can be used for a variety of purposes when setting up the SMTP Relay Network Connections and Routing Rules. For an overview of how TLS is used with SMTP, see 8.4 Email Firewall Security using TLS on page 373. For information about TLS certificate requirements in general, see 8.10.2 Third Party TLS Certificate Requirements on page 399. The self-signed server certificate generated by EMF Web Admin cannot be used for TLS. Primarily, this is because: • •
the name in the certificate needs to be domain name for SMTP/TLS instead of an email address which is needed for S/MIME it is likely that the TLS certificate will need to be chained to a root certificate from a well-known public Certificate Authority when and if the certificate is validated at a remote domain.
9.4 Setting Up Certificates for TLS
445
For a certificate to be used for TLS in Email Firewall, the following process should be followed. 1.
Give some thought to what domain name you want to have in the certificate. This will usually need to be the fully qualified domain name of the hostname where the Inbound SMTP Relay service will be running, especially if you want to enable TLS connections from external SMTP relays.
2.
If you have more than one inbound SMTP Relay host in your Email Firewall setup, you will need to take additional actions before you enable TLS. To solve the problem of multiple inbound SMTP Relays using a single EMF database: 2a. Configure the DNS so that all inbound SMTP Relays are known
by the same alias (i.e. map one host name to multiple IP addresses.) 2b. Use that same alias as domain name for the server certificate you request from the Certificate Authority. 3.
Obtain a TLS certificate (VeriSign or Microsoft Certificate Server or any other mechanism) from a valid CA. When obtaining the certificate, keep in mind that a certificate that will be used for TLS should have the digitalSignature and keyEncipherment bits set in the keyUsage extension in order for the certificate to be used as both a TLS client and server certificate. The recommended practice for X.509v3 certificates used as a TLS certificate is that the fully qualified domain name (FQDN) of the server should be in the subjectAltName extension as a dNSName field. In summary, for a certificate to be usable as the TLS server certificate, it should satisfy the following: • The common name (CN) field in the certificate's Subject should be a host name, not an email address or, there should be a subjectAltName extension with at least one dNSName field specified. • The digitalSignature keyUsage bit must be set. • The keyEncipherment keyUsage bit must be set.
4.
446
Import the TLS certificate using the Email Firewall PrivateKeyWizard tool. The password used to protect the private keys must match the password specified as the Private Key Protection password in the installer, or the password that was last set using the Private Key Wizard tool. See 10.6 Using the PrivateKeyWizard Tool on page 568 for instructions.
Chapter 9: Security Configuration
5.
After importing the TLS certificate, you must trust the root key of this certificate for use by TLS.
6.
Use Web Admin to select the certificate in the Set Up > TLS Setup page. See Figure 9.1
Figure 9.1: Setting Up TLS Security
7.
Mark the Enable TLS checkbox. 7a. Use the drop-down list to select the certificate configured in the
previous steps. 7b. Unless there is a compelling reason to do so, leave the default setting to require all TLS sessions to use 128 bit (or larger) encryption keys enabled. 7c. Click Save. 8.
Set up the SMTP Relay settings. These settings are located on the main Set Up page, under the Relays heading. 8a. In the Set Up > Network Connections page, configure the Network Connections that are going to accept TLS. As a first test it would be useful to specify the TLS OK or the Req TLS options (without client authentication, as client authentication may require other certificates to be trusted). See 2.5.11 Setting Up Network Connections on page 54 for instructions. 8b. In the Set Up > Routing Rules page, configure the Relay Routing Rules. If using a Relay Host configuration with an IP address specified, be sure to configure a designated domain. See 2.5.13 Setting Up Mail Routing Rules on page 60 for instructions.
9.4 Setting Up Certificates for TLS
447
Once these steps are complete, there is a simple initial test to make sure that TLS is configured on the server. 1.
Telnet to port 25 on the server, from a machine that is configured in the Network Connections to be allowed to do TLS.
2.
Issue the following commands: EHLO example.com 2a. Check that STARTTLS is advertised by the relay.
STARTTLS 2b. Check that this does not return an error. If it returns a 454 error
then usually this means that the password used to protect the private key is incorrect.
9.4.1
Creating a TLS Message Exchange Policy When the Email Firewall SMTP Relay Network Connections and Routing Rules are configured for use with TLS, policies can be written for TLS-specific purposes. Before this can occur, the TLS server certificate must have been imported, see 9.4 Setting Up Certificates for TLS on page 445. Then, the SMTP Relay must have been configured to specify where TLS is permitted or required. These configurations are made in the Relay Network Connections and Routing Rules. See 2.5.11 Setting Up Network Connections on page 54 and 2.5.13 Setting Up Mail Routing Rules on page 60. When setting up TLS with a partner organization, you will need to know the following: • • • • •
What domain names do they use for email? What are the MX hosts published in the DNS for those domains? Does each MX host have its own server certificate? Do the names in the certificates match the MX host names? What are the network addresses from which SMTP mail will be sent?
Given that information, you will need to set up: • • •
448
Network connection rules to enable or require TLS from their networks. Mail routing rules to enable or require TLS to/from their domains. Policies to take some action on mail that arrives over a connection that does not use TLS.
Chapter 9: Security Configuration
A TLS policy should only apply when the SMTP sender is in a partner domain. After these setup tasks are completed, the policy filter conditions can be used to assist in setting up a TLS-specific policy. These conditions on the Catch and Exclude pages allow Email Firewall to act on messages where: • • •
the Inbound SMTP session used TLS. the Inbound SMTP session used TLS with client authentication. the Inbound SMTP session did not use TLS.
An example TLS policy would be a Sender-based policy applied to the All folder. The policy summary could be as shown in Figure 9.2. The action conditions include quarantining the message with a TLS-specific tag, sending a notification to the administrator as an alert, and logging an event to assist in reporting.
9.4 Setting Up Certificates for TLS
449
Figure 9.2: Example TLS Message Exchange Policy Summary
450
Chapter 9: Security Configuration
9.5
Setting Up for Sender Signature Policies The Sender Signature policy is a sender-based policy type that supports signing outbound messages to arbitrary recipients. When a Sender Signature policy is applied to a sender, the message will be signed if an appropriate certificate and the corresponding private key data are available in the Email Firewall database. Otherwise, the policy's failure action will be taken. This signing policy allows organizations to use an S/MIME signature that positively identifies the sender of an email message. The Sender Signature policy provides an optional catch condition that allows Email Firewall to distinguish messages originating from Internal senders. The purpose of this option is to allow flexibility in message dispositions if a message that normally would require signing is sent from an internal source/sender. In this case, the policy’s disposition for failing to meet signing requirements may be different from the disposition of a message from an external source/sender.
9.5.1
Administrator Actions Required 1.
Obtain a PKCS #12 file from a Certificate Authority. The file contains the digital certificate and the corresponding private key data for a specific email address. The certificate must be examined to ensure that its fields contain the expected values. In particular, check the following: • Ensure that the Valid From and Valid To dates are reasonable. • The Subject field should contain the expected email address embedded in the subject distinguished name as an EmailAddress attribute. • If the Subject field does not contain an email address, there should be a Subject Alternative Name extension present with the expected email address present as an rfc822Name value. • If the Key Usage extension is present, the digitalSignature usage should be enabled. • If there is an Extended Key Usage extension present, it should include either the emailProtection OID or the anyExtendedKeyUsage OID.
9.5 Setting Up for Sender Signature Policies
451
The process for obtaining a certificate from a third-party CA differs from vendor to vendor. However, the certificate must have the following characteristics: • it must be a user certificate, not server certificate • it must be for email protection • it must be exportable to PKCS#12 format Third-party CAs refer to these certificates using various names such as “Digital IDs for Secure E-mail”, “Personal IDs”, “Personal Digital ID”, “Personal Email Certificate”, “S/MIME Certificate, or just “Email Certificate”. When enrolling for the certificate, some third-party CAs provide an option to prevent exporting the private key. Do not select this option, because Email Firewall requires exporting the private key so that it can be imported into the Email Firewall certificate store in the Email Firewall database. 2.
Once the certificate has been installed in your browser or email client, export it (including the private key) to a PKCS#12 format file. (Some clients call this PFX format.) For example, using Internet Explorer 6.0 a certificate can be exported with its private key using the following procedure: 2a. Select Tools > Internet Options> Content tab. 2b. Click Certificates > Personal tab and select the appropriate 2c. 2d. 2e. 2f. 2g. 2h. 2i.
3.
certificate. Click Export. Click Next. Select the option to export the private key. Select Personal Information Exchange. Click Next. Type a password two times to protect the PKCS#12 file. Record the password for later use; store in secure location. Type a file name for the PKCS#12 file. Click Finish.
Import the PKCS#12 file into the Email Firewall database using the PrivateKeyWizard tool. See 10.6 Using the PrivateKeyWizard Tool on page 568. To perform this step you must be logged on as a Windows domain user with permission to modify the Email Firewall database. Otherwise, the certificate/private key import operation will fail.
Also see 9.2.4 Importing Third-Party Server Certificates on page 438.
452
Chapter 9: Security Configuration
After the certificate and the private key are imported into the Email Firewall database, Email Firewall Web Admin lists the certificate under the Set Up > Secure Domains & Local Certificates > Local Certificates tab. The Sender Signature policy uses the email address in the certificate's Subject Distinguished Name or the subjectAltName extension to choose the appropriate certificate to sign the message. 4.
Verify that the PKCS#12 file imported into the Email Firewall system contains a signing certificate that chains to a trusted public CA root. In addition, ensure that the keyUsage field of that signing certificate has the right value selected for signing. If the Key Usage extension is present, the digitalSignature usage should be enabled. The PrivateKeyWizard tool must be used to import the PKCS#12 certificates. After import, Email Firewall Web Admin shows the imported certificate in Set Up > Secure Domains & Local Certificates page, under the Local Certificates tab. If the matching public CA root certificate is not present in the Trusted Root section of in the Setup > Security page, you must import it. There are two ways to do this: • The root certificate may have been inserted into the S/MIME Certificates section of in the Setup > Security page. Export the certificate from this section to your desktop and re-import it into the Trusted Roots section. • The CA that issued the private key may provide their root certificate for download off their Web site. After acquiring this file, import it into the Trusted Roots section under Set Up > Secure Domains & Local Certificates page.
5.
Create a Sender Signature type policy. In Web Admin, the new policy type is listed first in the list of Security policy types in the create Policies page. For instructions on creating Email Firewall policies, see Chapter 6, Creating and Editing Policies. Below is the summary of a sample policy created using the Sender Signature policy type. Example Sender Signature Policy Policy Name: Sender Signature policy Policy Type: Sender Signature Applies To: Sender Summary of policy, ready to save: Take the following actions...
9.5 Setting Up for Sender Signature Policies
453
If the message is not already signed, attempt to sign the message using a valid signing certificate for the sender if successful, Deliver normally otherwise Quarantine the message with the tag: “Signing Failed” 6.
Enable the Sender Signature policy on the appropriate Directory object. Example Use Cases Scenario 1: Email Firewall is deployed only for the purpose of signing. Email Firewall is expected to sign all messages sent through the system. In this case, the policy can be applied to the Internal folder. A user record for the Email Firewall Notifier address should be created and the Sender Signature policy should be disabled for that user so that Email Firewall does not attempt to sign any policy-triggered notifications. Scenario 2: Email Firewall is expected to sign messages only for specified senders. In this case, a sub-folder on the Internal folder should be created. For example, create a new folder named Certified Senders. A Sender Signature policy should be applied to this sub-folder. User records should be created under the sub-folder for each email address that has a signing certificate imported into the Email Firewall database.
9.5.2
Expected Signing Behaviors This section describes how the Sender Signature policy interacts with other Email Firewall Security features and policies. 1.
When there is more than one signing certificate available for a sender, Email Firewall will choose the most recent signing certificate that is valid from among those certificates that are stored in the Email Firewall certificate store with the private key data available.
2.
When the Sender Signature policy is enabled for the sender and the opaque-signing format for the signature is in the recipient's record: The Sender Signature policy uses the clear-signed (multipart/signed) message format by default. However, if the recipient is matched to a user or domain record in the Email Firewall directory where the opaque-signed (signedData) signature format is specified with the “Reformat S/MIME Signature” option, that format will be used instead. This behavior can be disabled with the Policy Engine configuration option “SMIME Convert Signature Form.” If this configuration parameter is set to the integer value 0, the clear-signed format will be used regardless of the recipient/domain
454
Chapter 9: Security Configuration
record preference. This change should only be made using the Email Firewall Configuration Editor. For information on using the Configuration Editor, see 10.11 Using the Configuration Editor on page 609. 3.
When the Sender Signature policy is enabled for the sender and a Proxy Encrypt and/or Sign policy is enabled for the recipient and the opaquesigning format for the signature is enabled in the recipient's record: The recipient will receive an opaque-signed message.
4.
When there is no Sender Signature or proxy policies enabled for the sender and the opaque-signing format is enabled for the signature in the recipient's record: The recipient will receive an opaque-signed message if a signed message is sent to that recipient. The recipient will receive an unsigned message if an unsigned message is sent to that recipient.
5.
When there is no Proxy Encrypt policy enabled for the recipient, the Sender Signature policy will always use the clear-signed format.
6.
When there is a Proxy Encrypt and/or Sign policy enabled for the recipient and the opaque-signing format for the signature is enabled in the directory record to which the recipient address is matched: The recipient will receive an opaque-signed message.
7.
When the sender has a Sender Signature policy enabled and the recipient has a Proxy Encrypt and/or Sign policy enabled: Any failure to produce the expected S/MIME message results in the failure actions of both policies being triggered. This is true even when the “fault” could be clearly associated with one policy or the other. By triggering both failure actions, this ensures that the more severe disposition of the two failure actions is taken by the Policy Engine. For example, suppose that an Automatic Signature policy is in place but the administrator has not yet imported the certificate and private key data for a particular sender. If that sender sends a message to a recipient with a Proxy Encrypt and/or Sign policy enabled, the failure actions from both policies are triggered.
8.
When the recipient is in an SPN domain and the message is signed by a Sender Signature policy: The signed message is “tunneled” by the SPN, meaning that the message is both secured (encrypted) by the SPN and forwarded to the recipient as if there were no SPN modifying the message. This allows the original signature to be validated by the recipient's email client. This result is the same as when the sender signs a message using the desktop email client in a non-SPN environment. 9.5 Setting Up for Sender Signature Policies
455
9.
9.5.3
When sending signed mail to a Microsoft Exchange 5.5 server, the Exchange server option Clients support S/MIME signatures must be enabled (marked). This enables the recipients to verify the signature in their email clients.
Troubleshooting Sender Signature Policies Following are descriptions of issues that may arise and suggestions for resolving them. 1.
Email Firewall does not recognize Extended Key Usage extensions to X.509 certificates. When validating digital certificates, Email Firewall does not currently consider the Extended Key Usage extension. If that extension is present in a certificate and it is marked as critical, Email Firewall will treat that certificate as invalid for S/MIME operations because it contains an unrecognized critical extension. To work around this issue, either request a new certificate from the issuing certificate authority, or use Web Admin to mark the certificate to Trust unconditionally.
2.
Web Admin prevents overriding an inherited single instance policy. Some Email Firewall policies are known as single instance policies, meaning that no more than one policy of that type can apply to a record in the Email Firewall directory. “Infected Message” and Sender Signature” policies are examples of single instance policies. Currently, Web Admin does not permit a single instance policy to be applied to a directory record if that record already inherits a policy of the same type from a parent folder. Web Admin displays an error message indicating “Cannot add multiple instances of a single instance policy type.” This happens even when the inherited policy is marked as Disabled. To work around this issue: 2a. 2b. 2c. 2d.
3.
Remove the policy temporarily from the parent folder. Apply the override policies to the sub-entries within the folder. Reapply the policy to the parent folder. Return to the sub-entries and disable the inherited folder-level policy.
Web Admin may display policy inheritance of single instance policies incorrectly. Some policies are known as single instance policies, meaning that no more than one policy of that type can apply to a record in the Email Firewall
456
Chapter 9: Security Configuration
directory. Infected Message and Sender Signature policies are examples of single instance policies. Suppose a single instance policy is applied to a directory entry, and then a different policy of the same type is applied to a parent folder. When the directory entry is edited, Web Admin will incorrectly display that both the inherited and the locally applied policy apply to that entry. In fact, only the inherited policy will be applied. The locally applied policy is not used unless the inherited policy is locally disabled. Email Firewall does not perform a Certificate Revocation List (CRL) Distribution Point (DP) check on the Sender Signature certificate when the certificate is used in a Sender Signature policy. By default, Email Firewall will not attempt to update a certificate revocation list (CRL) from any distribution point if the certificate validation is being performed for a Sender Signature policy. This default behavior is preferred for best performance. CRL DP is specified as one of the certificate attributes and is typically an LDAP or HTTP location hosting CRLs. Checking the CRL DP can cause significant delay if the source (LDAP or the Web server) is not available, for example, it is down or if the firewall prevents the connection. However, if you want to enable the CRL distribution point check, a configuration parameter named Enable CRL DP Checking For Sender Signature Policy can be added to the EngineConfigValues table using the Configuration Editor. Set this parameter to the integer value 1 to enable the distribution point access. It is false (0) by default. For information on using the Configuration Editor, see 10.11 Using the Configuration Editor on page 609. The existing configuration parameter called Enable CRL Distribution Point Checking, which is used for controlling whether CRL DP checking is done in certificate validation for rest of the SMIME policies, is not affected. The Enable CRL Distribution Point Checking parameter is set to TRUE (CRL DP checking enabled) by default. This is the reason the configuration parameter was added specifically for the Sender Signature policy.
9.5 Setting Up for Sender Signature Policies
457
9.6
Setting Up a Secure Public Network The example procedures in this section describe one way to set up an SPN between two Email Firewall servers, one local, and one external. For conceptual information about an SPN, see 8.3.4 The Email Firewall SPN-Type Policies on page 372. The main steps are listed below, with links to the relevant sections:
9.6.1
1.
9.6.1 Defining and Associating Local Secure Domains.
2.
9.6.2 Enabling SPN Links on page 461.
3.
9.6.3 Setting Up Email Firewall to Respond to SPN Links on page 463.
4.
9.6.4 Verifying the SPN and Security for the Domain on page 466.
5.
9.6.5 Creating a Policy to Check for Successful SPN on page 467.
Defining and Associating Local Secure Domains A local secure domain represents a particular set of end-users. Organizations often have different local secure domains that represent different sets of users. Once a local secure domain is defined and a server certificate is associated with it, Email Firewall security measures can be implemented for that set of users. As discussed in 8.3.1 Understanding Local Secure Domains on page 370, the name of the internal domain you defined during installation is created automatically as a Local Secure Domain. It cannot be deleted or removed, and it is always listed on the Setup > Secure Domains & Local Certificates (and SPN Setup) page, Local Secure Domains tab. However, no certificates are automatically associated with it. You must perform the association before implementing security measures that use encryption, decryption, and digital signatures. You can also associate local domains with third-party certificates imported using the PrivateKeyWizard tool. For more information about this tool, see 10.6 Using the PrivateKeyWizard Tool on page 568.
The following example shows how to create a local secure domain and associate a certificate with it. Before proceeding, if you have not done so already, you should create a certificate to use with SPN. To create a certificate, follow the procedure outlined in 9.2 Setting Up Key Pairs and Certificates for S/MIME on page 433.
458
Chapter 9: Security Configuration
If at the time of certificate generation, the new certificate is given the same email domain name as the new local secure domain, the new certificate will automatically be associated with that domain.
To create a new Local Secure Domain: 1.
If you are not already viewing the Set Up > Secure Domains & Local Certificates (and SPN Setup) page, in the Email Firewall main menu, click Set Up.
2.
Under the Security heading, click Secure Domains & Local Certificates to open the Set Up > Secure Domains & Local Certificates (and SPN Setup) page.
3.
On the Local Secure Domains tab, Local Secure Domain field, type the name of the new local secure domain in the field provided. (Be sure the domain name is correct.) See Figure 9.3.
4.
On the Local Secure Domains tab, use the drop-down list under the SPN Signing Certificate heading, Tumbleweed SPN subheading, to select the certificate you created in the procedure described in 9.2 Setting Up Key Pairs and Certificates for S/MIME on page 433. The private key in this certificate will be used to sign and decrypt messages passing through the Email Firewall server when a policy requiring this security is invoked.
Figure 9.3: Set Up Security, Local Secure Domains
9.6 Setting Up a Secure Public Network
459
5.
On the Local Secure Domains tab, Proxy Signing Certificate heading, use the drop-down list to select the certificate you selected in the previous step. See Figure 9.4. This will allow Email Firewall to create end user proxy certificates automatically and on the fly with this server certificate. These proxy certificates will contain unique email addresses in the certificate’s SubjectAltname, but the public key in each certificate will be that of the server certificate assigned to that secure domain Proxy certificates cannot be issued if you used an imported third-party certificate for the SPN signing certificate (server certificate).
Figure 9.4: Associating the Proxy Signing Certificate
6.
Click Create.
7.
Verify the new local secure domain appears on the Local Secure Domains tab associated with the certificate you selected.
Editing a Local Secure Domain To modify the local secure domain information or to change the certificate associated with the local secure domain:
460
1.
In the Email Firewall main menu, click Setup.
2.
In the Security heading, click Secure Domains & Local Certificates.
3.
In the Local Secure Domains tab, in the row for the domain you want to edit, click Edit to open the editing fields.
4.
Type the new information and click Update.
Chapter 9: Security Configuration
9.6.2
Enabling SPN Links After you have created a certificate for your local secure domain and associated the server certificate with the local secure domain, you can begin establishing SPN links with external domains. (This section continues the example of setting up an SPN begun in 9.6 Setting Up a Secure Public Network on page 458.) There are two ways to establish an SPN link with an external domain. The method you select will vary depending on whether the external domain is using an Email Firewall gateway, but in either case you must exchange certificates with the external domain. 1.
To exchange certificates with an Email Firewall gateway domain, you can automate the process: • request an SPN link from an external Email Firewall domain that is set up to automatically respond to SPN link requests. • set up your local Email Firewall to automatically respond to SPN link requests from others.
2.
To exchange certificates with either an Email Firewall or non-Email Firewall gateway domain, you can manually exchange the certificates between the two domains.You can do this, for example, by exchanging the certificate files on floppy disks. This method is most useful when the external domain is using a non-Email Firewall gateway.
The following section describes how to automate the exchange of certificates between a local and an external Email Firewall-gateway domain.
Requesting an SPN Link From External Email Firewall Servers Before you perform this step, make sure that the external Email Firewall server has generated a local certificate for its primary Local Secure Domain. The external Email Firewall server should also have Auto-Respond to SPN link requests enabled. See 9.6.3 Setting Up Email Firewall to Respond to SPN Links on page 463.
9.6 Setting Up a Secure Public Network
461
To request an SPN link: 1.
If you are not already viewing the Set Up > Security page, in the Email Firewall main menu, click Set Up. Under the Security heading, click SPN Setup to open the Set Up > Security page at the Pending SPN Links tab.
2.
Click Request to open the New SPN Link Request page. See Figure 9.5.
3.
In the New SPN Link Request page, mark the Use S/MIME Gatewaycompatible SPN communications checkbox, if you are using S/MIME gateway-compatible SPN communications.
4.
Select a local secure domain from the Local Domain drop-down menu for which to request an SPN link.
5.
In the Remote Domain field, type the fully qualified email domain of the external Email Firewall server. A fully qualified domain name consists of a host and domain name, including top-level domain. For example, www.example.com is a fully qualified domain name. www is the host, example is the second-level domain, and .com is the top level domain. An FQDN always starts with a host name and continues all the way up to the top-level domain name, so www.myspn.example.com is also an FQDN.
6.
Review the default Message text and type any changes to customize the message.
7.
If you want all SPN link requests to have the same message, mark the Make this the default message for next time checkbox.
Figure 9.5: Setting Up an SPN Link Request
462
Chapter 9: Security Configuration
8.
Click Send Request. Email Firewall automatically sends to the external server a digitally signed message that includes its certificate, so it can be imported by the external domain. If the external domain is configured to automatically respond to the SPN link request, it does the following in the order listed: • Receives the request. • Imports the certificate from the signed message into the Email Firewall database to be used for encrypting future messages to the local domain. • Sends a digitally signed and encrypted message back to the local Email Firewall domain. This message includes the certificate of the external Email Firewall domain. • When the local domain receives the message from the external Email Firewall domain, it automatically imports the external domain’s certificate to be used for encrypting future messages to that external domain. If the external Email Firewall domain is not configured to automatically respond, an administrator must perform the import and respond tasks manually. In this case, response is not assured and the process is not automatic.
9.6.3
Setting Up Email Firewall to Respond to SPN Links To enable an SPN, both the local and external domains must import the other’s certificate. One way to accomplish this exchange is for both Email Firewall gateway domains to enable auto-responder. To enable SPN link responses: 1.
In the Email Firewall main menu, click Set Up to open the Set Up page. Under the Security heading, click SPN Setup to open the Set Up > Security page at the Pending SPN Links tab. Or, if you are already viewing the Set Up > Security page, scroll to the Pending SPN Links tab.
2.
By default, the Auto-Respond to SPN link requests with the following checkbox is marked. When this checkbox is marked, Email Firewall will automatically respond to incoming SPN link requests with message
9.6 Setting Up a Secure Public Network
463
the message shown in the field. The response will also include the Email Firewall server certificate. Figure 9.6: Enabling Auto-Response to SPN Link Requests
3.
If you want to customize the default message, type any changes in the field. It is recommended that you change the default text to include the name of the domain from which the response is being sent. This will identify you more accurately to the external domain.
4.
By default, the Forward SPN link requests to checkbox is marked. Marking this checkbox ensures that you receive email notification that an SPN link request has been received. 4a. In the Name field, type the name you want to appear on the request
notification. 4b. In the Email Address field, type the email address to which the
SPN link request notification should be sent. 5.
Click Update to commit the new configuration information to the database.
Now when an SPN link request is received, Email Firewall will automatically respond to the request to provide the certificate for the local domain, and will notify the administrator that the link has been requested.
464
Chapter 9: Security Configuration
Checking For and Accepting SPN Links After both the local and external Email Firewall gateway domains have been set up to respond to SPN link requests and each has sent the request to the other domain, you will want to know when the link request has been received, and complete the request. To check for and accept SPN links: 1.
In the Set Up > Security page on the Pending SPN Links tab, click Refresh to update the Pending SPN Links list. The list is not updated automatically.
2.
If the external Email Firewall domain has responded to your request for an SPN link, the response appears on the tab. If the Forward SPN Link Requests to setting contains your email address (see Figure 9.6), you will also receive an email message when the response is received by the local Email Firewall server.
3.
If the response does not appear after clicking Refresh, check again after you receive email notification of the response.
4.
When the external Email Firewall domain response appears in the Pending SPN Links tab, in the row beside the response, click Accept to open the Pending SPN Link page.
5.
Verify the fingerprint of the certificate before accepting the SPN link: 5a. Contact the external domain’s administrator by phone or in person
to verify the certificate fingerprint. 5b. In the Pending SPN Link page, or in the Set Up > Security page, S/MIME Certificates tab,
locate the certificate to verify. 5c. Compare the fingerprint of the certificate with the fingerprint that the external domain’s administrator reports. 5d. If the fingerprints match, optionally mark the Trust Unconditionally radio button. If you trust unconditionally, Email Firewall will not perform the standard certificate checking functions such as: checking for expiration date, chaining to a root, checking for certificate purposes, or perform CRL checking.
If the fingerprints do not match, remove this certificate and have the administrator send it again, and re-verify. 6.
When the fingerprint of the certificate is verified, in the Pending SPN Link page, click Accept. When you click Accept, Email Firewall does the following:
9.6 Setting Up a Secure Public Network
465
6a. Creates a domain record for the external Email Firewall domain in
the All/External folder of the local Email Firewall Directory. 6b. Associates the external domain’s certificate with the newly
created domain record. 6c. On the domain record’s Domain Security tab, Secure Public Network (SPN) heading, enables the “Use SPN...” option in the security properties of the newly created record.
9.6.4
7.
In the Email Firewall main menu, click Directory and navigate to the All Folder and then to the External folder. Verify that a domain record has been created for the external Email Firewall domain that you accepted in the previous step.
8.
Click the new external Email Firewall domain icon to open the Directory > Edit Domain page for the new domain.
9.
Scroll down to the Domain Security tab and verify that the new certificate is associated with the new domain and that Use SPN is selected.
Verifying the SPN and Security for the Domain To verify the SPN, both the local and external domains should exchange signed, encrypted email to be sure the SPN is operating properly. Once you have verified that you are able to receive and decrypt mail from the external Email Firewall domain, you can set security options for that external domain. One option is to require that mail sent from that domain be accepted by Email Firewall only if it the mail is signed and encrypted. The following procedure shows how to set this up. To set up security for the external domain:
466
1.
In the Email Firewall main menu, click Directory to open the Directory page.
2.
Navigate to the All and then to the External folder to open it. Click the external domain icon to open the Directory > Edit page
3.
Scroll down to the Domain Security tab.
Chapter 9: Security Configuration
4.
Under the Secure Public Network (SPN) heading, mark the Require SPN for mail received from * (inbound) checkbox. This selection ensures that mail sent from this domain is only accepted if it is signed and encrypted. It is recommended that you wait 24 hours before selecting this option to allow for receipt of unencrypted messages that may have been sent before the SPN was established.
9.6.5
Creating a Policy to Check for Successful SPN In order for an SPN setup to succeed, in the Set Up > Relay Centers page, Policy Engine heading, the Route messages through Policy Engine option must be enabled.
When Email Firewall receives an SPN message (or VPN message, if the message is from a previous version of Email Firewall), it adds the X-SMIMEVPN: Processed header to the message after decrypting it. One way to determine whether an SPN messages is successful is to create a policy to scan for the existence of the X-SMIME-VPN header so that when triggered, the policy verifies a successful SPN. Figure 9.7 shows what the policy will look like when completed.
9.6 Setting Up a Secure Public Network
467
Figure 9.7: Successful SPN Policy Summary
To create the policy to check for an SPN:
468
1.
Plan the policy before starting. In this case, the policy should read as shown in Figure 9.7.
2.
In the left menu, click Policies to open the Policies page.
3.
In the Policy column, type Successful SPN in the field.
4.
In the Action column, click Create to open the Policies page where you select the type of policy and to whom it should apply.
5.
In the Basic row, use the drop-down arrow to select Recipient, then click Create to open the Policies > Edit Catch Conditions page.
Chapter 9: Security Configuration
Create a custom header: 1.
Scroll to the bottom of the page and in the Header Field column, see Figure 9.8, mark the (Enter Custom Header) radio button. In the field, type X-SMIME-VPN.
2.
In the Condition column, use the drop-down arrow and select exists.
3.
In the Action column, click Add.
Figure 9.8: Creating a Custom Header Field to Check for Successful SPN
4.
Review your new header under the Header Field column, then click OK.
5.
In the Policies > Edit Summary page, click Action to open the Policies > Edit Actions page.
6.
Under the Deliver heading, verify the Deliver Normally radio button is marked (it should be marked by default; if it is not, mark it now).
Create a new annotation: 1.
Under the Annotate heading, mark the Annotate with checkbox and click Select Annotations to open the Select Annotations page.
2.
In the Annotation field, type Secure Message.
3.
In the Skip column, use the drop-down arrow to select Skip.
4.
Click Create.
5.
In the Edit Annotations page Text field, type This secure message was sent using an SPN. To easily add more identifying information to the annotation text, use placeholders. For example: From $SENDER to $RECIPIENTS on $DATE Re:$SUBJECT via $SERVER.
6.
Click Save to close the window.
9.6 Setting Up a Secure Public Network
469
7.
In the Select Annotations window Type column, use the drop down arrow to select Information.
8.
In the Method column, use the drop-down arrow to select inline at Top.
9.
Mark the checkbox beside Secure Message and click Select Checked Annotations.
Complete the policy: 1.
In the Policies > Edit Actions page, click OK.
2.
In the Policies > Edit Summary page, review your policy. See Figure 9.7.
3.
Click Save to commit the new policy to the database.
4.
Review the Policies page and verify your new Successful SPN policy appears in the list.
Apply the policy to the Directory:
470
1.
In the Email Firewall main menu, click Directory to open the Directory page.
2.
Click the All folder, then in the Internal folder row, click Edit.
3.
On the Policies on this folder tab, click Add Policy.
4.
In the Select Policies page, in the Successful SPN row, click Add.
5.
In the Policies on this folder tab, if you do not want the policy to be able to be disabled at a lower directory level, click Lock.
6.
Scroll to the bottom of the page and click Save to apply the Successful SPN policy to Internal folder, and commit it to the database.
Chapter 9: Security Configuration
9.7
Setting Up for SMG Mode An S/MIME Gateway between two email domain servers is set up very similarly to setting up an Email Firewall server-to-server SPN. The table below points out the differences between the two: Table 9.2: Differences between SPN and SMG Mode Setup SMG
SPN
Remote server
Any S/MIME gateway from an Ideally a Tumbleweed Email Firewall 6.0, SMG certified vendor MMS 5.6.3 or earlier gateway. Interoperability with other vendors’ gateways has been demonstrated in the field, but not guaranteed
Email address in the subjectAltName of the certificate
domain-authority@ secure-server@
RSA key length
1024-bit
Configurable
Symmetric algorithm
3DES
Configurable
Digital signature applied
Optional
Mandatory
For conceptual and background information about SMG mode, see 8.3 Email Firewall Gateway-to-Gateway Security on page 369.
9.7.1
Set Up Differences in SMG Mode Setting up Email Firewall for SMG mode communications requires the same steps as setting up an SPN, with the following differences: 1.
You must generate a certificate specifically for SMG mode communications. To do so, follow the procedures in 9.2.1 Generating an Email Firewall Certificate and Key Pair on page 434 but be sure to mark the checkbox for enabling the certificate for S/MIME Gateway (SMG) communications. See Figure 9.9. When generating a key for SMG communications, the Key Length of 1024 bits - Commercial Grade cannot be changed.
9.7 Setting Up for SMG Mode
471
Figure 9.9: Generating a Key for SMG Communications
472
2.
Perform the steps in:
• • •
9.6.1 Defining and Associating Local Secure Domains on page 458 9.6.2 Enabling SPN Links on page 461 9.6.3 Setting Up Email Firewall to Respond to SPN Links on page 463
3.
Verify the SMG and security for the domain. These steps are similar to the steps described in 9.6.4 Verifying the SPN and Security for the Domain on page 466. However, there are additional steps when setting up for SMG mode. For that reason, follow the steps below and not the steps in 9.6.4 Verifying the SPN and Security for the Domain on page 466.
4.
To verify the SMG, both the local and external domains should exchange signed, encrypted email to be sure the SMG is operating properly.
5.
Once you have verified that you are able to receive and decrypt mail from the external SMG domain, you can set security options for that external domain.
6.
In the Email Firewall Directory, associate an inbound SMG mode request with the external domain. This is accomplished first by enabling SMG mode security on the domain record for which SMG mode is to be used. These settings are located on the Domain Record’s Domain Security tab.
Chapter 9: Security Configuration
7.
In the Email Firewall main menu, click Directory to open the Directory page.
8.
Navigate to the All and then to the External folder to open it. Click the relevant external domain icon to open the Directory > Edit Domain page.
9.
Scroll down to the Domain Security tab, Secure Public Network (SPN) heading.
10. Mark the Use S/MIME Gateway (SMG) for all SPN communications with this domain
checkbox.
11. Mark the Use SPN for mail sent to (outbound) checkbox. 12. Select a security policy for messages to SPN domains that cannot be
encrypted and signed. By default, this policy is the Outbound Failure policy. 13. Optionally, mark the Require SPN for mail received from (inbound)
checkbox. If you marked this checkbox:
This selection ensures that mail sent from this domain is only accepted if it is signed and encrypted. It is recommended that you wait 24 hours before selecting this option to allow for receipt of unencrypted messages that may have been sent before the SPN was established. 13a. Select the policy for non SPN messages received from SPN
domains. By default, the SPN: Non-SPN Message policy is selected. 13b. Select the policy for imperfect SPN messages received from SPN domains. by default, the SPN: Imperfect SPN Message is selected. 14. Click Select Certificate and select the SMG certificate for use with this
domain. 15. The Encryption Algorithm for SMG must be Commercial Grade 112-bit Triple DES
(3DES).
16. The Signing Algorithm if signing is required must be SHA1. 17. Click Save.
9.7 Setting Up for SMG Mode
473
9.8
Setting Up S/MIME Proxy Security The following describes some server-to-client example procedures you could use to enable users within your organization who do not have digital certificates to exchange S/MIME secure messages with external users who are using an S/MIME client. For a conceptual overview and additional information about S/MIME proxy security, see 8.5 Email Firewall Server-to-Client Proxy Security on page 375.
9.8.1
Configuring S/MIME Proxy Security Checklist Following is a summary checklist of the steps required for an example of one way to create a server-to-client SPN, or S/MIME proxy security, between a local user named John Snyder () and an external user named Selena Garcia (). S/MIME Proxy security is required because Selena uses an S/MIME email client and John does not have his own signing or decryption certificate on his desktop. If you have already set up an SPN or if you have already followed the procedures in 9.6 Setting Up a Secure Public Network on page 458, you may not need to perform some of these steps. 1.
Generate a key pair and certificate for the local secure domain, if one has not already been created, and configure Email Firewall to use the certificate as the proxy signing certificate.
2.
Export and publish the root key. See 9.8.5 Exporting and Publishing the Root Certificate on page 478.
3.
Enable Proxy Certificate Usage and Certificate Responder to automate the proxy security process. See 9.8.6 Enabling S/MIME Proxy Certificate Usage and Responder on page 479.
4.
Create the necessary directory folders and proxy security policies, and apply them to the appropriate directory folders: 4a. Client Encryption and Signature policy for the External folder. 4b. Detect cert-query policy with root key instructions to the
External folder.
474
Chapter 9: Security Configuration
4c. Proxy Decrypt and Verify policy for a folder, typically the Internal
folder, that contains all the local users and local domains that need proxy security. 4d. Proxy Encrypt and/or Sign policy for a folder, typically under the External folder, that contains the user records of all the external users who send S/MIME email to the local proxy users. 5.
External User Selena sends a digitally signed email to .
6.
Email Firewall sends the Administrator a notification to set up the secure link with Selena.
7.
In the Web Admin UI Certificate Properties tab for Selena’s certificate, Administrator marks the radio button to explicitly trust Selena’s certificate.
8.
Optionally, Email Firewall automatically pulls Selena’s certificate from the cert-query email and automatically associates the certificate with her user record in the Proxy Security folder.
9.
Selena imports the Email Firewall root certificate according to the instructions in the cert-query policy notification.
10. Selena sends another cert-query email with John’s email in the subject. 11. Email Firewall sends to Selena John’s proxy certificate. 12. Selena updates her address book with John’s proxy certificate.
When you use proxy security, be sure that your relay is not configured as an open relay. See 2.5 Setting Up Relays on page 32 for more information.
9.8 Setting Up S/MIME Proxy Security
475
9.8.2
Configuring S/MIME Proxy Security Example The following sections describe in detail the example described in the previous section. It describes one way to set up a server-to-client SPN, or S/MIME proxy security, between local user John Snyder () and external user Selena Garcia (). If you have already set up an SPN, see 9.6 Setting Up a Secure Public Network on page 458, you may not need to perform some of these steps.
9.8.3 9.8.4 9.8.5 9.8.6 9.8.7 9.8.8 9.8.9 9.8.10 9.8.11
9.8.3
Generating a Key Pair and Certificate.................................. 476 Configuring Email Firewall to Use the New Certificate ....... 477 Exporting and Publishing the Root Certificate...................... 478 Enabling S/MIME Proxy Certificate Usage and Responder.. 479 Creating the S/MIME Proxy Security Policies....................... 480 Enabling Automatic Certificate Association .......................... 490 Creating the User Records ..................................................... 494 Exchanging and Verifying Certificates................................... 495 Completing the Association.................................................... 496
Generating a Key Pair and Certificate If you have followed the steps in 9.6 Setting Up a Secure Public Network on page 458, you have already generated the key pair and certificate and do not need to repeat this step. To set up server-to-client S/MIME proxy security for this example, you must associate a key pair and certificate with the local secure domain. You may already have one associated with the local secure domain (for this example, localdomain.com)or you may need to create one.
476
Chapter 9: Security Configuration
If you need to generate a key pair and certificate for the local domain to be used for S/MIME proxy security: 1.
Use the Email Firewall main menu Set Up command to open the Set Up page.
2.
Under the Security heading, click Secure Domains & Local Certificates to open the Set Up > Secure Domains & Local Certificates (and SPN Setup) page.
3.
On the Local Certificates tab, click Generate to open the Generate Key page. Review and follow the procedure described in 9.2 Setting Up Key Pairs and Certificates for S/MIME on page 433 to generate a key pair for this exercise.
4.
Verify that the new certificate appears in the Trusted Root Keys tab. If you have imported a certificate and key pair from an external PKI, this certificate cannot be used to issue proxy certificates. The Certificate Practice Statement and business policies of external PKI vendors prohibit Tumbleweed from issuing additional end-user certificates.
9.8.4
Configuring Email Firewall to Use the New Certificate If you created a new S/MIME key pair and certificate for localdomain.com S/MIME proxy security, or if you are going to use a different local secure domain for localdomain.com S/MIME proxy security, you must associate the proxy signing certificate with the local secure domain for localdomain.com S/MIME proxy security. If you need to configure Email Firewall to use the new certificate as the S/MIME proxy signing certificate: 1.
Scroll to the Local Secure Domains tab.
2.
To create a new local secure domain, see 9.6.1 Defining and Associating Local Secure Domains on page 458.
3.
Under the SPN Signing Certificate heading, verify the certificate is associated with the appropriate local secure domain, for this example, localdomain.com. If it is not, edit the local secure domain and select the required SPN signing certificate.
9.8 Setting Up S/MIME Proxy Security
477
4.
Under the Proxy Signing Certificate heading, verify the certificate is associated with the appropriate local secure domain, for this example, localdomain.com. If it is not, edit the local secure domain and select the required proxy signing certificate. This is the certificate that will be used to issue end-user certificates for use by external parties to send encrypted email into the local secure domain.
The local certificate (also called the server certificate) is now associated with the local secure domain localdomain.com, and can be used for S/MIME proxy security.
9.8.5
Exporting and Publishing the Root Certificate If you have already set up an SPN, see 9.6 Setting Up a Secure Public Network on page 458, you may not need to perform these steps.
To trust a proxy certificate, some S/MIME clients must contain the root certificate that issued the proxy certificate. The Email Firewall server certificate that issues a proxy certificate acts as its root key. To accomplish this for this example, the server certificate that you use for S/MIME proxy security for John must be made available to Selena, the S/MIME proxy security external user. See 9.2.2 Sharing the Certificate and Root Key on page 435 for instructions on how to make the certificate available. For this example, assume that the server certificate, if needed, has been shared with Selena.
478
Chapter 9: Security Configuration
9.8.6
Enabling S/MIME Proxy Certificate Usage and Responder If you have already set up an SPN, see 9.6 Setting Up a Secure Public Network on page 458, you may not need to perform these steps.
A proxy certificate enables email security with external users whose S/MIME clients require that the email address in a certificate exactly match the email address in the header of the email. For this example, Selena needs this type of certificate to communicate securely with John. The Email Firewall Certificate Responder automatically locates and sends proxy certificates when requested. When the certificate responder options are selected, if a proxy certificate does not exist, Email Firewall creates one. If a certificate is requested, Email Firewall automatically provides it. See 9.2.3 Enabling Email Firewall Certificate Responder on page 437 for additional information. To enable Proxy Certificate Usage and the Certificate Responder: 1.
In the left menu, click Set Up to open the Set Up page.
2.
Under the Security heading, click S/MIME Certificates to open the Set Up > S/MIME Certificates page. 2a. Mark the Enable Proxy Certificate Usage checkbox. 2b. Mark the Enable Certificate Responder checkbox.
3.
Click Save.
9.8 Setting Up S/MIME Proxy Security
479
9.8.7
Creating the S/MIME Proxy Security Policies S/MIME proxy security relies on a number of policies that automatically enable S/MIME proxy security and that alert the administrator to perform actions to enable S/MIME proxy security. If you are not familiar with creating Email Firewall policies, see 6.6 Creating Policies on page 296 for instructions on creating policies.
Creating a Client Encryption and Signature Policy The first policy to create for this example is a Client Encryption and Signature policy that adds the administrator as a cc: recipient to all inbound messages that are digitally signed and addressed to . The policy notifies the administrator when it detects inbound signed messages addressed to . Selena will send John a cert-query email as one step in creating an S/MIME proxy security. This policy will ensure that the administrator is notified when she does so. This cc: message signals the administrator to: • •
Establish trust of the incoming certificate from Selena (imported automatically from the digitally signed message). Create a user record for Selena in the Email Firewall Directory to associate with her incoming certificate. See 9.8.9 Creating the User Records on page 494 for detailed instructions on creating the user record for an external user such as Selena, and the policies to be associated with her user record.
The Client Encryption and Signature policy summary is shown in Figure 9.10.
480
Chapter 9: Security Configuration
Figure 9.10: Client Encrypt and Sign Policy
To create the Client Encrypt and Sign policy: 1.
Create the cert-query address list that will recognize inbound S/MIME proxy security messages. 1a. Add the
[email protected] address to the list.
2.
As a policy action, add the administrator as a cc: recipient of the caught message.
3.
Click Save to commit the policy to the database.
4.
Add the policy to the External folder to apply this policy to all messages from external domains: 4a. In the Email Firewall main menu, click Directory to open the
Directory page. 4b. Click the All folder and then the External folder.
9.8 Setting Up S/MIME Proxy Security
481
4c. Beside the External folder, click Edit to open the Directory > Edit
folder page. 4d. In the Policies on this folder tab, click Add Policy to open the Select 4e.
4f. 4g. 4h.
Policies page. In the Select Policies page, locate the Client Encrypt and Sign policy, and in its Action column, click Add. Or, in the Client Encrypt and Sign row, mark the checkbox beside the policy, and at the bottom of the page, click Add Checked Policies. In the Directory > Edit folder page, verify the Client Encrypt and Sign policy now appears in the Policies on this folder tab. In the Client Encrypt and Sign row, click Lock so that the policy cannot be disabled at another directory entry level. Click Save to commit the change to the database.
Creating a Detect Cert-query Policy for the External Folder S/MIME proxy security also relies on policies that alert the sender to perform actions that enable S/MIME proxy security. The next policy for this example is a Detect cert-query policy that automatically sends instructions to Selena when she sends her message addressed to
[email protected]. The Detect cert-query policy summary is shown in Figure 9.11.
482
Chapter 9: Security Configuration
Figure 9.11: Detect Cert-query Policy Summary
1.
Create a Basic Mail Filtering Detect cert-query policy to notify the sender, in this example Selena, when Email Firewall detects inbound messages addressed to any domain on the address list cert-query.
2.
Create the notification Email Firewall Root Key to inform senders how to obtain your root key. The notification should include the instructions for how to obtain your root key, for example, instructions to go to your web site, or instructions for how to send the cert-query email to obtain the root key. See 9.2.2 Sharing the Certificate and Root Key on page 435. See 6.4.2 Creating a New Notification for a Policy Action on page 290 for general instructions on creating notifications.
3.
As a policy action, send the notification Email Firewall Root Key.
4.
Click Save to commit the policy to the database.
5.
Add the policy to the External folder. Review the previous procedure for instructions on adding policies to the Email Firewall Directory.
9.8 Setting Up S/MIME Proxy Security
483
Creating a Proxy Decrypt and Verify Policy A Proxy Decrypt and Verify policy is required for all local users, such as John in our example, who need S/MIME proxy security. This policy allows any incoming mail that is signed and/or encrypted to be decrypted and signatureverified before being sent to the local user. The Email Firewall server transparently and automatically manages the proxy certificates required for the decryption, without requiring any action by the local user or the administrator. This policy identifies a local user (or a set of local users) as a proxy user. The policy is added to a user record created for each local user, and/or added to a domain record that identifies a set of local users in that domain. These user and domain records are typically created under the All/Internal folder, so that the policy can be applied to the folder level. The Proxy Decrypt and Verify policy summary is shown in Figure 9.12. Figure 9.12: Proxy Decrypt and Verify Policy Summary
484
Chapter 9: Security Configuration
If multiple users in your organization will receive secure mail, add their records to the folder to which the Proxy Decrypt and Verify policy applies. External users must send a separate cert-query message for each user with whom they want to exchange secure mail.
To create a proxy decrypt and verify policy: 1.
Create a Proxy Decrypt and Verify policy that applies to recipients of S/MIME proxy security messages.
2.
Create the tag Proxy Decrypt.
3.
Create the notification Proxy Decryption Failed - Sender so that the sender will be informed of any problems with decryption.
4.
Create the notification Proxy Decryption Failed - Administrator so that the administrator will be informed of any problems with decryption.
5.
As a policy failure action, send the notification Proxy Decryption Failed Sender.
6.
As a policy failure action, send the notification Proxy Decryption Failed Administrator.
7.
Click Save to commit the policy to the database.
8.
Add the Proxy Decrypt and Verify policy to the Internal folder. 8a. In the Policies on this folder tab, click Add Policy. 8b. In the Select Policies page, beside Proxy Decrypt and Verify row,
click Add. 8c. Click Lock if you do not want the policy to be able to be disabled
at a lower level. 8d. Click Save to commit the added policy to the database.
Creating a Proxy Encrypt and/or Sign Policy S/MIME proxy security may also require that messages sent from local proxy users, such as John in the example, to external S/MIME users, such as Selena in the example, be encrypted and signed. The next step for this example is to create a policy that automatically encrypts and signs mail sent by John, the internal proxy user. The Proxy Encrypt and/or Sign policy catch conditions are shown in Figure 9.13. This policy automatically encrypts and signs all mail sent from the organization’s S/MIME proxy security users to external S/MIME proxy security users.
9.8 Setting Up S/MIME Proxy Security
485
This policy should be applied to the external S/MIME user’s user record, in this example, to Selena’s user record, or to the folder that contains the external S/MIME user records. Figure 9.13: Proxy Encrypt and/or Sign
To create the Proxy Encrypt and/or Sign policy:
486
1.
In the Email Firewall main menu, click Policies to open the Policies page.
2.
In the Policy field, type Proxy Encrypt and/or Sign, then click Create.
3.
In the Policies page, Security section, in the Proxy Encrypt and/or Sign row, click Create. (Notice it is a recipient only policy.) See Figure 9.13.
4.
Click Actions to open the Policies > Edit Actions page. See Figure 9.14.
Chapter 9: Security Configuration
Figure 9.14: Proxy Encrypt and/or Sign Policy Actions
5.
To define the policy failure actions, click these actions to open the Actions for Original Message page. See Figure 9.15.
9.8 Setting Up S/MIME Proxy Security
487
Figure 9.15: S/MIME Proxy Security Actions for Original Message
488
Chapter 9: Security Configuration
For this example, as shown in Figure 9.16, specify the following failure actions: if unsuccessful, quarantine the message with the tag: “Proxy Encryption Failed” and send the notification “Proxy Encryption Failed” to the sender 6.
To accomplish these actions: 6a. Create the tag Proxy Encryption Failed. 6b. Create the notification Proxy Encryption Failed.
See 6.4.2 Creating a New Notification for a Policy Action on page 290 for general instructions on creating a new notification. 7.
Click Save to commit the policy to the database.
Figure 9.16: Proxy Encrypt and/or Sign Policy Summary
8.
Create a new folder named External S/MIME Proxy Security in the External folder. This is the folder where you will place the user records of all external S/MIME users who use S/MIME proxy security. 8a. In the Email Firewall main menu, click Directory to open the
Directory page. 9.8 Setting Up S/MIME Proxy Security
489
8b. Click the All and then the External folder. 8c. In the Entry field, type External S/MIME Proxy Security. 8d. In the Type column, use the drop-down arrow to select Folder. 8e. Click Create. 8f. Click Save. 9.
Add the Proxy Encrypt and/or Sign policy to the External S/MIME Proxy Security folder. 9a. In the Email Firewall main menu, click Directory to open the
Directory page. 9b. Click the All and then the External folder. 9c. Beside the External S/MIME Proxy Security folder, click Edit to
open the Directory > Edit Folder page. 9d. In the Policies on this folder tab, click Add Policy. 9e. In the Select Policies page, beside Proxy Encrypt and/or Sign row,
click Add. 9f. Click Lock if you do not want the policy to be able to be disabled
at a lower level. 9g. Click Save to commit the added policy to the database.
Your directory environment is now set up for the example user, Selena, and for any other external S/MIME proxy users.
9.8.8
Enabling Automatic Certificate Association An Automatic Certificate Association policy may be useful for the folder that contains the user records of the external S/MIME proxy users who send S/MIME email to the local S/MIME proxy users. With this policy you will also need to create the necessary user record(s) in the appropriate directory folder so that the automatic certificate association policy performs properly. To create the user records, you must know the external S/MIME user’s email address.
For this example, create an Automatic Certificate Association policy on the folder for Selena, the external S/MIME proxy security end-user. When Email Firewall encounters a signed message from Selena, the certificate association is automatically made. External S/MIME Proxy Security
490
Chapter 9: Security Configuration
The root certificate for the external user’s CA must already be imported and the Auto-association purpose must be enabled. To create an Automatic Certificate Association policy: 1.
In the Email Firewall main menu, click Policies to open the Policies page.
2.
In the Policy field, type Auto Associate for Proxy, then click Create.
3.
In the Policies page, Security section, in the Automatic Certificate Association row, click Create. (Notice it is a sender only policy.)
4.
Click Actions to open the Policies > Edit Actions page. See Figure 9.17.
Figure 9.17: Actions for the Automatic Certificate Association Policy
5.
Review the requirements that allow the policy to succeed and be sure to create the appropriate environment. These requirements are set out in Figure 9.17.
6.
Click OK and review the policy summary. See Figure 9.18.
9.8 Setting Up S/MIME Proxy Security
491
7.
Click Save.
8.
Apply the policy to the External S/MIME Proxy Security folder following the steps in the previous procedure.
Figure 9.18: Automatic Certificate Association Policy for Proxy Security
Setting Root Key Purposes When you import a root key into Email Firewall for use with proxy security, you may want to configure the usage conditions for the root key. See 8.14.2 Understanding Root Key Purposes on page 411 for more information. All certificates are Trusted for S/MIME operations. But if you will be using an Email Firewall policy to provide automatic certificate associations between user records and the certificates used to sign email from the user, you may want to enable the Auto Certificate Association with End User Records option.
492
Chapter 9: Security Configuration
If a certificate is received that does not chain to a root with the Auto Certificate Association with End User Records purpose set, the certificate will be imported, but will not be associated with the user record.
For purposes of the example S/MIME proxy security between Selena, the external user, and John, the local user, we want to enable the root key purposes for auto-association. To set the root key purposes: 1.
In the Email Firewall main menu, click Setup.
2.
In the Security heading, click Secure Domains & Local Certificates.
3.
In the Trusted Root Keys tab, click View in the row for the root key you want to work with.
4.
In the Root Key Properties page, Trusted for heading, note that the certificate is by default enabled and trusted for S/MIME usage. (This is true of all root keys.)
5.
Mark the Auto Certificate Association with End User Records checkbox.
6.
Optionally, mark the Auto Certificate Lookup of End User Certificates checkbox. See 9.8.12 Dynamic Lookups in S/MIME Proxy Security on page 496 for more information about using this feature.
7.
Click Save. You can override the automatic certificate association on a per-user basis by manually associating a different certificate with that user’s user record.
9.8 Setting Up S/MIME Proxy Security
493
9.8.9
Creating the User Records To be able to implement S/MIME proxy security for the example begun in 9.8.1 Configuring S/MIME Proxy Security Checklist on page 474, you must create user records for the S/MIME proxy security users. For the example External User, Selena, create a user record for Selena Garcia in the External S/MIME Proxy Security folder: 1.
In the External S/MIME Proxy Security folder row, click Open.
2.
In the Entry field, type Selena Garcia.
3.
In the Type column, use the drop-down arrow to select User.
4.
Click Create.
5.
In the User Properties tab, Public Email Address field, type
[email protected].
6.
Click Save.
For the example Local User, John, create a user record for John Snyder in the Internal S/MIME Proxy Security folder: 1.
In the Directory page, click the All folder and then the Internal folder.
2.
In the Local S/MIME Proxy Users folder row, click Open.
3.
In the Entry field, type John Snyder.
4.
In the Type column, use the drop-down arrow to select User.
5.
Click Create.
6.
In the User Properties tab, Public Email Address field, type
[email protected].
7.
Click Save. If all end-users in the email domain localdomain.com need S/MIME proxy security, you could create a domain record for localdomain.com under the Local S/MIME Proxy Users folder instead of creating individual user records.
494
Chapter 9: Security Configuration
9.8.10 Exchanging and Verifying Certificates If you have been following the example step begun in 9.8.1 Configuring S/MIME Proxy Security Checklist on page 474, you are now ready to receive and respond to a certificate query from Selena. 1.
Selena must send Email Firewall a digitally signed message in the following format: From:
[email protected] To:
[email protected] Subject:
[email protected]
Note that the Subject field specifies John’s fully qualified email address. 2.
When Email Firewall receives the message, it automatically imports Selena’s certificate from the digitally signed message and associates it with her user record. It then sends a digitally signed response to Selena that includes a proxy certificate for John Snyder.
3.
In addition, the message from Selena invokes the Detect cert-query policy that you created, and Email Firewall sends her the notification about how to obtain the Email Firewall root key. After she imports the root key, her client will trust John’s proxy certificate.
To verify the authenticity of Selena’s certificate: 1.
In the Set Up > Security page, scroll to the S/MIME Certificates tab.
2.
In the row beside Selena’s certificate, click View.
3.
In the Certificate Properties page, if Selena’s certificate issuer is in the Root Key list, Selena’s certificate will be trusted. Otherwise, obtain the issuer’s certificate and import it as a root key. Alternatively, you can apply direct trust: 3a. Contact Selena by phone or in person to verify the certificate
fingerprint. 3b. In the Set Up > Security page, S/MIME Certificates tab, locate the
certificate to verify and click View. 3c. Compare the fingerprint of the certificate with the fingerprint that
Selena reports. 3d. If the fingerprints match, mark the Trust Unconditionally radio
button. If the fingerprints do not match, remove this certificate and have Selena send it again, and re-verify. 3e. Click Save.
9.8 Setting Up S/MIME Proxy Security
495
John, as local user, sends an email message to Selena, the external user, to complete the S/MIME proxy security exchange: 1.
John composes a message to Selena and sends it to her at her fully qualified email address.
2.
Email Firewall checks to see if the local user already has a proxy certificate. If not, Email Firewall creates a proxy certificate.
3.
Email Firewall signs the message with the proxy certificate.
4.
Email Firewall attaches the proxy certificate to the signed message.
5.
Email Firewall finds the external user’s Email Firewall Directory record and associated certificate, and encrypts the message with the certificate.
6.
Email Firewall sends the message.
9.8.11 Completing the Association 1.
Selena adds John’s certificate to her S/MIME database.
2.
Selena associates John’s email address with that certificate.
Selena and John can now exchange secure mail. Note that with S/MIME proxy security, the email Selena receives is digitally signed and encrypted by the Email Firewall server on behalf of John. When Selena verifies this digital signature on her S/MIME email client, she can be assured the message contents were not altered from the time they left the Email Firewall server, but not necessarily from the time the message contents left John’s desktop.
9.8.12 Dynamic Lookups in S/MIME Proxy Security Dynamic Lookup of certificates is another way to obtain the certificate for server-to-client security. The procedures in sections 9.8.1 Configuring S/MIME Proxy Security Checklist on page 474 through 9.8.9 Creating the User Records on page 494 are valid for dynamic lookups as well. For the LDAP lookup, the policy can be configured on a domain record. If the policy is enabled on the domain record, you do not need the user records, and so you do not need to associate the certificate to a particular user record.
496
Chapter 9: Security Configuration
Also, if you will be using an Email Firewall policy to specify real-time lookup of end user certificates for proxy security, you can enable the Auto Certificate Lookup of End User Certificates option.
9.9
Rolling Over S/MIME Certificates S/MIME certificates can become invalid. A server certificate can become invalid because it has expired, been revoked, or been compromised. When a certificate is invalid, the Email Firewall administrator must replace the certificate with a valid certificate. Before beginning a certificate rollover you should carefully review 8.12 Understanding Certificate Rollovers on page 401 for a detailed explanation of the rollover process, concepts and consequences. This is especially important if you use proxy security. The ramifications of a certificate rollover may not be immediately apparent, and the process must occur gracefully to prevent problems in exchanging secure email with proxy partners.
9.9.1
Rolling Over a Certificate The following subsections describe the steps for rolling over a certificate.
Generating or Importing The New Certificate 1. At the start of the rollover period, generate or import the new certificate. Every certificate name is made up of a combination of the Organization and the Email Domain, and the Email Domain for the replacement certificate is fixed. Name
To avoid confusion, the Organization Name should not be the same Organization Name that was used for the expiring certificate. Using a serial number or issue date in the organization name is a good practice. • To generate a self-generated certificate, follow the procedure outlined in 9.2.1 Generating an Email Firewall Certificate and Key Pair on page 434 and following. • To import an external or third-party certificate as the server certificate, see 9.2.4 Importing Third-Party Server Certificates on page 438.
9.9 Rolling Over S/MIME Certificates
497
Distributing The New Certificate When distributing the new certificate to SPN partners, be sure to inform them of the end date the old certificate, after which the old certificate will no longer be valid. All SPN partners must switch to the new certificate before that date. Otherwise, they cannot exchange encrypted email with you. 2.
When the rollover period has started, use any of several ways to distribute the new certificate to your SPN and proxy partners: • Issue new SPN link requests to all SPN partners with a message that explains that the old certificate is being replaced. The SPN partner must then accept this request in the normal way. Once accepted, the new certificate is automatically associated with your domain record. When issuing new SPN link requests, in order for the SPN link request to be signed by the new server certificate, you must temporarily associate the new server certificate as the SPN signing certificate for the primary local secure domain. Since you have not yet rolled over the old certificate, after the SPN Link request is sent, you should re-associate the old server certificate as the SPN signing certificate for the local secure domain. • Send the new certificate by email to all SPN and proxy partners, with instructions on how to replace the old certificate with the new one. • Send a message with a link to your web site that contains the certificate and instructions. The instructions sent to SPN partners should advise them to: 2a. Import the new certificate in the S/MIME Certificates list. 2b. Establish that it is a Trusted certificate. 2c. Associate the new certificate with your domain record in their
Email Firewall database. The instructions sent to proxy partners should advise them to import the new server certificate as a Trusted Root certificate in their email client. 3.
498
Advise SPN partners that after they have successfully imported the new certificate and associated it with your domain record, they should keep your old certificate in their Email Firewall database until after the end of the rollover period.
Chapter 9: Security Configuration
The old certificate should remain associated with your domain record in the Email Firewall database of SPN partners, even though it is not selected as the Use for Encryption certificate. For additional information about distributing your certificate, see 9.2.2 Sharing the Certificate and Root Key on page 435.
Associating The Server Certificate With the Local Domain This step is the actual rollover and is accomplished by associating the new server certificate as the SPN signing certificate and as the proxy signing certificate of the local secure domain(s). 4.
Associate the new server certificate with the local secure domain(s). See 9.6.1 Defining and Associating Local Secure Domains on page 458 for instructions.
Enabling Proxy Partners To Obtain The Proxy Certificates 5.
Advise proxy partners that they must obtain the proxy certificate of each internal correspondent. Proxy partners can obtain the new proxy certificates issued by the new server certificate in two ways: • The proxy partner sends a cert-query email with the email address of their internal correspondent as the email subject. Email Firewall will process this cert-query email by responding with an automatic email from the internal proxy correspondent signed with the new proxy certificate issued by the new server certificate. The external user can then associate this certificate with the internal proxy correspondent in their address book. More information about the cert-query email can be found in 8.9 Understanding Certificate and PGP Key Responders on page 395. • Proxy partners can ask the internal proxy correspondent to send them a placeholder email. This email can even be blank. The email will be automatically signed by Email Firewall using the proxy certificate issued by the new server certificate.
9.9 Rolling Over S/MIME Certificates
499
Completing the Certificate Rollover 6.
At the end of the rollover period: • Optionally, send an email to SPN partners notifying them that the old certificate is no longer valid and that they can delete the old certificate from their Email Firewall database. • Optionally, inform all proxy partners that they can delete the old server certificate, and the proxy certificates issued by the old server certificate, from the certificate store used by their email client.
7.
Delete the old certificate from the Set up > Security > Secure Domains & Local Certificates (& SPN Setup) page under the Local Certificates tab. Note that this automatically deletes the root key associated with the old certificate.
If an SPN partner has not yet switched to the new certificate: • •
messages from them cannot be processed by the local Email Firewall. messages sent by the local Email Firewall to the SPN partner cannot be processed by the SPN partner.
If the appropriate policies are enabled and applied at the appropriate directory level, such messages will be processed by the Bad Message/Imperfect SPN Message Received policy (local Email Firewall). This policy has a default action to quarantine such messages.
9.10 Downloading Certificate Revocation Lists This section describes how to set up and perform certificate revocation list (CRL) downloads for CRL checking. You can specify that CRLs be downloaded automatically on a scheduled basis, and can download CRLs from multiple locations. To download CRLs, you must be able to connect to a remote location on a periodic basis to download a file from an http server. This download may use an intermediate proxy server. You can also manually start a CRL import for the initial import and for unscheduled imports. When a certificate has CRL checking, certificate status is checked against the most recent CRL available to Email Firewall every time a certificate is used. For more information about CRLs in general, see 8.14.7 Certificate Revocation Lists on page 419.
500
Chapter 9: Security Configuration
9.10.1 Specifying CRL Source and Download Schedule To identify the source for the CRL download: 1.
In the left menu, click Setup.
2.
Under the Security heading, click CRL Download.
3.
In the CRL Sources tab, CRL Source field, type the full URL of the CRL source. Example: http://crl.versign.com/class1.crl
4.
Click Add. Figure 9.19 shows CRLs added with downloads scheduled.
5.
In the CRL Download Schedule tab, specify the CRL Download schedule. 5a. Use the fields to specify download frequency in number of hours,
days or weeks. 5b. Specify the start date month, date, year and time. 5c. Click Save. 6.
Verify the new CRL source appears on the CRL Sources tab with the correct download schedule.
Figure 9.19: Setting Up CRL Updates
9.10 Downloading Certificate Revocation Lists
501
9.10.2 Specifying the HTTP Proxy Server for Downloads Once a CRL source has been identified, you will want to keep the information current. If you need to access an HTTP proxy server to obtain the downloads, complete the information in the HTTP Proxy tab within the Proxy Servers page. The HTTP proxy information is used to access both: • •
schedule downloaded CRLs HTTP URI-based CRL DP references
To identify the HTTP Proxy Server through which to access the CRL source: 1.
In the left menu, click Set Up to open the Set Up page.
2.
Click Proxy Servers to open the Proxy Servers page.
3.
In the HTTP Proxy tab, mark the Use HTTP Proxy Server checkbox. 3a. In the Address field, enter the hostname of the HTTP proxy the
Email Firewall will use to access and download the CRLs. 3b. In the port field, enter the port number of the of the HTTP proxy the Email Firewall will use to access and download the CRLs. The default port number is 80. 4.
If you require authenticated access to the HTTP Proxy Server, mark the Use Authenticated Access to HTTP Proxy Server checkbox. 4a. In User Name field, enter your user name. 4b. In the Password field, enter your password.
5.
Click Save.
9.10.3 Manually Invoking CRL Downloads When you first specify a CRL source, or at any time after specifying a CRL source, you can manually invoke a CRL download. To manually invoke a CRL download:
502
1.
If you are not already viewing the Setup > CRL Download page: 1a. In the left menu, click Setup. 1b. Under the Security heading, click CRL Download.
2.
In the CRL Source row, Action column, click Download Now.
3.
Review the dialog indicating the download will occur, and click OK.
Chapter 9: Security Configuration
4.
Return to the CRL Download page (or check the Event Log) after the CRL has had sufficient time to download (this will vary by source).
5.
In the CRL Source row, Last Download column, verify the download has occurred.
9.11 Specifying the CRL DP LDAP Lookup Email Firewall gets most of the information for accessing a CRL Distribution Point from the certificate itself. This can be: • • •
an HTTP URL. an LDAP URI (which is fully qualified and so has all the information needed to access the CRL DP via LDAP). a LDAP Distinguished Name (which needs the LDAP host and port information to access the CRL DP via LDAP).
If the CRL Distribution Point host information is not specified in the certificate, use the CRL Distribution Point LDAP Lookup tab to provide the LDAP Data Source information. To identify the LDAP Data Source for CRL Distribution Point host information: 1.
If you are not already viewing the Setup > CRL Download page: 1a. In the left menu, click Setup. 1b. Under the Security heading, click CRL Download.
2.
In the CRL Distribution Point LDAP Lookup tab, use the drop-down list beside the LDAP Data Source heading to select the correct data source, then click Save. If you have not previously configured a data source for CRL Distribution Point LDAP lookups, proceed to the next step.
3.
To configure a data source for CRL Distribution Point LDAP lookups, click (add new data source).
4.
Proceed to 10.2.3 Identifying the Data Source for LDAP Import on page 540 for information and instructions on how to identify a data source for LDAP import. Figure 9.20 shows the LDAP Import page where you configure the data source.
9.11 Specifying the CRL DP LDAP Lookup
503
5.
When you have configured the new LDAP Data Source for CRL Distribution Point lookups, in the CRL Distribution Point LDAP Lookup tab, use the drop-down arrow beside the LDAP Data Source heading to select that data source.
Figure 9.20: Specifying an LDAP Import Data Source for CRL Distribution Point
6.
Click Save.
9.12 Setting Up OpenPGP Proxy Security The following describes some server-to-client example procedures you could use to enable users within your organization who do not have PGP keys to exchange OpenPGP secure messages with external users who are using an Open PGP client. For a conceptual overview and additional information about Open PGP proxy security, see 8.5 Email Firewall Server-to-Client Proxy Security on page 375.
9.12.1 Configuring OpenPGP Proxy Security Checklist Following is a summary checklist of the steps required of one way to set up an OpenPGP proxy security, between a local user named John Snyder () and an external user named Selena Garcia (). For this example it is assumed that Selena has an OpenPGP email client or plugin, and John does not have his own signing or decryption key on his desktop. 504
Chapter 9: Security Configuration
1.
Generate a PGP key for the local secure domain, if one has not already been created, and configure Email Firewall to use the PGP key as the proxy signing PGP key.
2.
Create the necessary directory folders and OpenPGP proxy security policies, and apply them to the appropriate directory folders: 2a. Copy Admin on PGP Keys policy for the External folder. 2b. Proxy Decrypt and Verify policy for a folder, typically the Internal
folder, that contains all the local users and local domains that need OpenPGP proxy security. 2c. Proxy Encrypt and/or Sign policy for a folder, typically under the External folder, that contains the user records of all the external users who send OpenPGP email to the local proxy users. 3.
Selena sends her PGP key to the PGP keys address. This is accomplished by sending the ASCII armored block of her PGP key in the body of a message, which is sent to
[email protected]. The Administrator manually
associates the PGP key with her user record in the External OpenPGP Proxy Security folder and marks her user record as an OpenPGP user. 4.
Selena sends a pgp-key-query email to PGP-keys query email address (
[email protected]) with John’s email in the subject.
5.
Email Firewall will generate a proxy PGP key for John, and send Selena the public PGP key.
6.
Selena updates her address book with John’s proxy PGP key.
9.12 Setting Up OpenPGP Proxy Security
505
9.12.2 Configuring OpenPGP Proxy Security Example The following sections describe in detail the example described in the previous section. It describes one way to set up a server-to-client or OpenPGP proxy security between local user John Snyder () and external user Selena Garcia (). 9.12.3 9.12.4 9.12.5 9.12.6 9.12.7 9.12.8
Generating an Internal PGP Key (Local Key) ...................... 506 Configuring Email Firewall to Use the New PGP Key ......... 507 Creating the OpenPGP Proxy Security Policies .................... 507 Creating the User Records ..................................................... 516 Exchanging and Verifying PGP Keys..................................... 517 Completing the Association.................................................... 518
9.12.3 Generating an Internal PGP Key (Local Key) To set up server-to-client OpenPGP proxy security for this example, you must associate a PGP key with the local secure domain. You may already have one associated with the local secure domain (for this example, localdomain.com)or you may need to create one. To generate a PGP key for the local domain to be used for OpenPGP proxy security:
506
1.
In the left menu, click Set Up to open the Set Up page.
2.
Under the Security heading, click Secure Domains & Local Certificates to open the Set Up > Secure Domains & Local Certificates (and SPN Setup) page.
3.
On the PGP Keys tab, click Generate to open the Generate Key page. Review and follow the procedure described in 9.3 Setting Up PGP Keys on page 442 to generate a key pair for this exercise.
4.
Verify that the new PGP key appears in the PGP Keys tab.
Chapter 9: Security Configuration
9.12.4 Configuring Email Firewall to Use the New PGP Key You are required to configure the Email Firewall to use the local PGP key as the proxy PGP key by associating the PGP key with a local secure domain. This is the PGP key that will be used to sign end-user PGP keys for use by external parties to send encrypted OpenPGP email into the local secure domain. To configure Email Firewall to use the new PGP as the proxy PGP key: 1.
Go to the Local Secure Domains tab of the Secure Domains & Local Certificates (and SPN Setup) page. To create a new local secure domain, see 9.6.1 Defining and Associating Local Secure Domains on page 458.
2.
Select the local secure domain and edit it. Under the Proxy PGP Keys heading, select the PGP key associated with domain email address and click Update.
3.
Under the Proxy PGP Keys heading, verify the key is associated with the appropriate local secure domain. For this example, localdomain.com.
The local PGP key is now associated with the local secure domain localdomain.com.
9.12.5 Creating the OpenPGP Proxy Security Policies OpenPGP proxy security relies on a number of policies that automatically enable OpenPGP proxy security and that alert the administrator to perform actions. If you are not familiar with creating Email Firewall policies, see 6.6 Creating Policies on page 296 for instructions on creating policies.
9.12 Setting Up OpenPGP Proxy Security
507
Create a Policy to Detect PGP Keys Sent to EMF Server The first policy to create for this example is a Basic Mail Filtering policy that adds the administrator as a cc: recipient of all inbound messages that contain PGP keys and are addressed to
[email protected] where localdomain.com is your domain name. The policy notifies the administrator when it detects inbound keys being sent to the server. Selena will send her key into the Email Firewall as one step in setting up the OpenPGP proxy security with John. This policy will ensure that the administrator is notified when she does so. This cc: message signals the administrator to create a user record for Selena in the Email Firewall Directory to associate with her incoming PGP Key and to mark her user record as an OpenPGP user. The Basic Mail Filtering policy is shown in Figure 9.21. Figure 9.21: Detect pgp-keys Policy Summary
508
Chapter 9: Security Configuration
To create the basic mail filtering policy: 1. 2.
Create the pgp-keys address list. Add
[email protected] to the address list where localdomain is the name of your local domain. Create a new, sender-based, Basic Mail Filtering policy named Copy admin on PGP keys.
3.
As a catch condition, specify the policy to catch any mail sent to a recipient on the pgpkeys address list.
4.
As a policy action add the administrator as a cc: recipient of the caught message.
5.
Click Save to commit the policy to the database.
6.
Add the policy to the External folder to apply this policy to PGP keys going to internal domains. 6a. In the Email Firewall main menu, click Directory to open the
Directory page. 6b. Click the All folder and then the External folder. 6c. Beside the External folder, click Edit to open the Directory > Edit
folder page. 6d. In the Policies on this folder tab, click Add Policy to open the Select
Policies page. 6e. In the Select Policies page, locate the Copy admin on PGP keys
policy, and in its Action column, click Add. Or, in the Copy admin on PGP keys row, mark the checkbox beside the policy, and at the bottom of the page, click Add Checked Policies. 6f. In the Directory > Edit folder page, verify the Copy admin on PGP keys policy now appears in the Policies on this folder tab. 6g. In the Copy admin on PGP keys row, click Lock so that the policy
cannot be disabled at another directory entry level. 6h. Click Save to commit the change to the database.
Creating an Proxy Decrypt and Verify Policy A Proxy Decrypt and Verify policy is required for all local users, such as John in our example, who need OpenPGP proxy security. This policy allows any incoming mail that is signed and/or encrypted to be decrypted and signatureverified before being sent to the local user. The Email Firewall server transparently and automatically manages the proxy PGP key required for the decryption, without requiring any action by the local user or the administrator. This policy identifies a local user (or a set of local users) as a proxy user. The policy is added to a user record created for each local user, and/or added to a domain record that identifies a set of local users in that domain. These users and domain records are typically created under the All/Internal folder, so that the policy can be applied to the folder level. 9.12 Setting Up OpenPGP Proxy Security
509
The Proxy Decrypt and Verify policy summary is shown in Figure 9.22. Figure 9.22: Proxy Decrypt and Verify Policy Summary
If multiple users in your organization will receive secure mail, add their records to the folder to which the Proxy Decrypt and Verify policy applies. External users must send a separate pgp-key-query message for each user with whom they want to exchange secure mail.
To create a proxy decrypt and verify policy:
510
1.
Create a Proxy Decrypt and Verify policy that applies to recipients of OpenPGP proxy security messages.
2.
Create the tag Proxy Decrypt.
3.
Create the notification Proxy Decryption Failed - Sender so that the sender will be informed of any problems with decryption/signature verification.
Chapter 9: Security Configuration
4.
Create the notification Proxy Decryption Failed - Administrator so that the administrator will be informed of any problems with decryption/signature verification.
5.
As a policy failure action, send the notification Proxy Decryption Failed Sender.
6.
As a policy failure action, send the notification Proxy Decryption Failed Administrator.
7.
Click Save to commit the policy to the database.
8.
Add the Proxy Decrypt and Verify policy to the Internal folder. 8a. In the Policies on this folder tab, click Add Policy. 8b. In the Select Policies page, beside Proxy Decrypt and Verify row,
click Add. 8c. Click Lock if you do not want the policy to be able to be disabled at a lower level. 8d. Click Save to commit the added policy to the database.
Creating a Proxy Encrypt and/or Sign Policy OpenPGP Proxy security may also require that messages sent from local OpenPGP proxy users, such as John in the example, to external OpenPGP users, such as Selena in the example, be encrypted and signed. The next step for this example is to create a policy that automatically encrypts and signs mail sent by John, the internal proxy user. The Proxy Encrypt and/or Sign policy catch conditions are shown in Figure 9.23. This policy automatically encrypts and signs all mail sent from the organization’s OpenPGP proxy security users to external OpenPGP proxy security users.
9.12 Setting Up OpenPGP Proxy Security
511
This policy should be applied to the external OpenPGP user’s user record, in this example, to Selena’s user record, or to the folder that contains the external OpenPGP user records. Figure 9.23: Proxy Encrypt and/or Sign
To create the Proxy Encrypt and/or Sign policy:
512
1.
In the Email Firewall main menu, click Policies to open the Policies page.
2.
In the Policy field, type Proxy Encrypt and/or Sign, then click Create.
3.
In the Policies page, Security section, in the Proxy Encrypt and/or Sign row, click Create. (Notice it is a recipient only policy.) See Figure 9.23.
4.
Click Actions to open the Policies > Edit Actions page. See Figure 9.24.
Chapter 9: Security Configuration
Figure 9.24: Proxy Encrypt and/or Sign Policy Actions
5.
To define the policy failure actions, click these actions to open the Actions for Original Message page. See Figure 9.25.
9.12 Setting Up OpenPGP Proxy Security
513
Figure 9.25: OpenPGP Proxy Security Actions for Original Message
514
Chapter 9: Security Configuration
For this example, as shown in Figure 9.25, specify the following failure actions: if unsuccessful, quarantine the message with the tag: “Proxy Encryption Failed” and send the notification “Proxy Encryption Failed” to the sender 6.
To accomplish these actions: 6a. Create the tag Proxy Encryption Failed. 6b. Create the notification Proxy Encryption Failed.
See 6.4.2 Creating a New Notification for a Policy Action on page 290 for general instructions on creating a new notification. 7.
Click Save to commit the policy to the database.
Figure 9.26: Proxy Encrypt and/or Sign Policy Summary
9.12 Setting Up OpenPGP Proxy Security
515
8.
Create a new folder named External OpenPGP Proxy Security in the External folder. This is the folder where you will place the user records of all external OpenPGP users who use OpenPGP proxy security. 8a. In the Email Firewall main menu, click Directory to open the 8b. 8c. 8d. 8e. 8f.
9.
Directory page. Click the All and then the External folder. In the Entry field, type External OpenPGP Proxy Security. In the Type column, use the drop-down arrow to select Folder. Click Create. Click Save.
Add the Proxy Encrypt and/or Sign policy to the External OpenPGP Proxy Security folder. 9a. In the Email Firewall main menu, click Directory to open the
Directory page. 9b. Click the All and then the External folder. 9c. Beside the External OpenPGP Proxy Security folder, click Edit to
open the Directory > Edit Folder page. 9d. In the Policies on this folder tab, click Add Policy. 9e. In the Select Policies page, beside Proxy Encrypt and/or Sign row,
click Add. 9f. Click Lock, if you do not want the policy to be able to be disabled at a lower level. 9g. Click Save to commit the added policy to the database. Your directory environment is now set up for the example user, Selena, and for any other external OpenPGP proxy users.
9.12.6 Creating the User Records To be able to implement OpenPGP proxy security for the example begun in 9.12.1 Configuring OpenPGP Proxy Security Checklist on page 504, you must create user records for the OpenPGP proxy security users. For the example External User, Selena, create a user record for Selena Garcia in the External OpenPGP Proxy Security folder:
516
1.
In the External OpenPGP Proxy Security folder row, click Open.
2.
In the Entry field, type Selena Garcia.
3.
In the Type column, use the drop-down arrow to select User.
4.
Click Create.
Chapter 9: Security Configuration
5.
In the User Properties tab, Public Email Address field, type
[email protected].
6.
Click Save.
For the example Local User, John, create a user record for John Snyder in the Internal OpenPGP Proxy Security folder: 1.
In the Directory page, click the All folder and then the Internal folder.
2.
In the Local OpenPGP Proxy Users folder row, click Open.
3.
In the Entry field, type John Snyder.
4.
In the Type column, use the drop-down arrow to select User.
5.
Click Create.
6.
In the User Properties tab, Public Email Address field, type
[email protected].
7.
Click Save.
9.12.7 Exchanging and Verifying PGP Keys If you have been following the example step begun in 9.12.1 Configuring OpenPGP Proxy Security Checklist on page 504, you are now ready to receive and respond to a PGP key query from Selena. 1.
Selena must send Email Firewall a copy of her public PGP key to
[email protected].
2.
When email firewall receives the message, it automatically imports Selena’s PGP key from the message and notifies the administrator. The administrator associates Selena’s PGP key with her user record and marks her user record as a PGP user.
3.
Selena can then request a copy of John’s public PGP key by sending an email in the following format: From:
[email protected] To:
[email protected] Subject:
[email protected]
Email firewall will return a copy of John’s public PGP key for Selena to use, and Selena can now encrypt emails to John using his public PGP key.
9.12 Setting Up OpenPGP Proxy Security
517
9.12.8 Completing the Association 1.
Selena imports John's PGP public key into her PGP client software.
2.
Selena associates John’s email address with his PGP key.
Selena and John can now exchange secure mail. Note that with OpenPGP proxy security, the email Selena receives is digitally signed and encrypted by the Email Firewall server on behalf of John. When Selena verifies this digital signature on her OpenPGP email client, she can be assured the message contents were not altered from the time they left the Email Firewall server, but not necessarily from the time the message contents left John’s desktop.
9.12.9 Putting It All Together The following steps show what happens when John now sends a message to Selena: 1.
John composes a message to Selena and sends it to her at her fully qualified email address.
2.
Email Firewall checks to see if John already has a proxy PGP key. If not, Email Firewall creates a proxy PGP key for him.
3.
Email Firewall signs the message with the proxy PGP key.
4.
Email Firewall finds the Selena’s Email Firewall Directory record and associated PGP key, and encrypts the message with this key.
5.
Email Firewall sends the message.
The following steps show what happens when Selena sends a message to John:
518
1.
Selena composes the message in her email client and chooses to encrypt to John using his proxy PGP key.
2.
The encrypted message arrives at Email Firewall.
3.
Email Firewall decrypts the message using John’s proxy PGP key.
4.
The message is forwarded in the clear to John who can open it in his standard email client.
Chapter 9: Security Configuration
9.13 Rolling Over OpenPGP Proxy Domain Keys PGP keys can become invalid. A server PGP key can become invalid because it has expired or been compromised. When a PGP key is invalid, the Email Firewall administrator must replace the key with a valid one. Before beginning a PGP-key rollover, you should carefully review 8.12.5 Proxy PGP Key Rollover on page 407 for a detailed explanation of the rollover process, concepts and consequences. This is especially important if you use OpenPGP proxy security. The ramifications of a PGP-key rollover may not be immediately apparent, and the process must occur gracefully to prevent problems in exchanging secure email with OpenPGP proxy partners. To allow for key rollover, EMF will check that the proxy PGP key is signed by the current Domain Key. If it is not, then a new proxy user PGP key will be generated. The old PGP key will not be deleted to continue to allow for messages encrypted to that old key to be decrypted. Therefore, key rollover can be achieved by generating a new PGP domain key for the local secure domain.
9.13.1 Rolling Over a PGP Key The following subsections describe the steps for rolling over a PGP key.
Generating the New PGP Key 1. At the start of the rollover period, generate a new PGP key. Every PGP key name is made up of a combination of the Organization Name and the Email Domain. Ensure you generate a new PGP key with the same domain name as the key you are rolling over. To avoid confusion, the Organization Name should not be the same organization name that was used for the expiring PGP key. Using a serial number or issue date in the organization name is a good practice.
9.13 Rolling Over OpenPGP Proxy Domain Keys
519
Distributing the New PGP Key 2.
When the rollover period has started, send the new PGP key by email to all OpenPGP proxy partners, with instructions on how to replace the old PGP key with the new one. The instructions sent to OpenPGP proxy partners should advise them to associate the new PGP key with your domain record in their Email Firewall database.
3.
Inform your proxy partners to trust your new PGP proxy domain key in order to establish a trust model for all new PGP proxy user keys generated by EMF.
Associating the Server PGP Key With the Local Domain This step is the actual rollover and is accomplished by associating the new server PGP key as the proxy PGP key of the local secure domain(s). 4.
Associate the new server PGP key with the local secure domain(s). See 9.12.4 Configuring Email Firewall to Use the New PGP Key on page 507 for instructions.
Enabling Proxy Partners To Obtain The Proxy PGP Key 5.
Advise OpenPGP proxy partners that they must obtain the proxy PGP key of each internal correspondent. OpenPGP proxy partners can obtain the new proxy PGP key issued by the new server PGP key in the following way: The proxy partner sends a pgpkey-query email to pgp-keyquery@ with the email address of their internal correspondent as the email subject. Email Firewall will process this pgpkey-query email by responding with an automatic email from the internal OpenPGP proxy correspondent containing the new proxy PGP key. The external user can then associate this PGP key with the internal OpenPGP proxy correspondent in their address book. More information about the pgp-key-query email can be found in 8.9 Understanding Certificate and PGP Key Responders on page 395.
520
Chapter 9: Security Configuration
9.14 Setting Up S/MIME and OpenPGP Client-to-Client Security S/MIME or OpenPGP client-to-client security involves encryption between two individual S/MIME or OpenPGP users whose email is passing through Email Firewall. S/MIME or OpenPGP client-to-client security requires that policies be written so that encrypted email flowing between two clients can be fully scanned by the Policy Engine. The client-to-client policies can be grouped into two categories: •
•
Policies that allow encryption between two parties so long as each message can be decrypted and fully scanned by Email Firewall. These include: • Plaintext Access • Allow Security Stripping Policies that require encryption between two parties. These include: • Unencrypted Message Filter • Client Encryption and Signature
To review this concept, see 8.6 Email Firewall Client-to-Client Security on page 385.
9.14.1 Creating Plaintext Access Policies A Plaintext Access policy is used to ensure that mail is encrypted not only for the recipient, but also for Email Firewall. Plaintext Access policies come in two varieties: • •
One that affects encrypted messages received (Recipient) One that affects encrypted messages sent (Sender)
For more information about plaintext access policies generally, see 8.6.1 “Allow” Client-to-Client Security Policies on page 387. To create a plaintext access policy based on the recipient of the encrypted message: 1.
In the left menu, click Policies.
2.
In the Policies page, click Create.
9.14 Setting Up S/MIME and OpenPGP Client-to-Client Security
521
3.
In the Policies type page, Policy Name field, type Recipient Plaintext Access.
4.
In the Plaintext Access row, use the drop-down arrow to select Recipient and click Create.
5.
In the Policies > Edit Catch Conditions page, click Action.
6.
In the Policies > Edit Actions page, Deliver heading, mark the Quarantine radio button.
7.
Scroll down to the Apply Encryption tab and mark the Send signed notification to sender containing instructions for using the required server encryption checkbox.
The notification sent for OpenPGP operations will not be signed. It will be signed for S/MIME.
8.
In the Notification Text field, type the message text you want the message sender to read and act upon. For example: You cannot send encrypted messages to this domain unless you send an encrypted copy of the message to the service itself. You should first request the S/MIME certificate or PGP key associated with the domain. If you are using S/MIME, this message will be signed with the S/MIME key. If you are using PGP, you should request the PGP key for the server by sending an email to
[email protected] with subject line of domain.com. Once you have obtained the S/MIME certificate or PGP key, you should cc: encrypted messages to
[email protected].
9.
Click OK and review the policy summary. If it is correctly defined, click Save.
10. Apply the policy to the appropriate location in the Email Firewall
directory. For this example, apply it to the Internal folder so that all email users who attempt to send encrypted messages to your organization are prevented from doing so unless the message is also encrypted for Email Firewall, so that the message contents can be scanned prior to delivery within your organization. 11. Test the policy.
522
Chapter 9: Security Configuration
To create a plaintext access policy based on the sender of the encrypted message: 1.
In the left menu, click Policies.
2.
In the Policies page, click Create.
3.
In the Policies type page, Policy Name field, type Sender Plaintext Access.
4.
In the Plaintext Access row, use the drop-down arrow to select Sender and click Create.
5.
In the Policies > Edit Catch Conditions page, click Action.
6.
In the Policies > Edit Actions page, Deliver heading, mark the Return to radio button.
Sender
7.
Scroll down to the Apply Encryption tab and mark the Send signed notification to sender containing instructions for using the required server encryption checkbox.
The notification sent for OpenPGP operations will not be signed. It will be signed for S/MIME.
8.
In the Notification Text field, type the message text you want the message sender to read and act upon. For example: You must install the attached Email Firewall Public Key and cc: when sending encrypted mail.
9.
Click OK and review the policy summary. If it is correctly defined, click Save.
10. Apply the policy to the appropriate location in the Email Firewall
directory. For this example, apply it to the Internal folder so that messages that Email Firewall cannot decrypt are returned to the sender with the information that in order to send encrypted messages from your organization, the message must also be encrypted for Email Firewall so that the message contents can be scanned. 11. Test the policy.
9.14 Setting Up S/MIME and OpenPGP Client-to-Client Security
523
9.14.2 Creating Allow Security Stripping Policies Use Allow Security Stripping policies to strip encryption and digital signatures from messages when other policies need access to it, for example, to modify the message contents (e.g. remove virus-infected attachments). This is a “backup” policy to the Plaintext policy. Security stripping leaves recipients with nonsecure messages; you may want to restrict this policy to internal recipients only.
Both the sender and the recipient must have a Security Stripping policy in place before the policy will take effect. To create an allow security stripping policy: 1.
In the left menu, click Policies.
2.
In the Policies page, click Create.
3.
In the Policies type page, Policy Name field, type Sender Security Stripping.
4.
In the Allow Security Stripping row, use the drop-down arrow to select Sender and click Create.
5.
Review the summary of the policy: “Allow Email Firewall to decrypt the message when another policy requires access to it.”
6.
Click Save.
7.
Repeat the previous steps to create a recipient version of this policy, with these modifications: 7a. In step 3, type Recipient Security Stripping. 7b. In step 4, select Recipient instead of Sender.
8.
524
Apply both policies to the appropriate user records or folders.
Chapter 9: Security Configuration
9.14.3 Creating an Unencrypted Message Filter Policy Use this recipient policy to catch mail that is not encrypted, and will not be encrypted, though it should be. This policy is useful for preventing non-secure messages from being sent over the Internet. It examines non-secure messages for specific conditions that you specify when you create the policy. Keep in mind that the policy ignores all encrypted messages and it does not distinguish between encryption performed by Email Firewall and encryption performed by an S/MIME or OpenPGP desktop. This policy is an exception to the general rule that it is always preferable to use sender policies when possible.
To create an unencrypted message filter policy: 1.
Plan the policy before starting. For this example, we define an unencrypted message filter policy that returns all unencrypted messages sent to specified domains or users to the sender, with a notification sent to the sender from Email Firewall stating that all messages sent to that recipient must be encrypted. Then, we create a folder for the user and domain records that require encrypted messages.
2.
Create a notification that will alert your email senders that messages sent to the recipient must be encrypted. See 6.4.2 Creating a New Notification for a Policy Action on page 290 for information on how to create a new notification. For this example, the notification is named Sender Note - Must Encrypt. The notification should be sent to the sender of the message. In your notification text, use the placeholder $RECIPIENT to provide the sender with specific information about which recipient requires encrypted mail.
3.
Create the policy. In the left menu, click Policies.
4.
In the Policies page, click Create.
5.
In the Policies type page, Policy Name field, type Must Encrypt.
6.
In the Unencrypted Message Filter row, use the drop-down arrow to select Recipient and click Create.
7.
In the Policies > Edit Catch Conditions page, click Actions.
9.14 Setting Up S/MIME and OpenPGP Client-to-Client Security
525
8.
In the Policies > Edit Actions page, Deliver heading, mark the Return to radio button.
Sender
9.
In the Notify heading, mark the Send the notifications checkbox and click Select Notifications.
10. In the Select Notifications page, mark the Sender Note - Must Encrypt
checkbox and click Select Checked Notifications. 11. In the Policies > Edit Actions page, click Summary. Your policy summary
should look like the one in Figure 9.27. Figure 9.27: Unencrypted Message Filter Policy Example
12. Click Save to commit the new policy to the database. 13. Create a directory folder for the domain and user records which require
that messages to them be encrypted before sending. These records might include sensitive partners, suppliers, vendors, or special customers. See 5.3.4 Adding New Directory Objects on page 224 for information on how to add a folder to the directory. For this example, the folder is named Must Encrypt.
526
Chapter 9: Security Configuration
14. Apply the Must Encrypt policy to the Must Encrypt folder in the directory.
See 6.7 Applying the Policy to a Directory Object on page 301 for instructions on how to apply a policy to a directory object. 15. Add to the Must Encrypt folder the domain and user records of the
recipients who require encrypted mail. 16. Test the policy. Send an unencrypted email message to a recipient whose
user or domain record is in the Must Encrypt folder. 17. Verify the message is returned to you with the Sender Note - Must Encrypt
notification.
Sender-Based Unencrypted Message Filter Solution A problem arises when you have a sender-based policy to block all unencrypted messages, defined on the All folder, and the policy attempts to send a notification to the original message sender. In this case, the notification generated by the policy gets blocked by that policy when there will not be any encryption applied by the server (because the server does not know how to encrypt messages for the original message sender). There are two parts to the recommended solution. It is important to do both steps: 1.
Create a user record in the Email Firewall directory for the Email Firewall Notifier, using the same email address that you used for Notification Sender Email Address on the Web Admin Notifications page. This user record should be in the Internal folder, or in some sub folder thereof.) The unencrypted message filter policy must be disabled on this user record. This is effectively saying that mail sent from this address is allowed to be sent out, even when it is not encrypted or will not be encrypted by the server.
2.
To ensure that nobody outside of the Email Firewall system uses this exception as a security hole (by spoofing the sender address), create a Basic Mail Filtering policy to drop or quarantine all messages where this user is the sender. Apply this policy to the user record created in step 1.
The policy created and applied in Step 2 will not be enforced on the notifications generated by the unencrypted message filter. This is because the Basic Mail Filtering policies are decomposition phase policies. Only the composition phase policies are applied to policy-based notifications.
9.14 Setting Up S/MIME and OpenPGP Client-to-Client Security
527
9.14.4 Creating a Client Encryption and Signature Policy A client encryption and signature policy is used to monitor or act upon messages based on their state of security, such as “signed,” “encrypted and not signed,” or “not encrypted.” Figure 9.28 shows the encryption and signature catch condition selections. If you want to detect and act upon messages based on a particular state of their security or lack of security, and any additional criteria, create a Client Encryption and Signature policy. The last option Signed by a non-trusted CA shown in Figure 9.28 does not apply to the OpenPGP due to the PGP trust model.
Figure 9.28: Client-to-Client Encryption and Signature Catch Selections
528
Chapter 9: Security Configuration
To create a client encryption and signature policy: 1.
Plan the policy before starting. Decide what state of security or lack of security you want to detect and act upon. For this example, we want to catch messages that are encrypted and not signed. We do not want to allow encrypted, unsigned messages to be delivered either internally or externally.
2.
Create a notification that will alert email senders that if they want their message to be delivered, it must be signed if it is encrypted. See 6.4.2 Creating a New Notification for a Policy Action on page 290 for information on how to create a new notification. For this example, the notification is named Not Signed.
3.
Create the policy. In the left menu, click Policies.
4.
In the Policies page, click Create.
5.
In the Policies Type page, Policy Name field, type Not Signed.
6.
In the Client Encryption and Signature row, use the drop-down arrow to select Sender and click Create.
7.
In the Policies > Edit Catch Conditions page, Encryption and Signature heading, use the drop-down arrow to select Encrypted and Not Signed.
8.
In the Policies > Edit Catch Conditions page, click Actions.
9.
In the Policies > Edit Actions page, Deliver heading, mark the Return to radio button.
Sender
10. In the Notify heading, mark the Send the notifications checkbox and click Select Notifications.
11. In the Select Notifications page, mark the Not Signed checkbox and click Select Checked Notifications.
12. In the Policies > Edit Actions page, click Summary and review your policy. 13. Click Save to commit the policy to the database. 14. Apply the policy to the appropriate folder in the directory. For this policy,
the All folder may be a useful location if you do not want either internal or external senders transmitting encrypted, unsigned messages. See 6.7 Applying the Policy to a Directory Object on page 301 for instructions. 15. Test the policy. Send an encrypted, unsigned email message.
Verify the message is returned to you with the Not Signed notification.
9.14 Setting Up S/MIME and OpenPGP Client-to-Client Security
529
530
Chapter 9: Security Configuration
10
Administrative Tools
The Tumbleweed Email Firewall program provides tools that perform a variety of administrative functions. These tools include directory tools used to find and import new users into the Email Firewall Directory, tools to help with security administration, updates, and troubleshooting. This chapter describes these tools and instructions for how to use them. All tools that access the Email Firewall database rely on the role capabilities granted to the admin account. An administrator who wants to use these tools must have the appropriate role capabilities. For this reason, many of the tools require entry of a user name and password to use the tool. For LDAP Import, the administrator must have a role with access to the Email Firewall Directory. This chapter contains the following sections: 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10 10.11
Email Firewall Directory Tools .............................................. 532 Setting Up LDAP Directory Imports ...................................... 534 Performing the LDAP Import ................................................. 552 Using the Command Line Program Tools .............................. 560 Using the Word List Tester ..................................................... 564 Using the PrivateKeyWizard Tool........................................... 568 Using the Email Firewall Diagnostics Utility ........................ 582 Using the EMFDebugLogCapture Tool .................................. 590 Using EMFSave ...................................................................... 592 Using the Email Firewall Update Service.............................. 602 Using the Configuration Editor.............................................. 609
531
10.1 Email Firewall Directory Tools A default directory structure is set up during installation. See 5.3 Email Firewall Directory on page 220 for information. The two tools described here assist in using and setting up the Directory. They are: • •
Find User Import Directory
In the left menu, click Directory to open the Directory page. The buttons for these directory tools are found at the top of every Directory page. See Figure 10.1. Figure 10.1: Directory Tools
10.1.1 Find User If you know a user’s email address, you can search for that user in your Email Firewall Directory. In the left menu, click Directory to open the Directory page. In the Directory page, click Find User to open the Find User page. Type the user’s email address in the Find User with email address field, and click Find. You can also search the directory records to find a matching domain for the user if the specific user email address cannot be found. After typing the user’s email address, mark the Find matching domain record if no user record is found checkbox, then click Find. See Figure 10.2.
532
Chapter 10: Administrative Tools
The matching record (domain or user) determines which policies apply to the address. Figure 10.2: Using the Find User Directory Tool
10.1.2 LDAP Import Email Firewall uses the Lightweight Directory Access Protocol (LDAP) to add users from corporate address books or other LDAP-compliant sources to your Email Firewall Directory. The Email Firewall Import Directory tool allows user information to be imported into the Email Firewall Directory from both LDAP Server directories and LDAP Data Interchange Format (LDIF) files. Using LDAP Import you can import all users in a data source into one Email Firewall Directory folder, where you can apply common policies to all. You can also use filters to import only particular users or groups of users from a data source, and then apply policies to only those users and groups. You can schedule regular import updates to assure that the user lists in your Email Firewall Directory are current and up-to-date.
10.1 Email Firewall Directory Tools
533
10.2 Setting Up LDAP Directory Imports LDAP is an Internet standard directory service that runs over TCP/IP (Transmission Control Protocol/Internet Protocol) based on the client/server model. It allows an LDAP client to request an entry (e.g. a person’s record) from an LDAP server. For more detailed LDAP information, RFC 2251 defines the LDAP protocol operations and data model. The RFC 2251 protocol model is client/server based, with read and update access, using asynchronous requests and responses. In an LDAP directory, entries are organized in a hierarchic directory structure called a schema. The hierarchic structure is usually determined by organizational and geographical boundaries. The top node of the directory immediately under the root is typically represented by a country name; subdirectories are typically represented by geographic and physical location information; and the LDAP user entry is represented by a common name. This collective information about an entry’s location in the LDAP directory comprises its Distinguished Name, in which each item in the LDAP directory has a unique distinguished name. For example: CN=name, OU=Organizational Unit Name, O=Organization, C=Country
A mandatory attribute of each directory entry, called an object class, defines the specific set of required and optional attributes the entry contains. An entry can belong to one or more standard or auxiliary (user-defined) object classes. For example, if the object class is person, the attributes for that entry must include the user’s first and last name, and may include others such as telephone number and password. For additional information about the LDAP protocol, see . RFC 2849 provides information about the LDIF format, which is also used by Email Firewall for directory import. See 10.3.2 Creating LDIF Files on page 555 for more information on using LDIF files in LDAP Import.
534
Chapter 10: Administrative Tools
10.2.1 Configuring LDAP Import Mappings Before you can import LDAP users into your Email Firewall Directory, you must configure Email Firewall by setting up a sequence of mappings which are used to import the users from the specified data source. You must configure at least one mapping sequence, query, and data source before importing LDAP users. •
•
•
A mapping is a query that specifies a destination folder in the Email Firewall Directory. Users imported using this query will appear in the specified destination folder. A query is a set of import filters and restrictions used to import users into the Email Firewall Directory. The query targets a specific data source for import. A data source is an LDAP server or an LDIF file from which Email Firewall imports user records.
The steps of a sequence (mappings) are performed in order when a single sequence is used for import, starting at number one. Each mapping in the sequence supersedes the previous one. For this reason, you should order mappings so that the more general tasks are performed before the more specific ones. For example, suppose you want to import engineering users only into a destination folder named Engineering, but you also want the engineering managers to appear in a different folder, named Managers. The first query would specify that the user’s department equals Engineering. It would be mapped to the Engineering folder. The second query would specify that the user’s department equals Engineering and the user’s title equals Manager. It would be mapped to the Managers folder. During import, all Engineering users would be retrieved according to the specifications of the first mapping, and then the Engineering Managers would be moved to the Managers folder according to the specifications of the second mapping. If, however, you switched the order of the mappings, the more general one specifying department would take precedence over the one specifying both department and title, and all users would appear in the Engineering folder.
10.2 Setting Up LDAP Directory Imports
535
Attribute Mapping The Email Firewall LDAP data source attributes are configured based on schemas supported by Email Firewall. You can add, edit, and delete attribute name and ID pairs.
Attribute Mapping is not available for LDIF imports.
The default attributes used in imported user records include: • • • • • •
first name middle name last name (mandatory) email address (mandatory) delivery address aliases
Both last name and email address are listed as “mandatory” because a user who does not have both of these attributes in the Enterprise or External Directory cannot be imported. The default user attribute mappings, First Name, Middle Name, Last Name, Email and Delivery Address, are used to import values used by the imported Email Firewall record. However, if you do not want to map the First Name, Middle Name or Delivery Address, click Edit on the attribute row, and then make your changes in the Internal Source Identifier field.
Address
You can add additional attributes for query filters if your data source is an LDAP server. However, there is no schema discovery mechanism, so before identifying attributes, you should be thoroughly familiar with your directory schema. See Figure 10.3 for an example of other attributes. The default attribute mapping listed in Table 10.1 shows the source directory attributes that Email Firewall maps by default for two supported schemas.
536
Chapter 10: Administrative Tools
Table 10.1: User Attribute Mappings Email Firewall User Record Attribute
Sun ONE Schema Attribute
Microsoft Exchange Schema Attribute
First Name
givenName
givenName
Middle Name
middleName
initials
Last Name
sn
sn
Mail Address
mail
mail
Email aliases (up to 10)
no default
no default
Delivery Address
no default
no default
You can add to or modify an attribute mapping. For example, it might be necessary to add or modify an attribute mapping under the following conditions: • •
To create a query filter using the new source attribute. To re-map the Email Firewall user record attributes (i.e. first name, middle name, last name, mail address, delivery address) to the new source attribute.
Attribute mappings are defined during LDAP Sources configuration. Figure 10.3 shows an example of this information displayed in the Directory > Import Directory > LDAP Sources > Edit Source page. The attribute mappings are those shown using a Microsoft Exchange Server as the data source.
10.2 Setting Up LDAP Directory Imports
537
Figure 10.3: LDAP Import Data Source Attribute Mapping
The Directory > Import Directory > Data Source > Edit Source page has three columns under the Custom Filter Attribute Mapping heading: •
•
•
Attribute Name: This column is for display purposes only. The value typed in this column will appear as an available selection when mapping the named attribute when creating a query filter. Internal Source Identifier: The Internal Source Identifier column represents the actual attribute names in the LDAP source. Before adding an attribute, you must know the internal attribute name from the LDAP source. In many instances, the LDAP attribute display name is different from the actual internal LDAP attribute name. Action: • Use Add to add additional custom filter attributes and internal source identifiers. • Use Edit to change the Attribute Name or Internal Source Identifier. • Use Remove to delete an attribute you do not want to use. Note that the first five attributes in the list cannot be removed, only modified.
These attributes are used only to define an import query filter. The Email Firewall Directory Import tool allows filtering on attributes that are defined 538
Chapter 10: Administrative Tools
here. This feature can be used to build arbitrary groups of users by selectively importing users with different attributes into different folders in the Email Firewall directory.
10.2.2 Understanding the Directory Import Sequence To create a directory import sequence, begin in the Directory > Import Directory page. The Import Sequences page shows the list of import sequences. To begin creating a sequence, click Create. After a sequence has been created, the mappings that comprise an individual sequence are shown on the Directory > Import Sequences > Edit Sequence page. Mappings are created and edited within a sequence. Once a mapping is created, those mappings that are Enabled (shown in the State column on the Directory > Import Sequences > Edit Sequence page) are processed in the order in which they appear in this list. For each mapping, the corresponding query is executed using the data source as configured. Multiple import sequences can be specified, and sequences can also be scheduled. It is possible that a single user entry is returned by multiple queries. If this happens, each query in succession will supersede the changes from the previous queries. The final Destination folder of the user entry is determined by the last query that returns the user. An import will fail if any mapping does not work. Often, the cause of this failure is an inaccessible or invalid data source. It is recommended that the data source be tested before using it in a query.
Configuring an import sequence requires these basic steps: 1.
Specifying an LDAP server or LDIF file as the LDAP Source from which to import users.
2.
Configuring a Query to define specific users for import.
3.
Create an Import Sequence
4.
Create an Import Sequence Step by mapping the Query to a Destination folder in the Email Firewall Directory.
The import sequence can be used to: 1.
Perform an Import manually using Web Admin.
2.
Create an import schedule. 10.2 Setting Up LDAP Directory Imports
539
Each step builds on the previous one. You must configure a query using a data source to create a mapping. You must identify a data source to configure a query. The following subsections describe the procedures for identifying an LDAP Import Data Source, configuring a Query, and creating an Import Sequence that maps the query to the Email Firewall Directory Destination folder. These example procedures assume you have not previously configured any data sources, queries or sequences.
Special Considerations When Using Active Directory If you are using data from an Active Directory source, keep these points in mind: •
•
•
When creating an LDAP import source that uses Active Directory, only Authenticated Account access is allowed. Selecting Anonymous will not work. The Windows NT Account name used for authentication must be entered in the format \ and not CN=, CN= as used when connecting using Active Directory as the LDAP source. You must include the search root. Without the search root, LDAP import will not return any user or group. The default search root should be in the form of: cn=users, dc=tumbleweed, dc=com
For Active Directory with Organizational Unit specified, the search root should be in the form of: ou=, dc=tumbleweed, dc=com
10.2.3 Identifying the Data Source for LDAP Import To prepare for LDAP Import, the first step is to identify your data source. Web Admin supports the import of up to 30,000 user records in one LDAP Import sequence. More than that number, the browser may time out. If an LDIF file is used as the data source, the path to the LDIF file can be entered as an alternative to uploading the LDIF file to the database. If there are multiple import scheduling services running on different machines, the path must be a UNC path to enable use of the path from different machines. See 10.4.1 MMSLDIFImportConfig on page 560.
540
Chapter 10: Administrative Tools
To identify the data source: 1.
In the left menu, click Directory to open the Directory page.
2.
In the Directory page, click Import Directory to open the Directory > Import Directory page.
3.
Click LDAP Sources to open the Directory > Import Directory > Data Source page. See Figure 10.4.
Figure 10.4: Identifying the Data Source for LDAP Import
4.
In the Data Source Type column, use the drop-down list to select the data source type you will be using, either an LDAP Server or an LDIF File. For this example, select LDAP Server.
5.
In the Data Source Name column, type a descriptive name for the name of the data source in the field, usually the name of the server or the name of the LDIF file. For this example, type test.
6.
In the LDAP Schema Type column, use the drop-down arrow to select the schema type. The currently supported schemas include: • • • •
Microsoft Active Directory Exchange 5.5 Lotus Notes Sun One
For this example, select Exchange 5.5. If you are using Active Directory, refer to Special Considerations When Using Active Directory on page 540 before proceeding.
10.2 Setting Up LDAP Directory Imports
541
7.
In the Action column, click Create to open the Directory > LDAP Sources > Edit Source page where you specify additional information about your data source. You can use an LDIF file generated by an external directory or some other tool. Or, if you plan to create your own LDIF File as your data source, read 10.3.2 Creating LDIF Files on page 555.
8.
If you selected an LDAP Server as the data source type, define the following parameters as shown in Figure 10.5.
Figure 10.5: LDAP Server as LDAP Import Data Source
9.
Verify the correct LDAP Schema Type is showing. If it is not, use the dropdown arrow to make your selection now.
10. Type the name or IP address of the Directory Host for the LDAP Server.
Use the server_name.domain.com format for the directory host name. 11. Type the port number on which the LDAP Server connects. The default
port is 389.
542
Chapter 10: Administrative Tools
12. Optionally, type the Search Root directory information to narrow the
directory host search: Type the Search Root information directly into the field in the format OU=organizational_unit, O=organization, C=country.
Or, click Enter as Distinguished Name to open the Edit Distinguished Name pop-up page to enter Country and Organization distinguished name attributes. See Figure 10.6. Figure 10.6: Entering Distinguished Name Attributes
13. Click Update to save the data to the session and close the pop-up page. 14. In the Directory > LDAP Sources > Edit Source page, see Figure 10.5,
beside the Login heading, mark the Anonymous radio button if your LDAP server does not require authentication to connect. Or, mark the Authenticated Account radio button if you are connecting to an LDAP server that requires authentication, and type the Account and Password information in the fields provided. 14a. If you marked the Authenticated Account radio button, you can
enter the Account information using distinguished name attributes. Click Enter as Distinguished Name to open the Edit Distinguished Name pop-up page to enter distinguished name attributes. See Figure 10.6. Note that in addition to the fields shown in Figure 10.6, you can also define distinguished name attributes by common name. Type the attributes in the Common Name: CN1= and CN2= fields.
10.2 Setting Up LDAP Directory Imports
543
For example, the Windows Account information used to authenticate an MS Exchange Server is represented by CN1= and CN2=. 14b.Click Update to commit the data to the session and close the popup page. 15. Once your Data Source is created, you can specify its Attribute Mapping.
Refer to Attribute Mapping on page 536 for background information on making these selections. 15a. In the Directory > LDAP Sources page, in the Action column of
the new data source, click Edit to open the Directory > Import Directory LDAP Sources > Edit Source page. 15b.In the Default User Attribute Mappings group box, optionally click Edit to more closely define your attribute mappings with your data source. 15c. In the Custom Filter Attribute Mappings group box, optionally click Edit or Remove to more closely define your attribute mappings with your data source. Or, add one or more additional Attribute Name and Internal Source Identifier to more closely define your attribute mappings with your data source. 15d.Optionally, in the Email Aliases group box, enter an Internal Data Source Identifier for email aliases in the field and click Add. 16. Click Save to commit the new data source information to the database.
LDAP Import and MS Exchange Issue When configuring an LDAP import source, it will not be possible to save the configuration if an invalid search root is entered. There is one exception to this. If the remote LDAP server is an MS Exchange server, an invalid c= or co= entered as the final name/value pair of an otherwise valid search root will be accepted. (“c” or “co” is used to specify a country component in a DN). This will cause problems performing a group import from this LDAP source. It is recommended that when configuring an MS Exchange LDAP source, if entering a search root that ends with either c= or co=, verify that this is part of the DN of the base object in the Exchange server from which searches are to be performed.
544
Chapter 10: Administrative Tools
10.2.4 Configuring a Query for LDAP Import To configure a query for LDAP Import, the following steps must be followed: 1.
Select your data source.
2.
Specify a filter (LDAP server only).
3.
Select a group (LDAP server only).
4.
Preview your query.
The entries returned by a query are determined by: • • • • •
the search base distinguished name of the source filters group the presence of last name and email addresses server settings, which affect the results size limit, paging support, and access controls
To configure a query for LDAP import: 1.
In the Directory> Import Directory page, click LDAP Queries to open the Directory > LDAP Queries page. See Figure 10.7.
Figure 10.7: Creating a Directory Import Query for LDAP Import
2.
In the LDAP Query Name column, type a descriptive name in the field. For administrative ease, it makes sense to type a name similar to the name of the Data Source that will be invoked by the query. For this example, type
10.2 Setting Up LDAP Directory Imports
545
Test query. We will use the data source test created in 10.2.3 Identifying the Data Source for LDAP Import on page 540.
3.
In the Data Source column, use the drop-down list to select the data source. In this example, select test.
4.
In the Action column, click Create to open the Directory > LDAP Queries > Edit Query page. See Figure 10.8.
5.
Beside the Group heading, select a group. You must select either All groups or a specific group, or else the query cannot be saved.
6.
Beside the Filter heading, see Figure 10.8, mark one of the radio buttons: • Mark No filter (include all records) to import them all, unfiltered. • Mark Include only records caught by filter to import only those records matching the query filter. • Mark Exclude records caught by the filter to import all others but exclude those records matching the query filter.
Figure 10.8: Defining a Query for LDAP Import
546
Chapter 10: Administrative Tools
7.
If you marked either the Include only... or the Exclude records... radio button, create a filter. Under the Filter Specification heading (see Figure 10.9): 7a. In the Attribute column, use the drop-down list to select among the
attributes present in your data source. 7b. In the Condition column, use the drop-down list to select among the options shown in Figure 10.9. Figure 10.9: LDAP Import Filter Conditions
7c. In the Value column, type the value for which you want to filter. 7d. Click Add and verify the new filter attribute appears in the Filter Specification
list.
7e. Optionally, repeat steps 7a through 7d to add additional filter
attributes. If you do so: In the Conjunction column, use the drop-down arrow to select And or Or, to include or exclude against the other selected attributes. See Figure 10.10. 7f. Click Preview to view the filtered results, to be sure you have caught or excluded the intended users. Use Edit and Delete if you need to modify a filter attribute, condition, value or conjunction value.
10.2 Setting Up LDAP Directory Imports
547
Figure 10.10: Adding Additional LDAP Import Filter Conditions
8.
Click Save to commit the new query to the database and close the page. Once you have created a query and data sources, click Duplicate to quickly create an identical query. Then, give it a new name and edit it to select a different data source, filter specifications or mapping.
9.
In the Directory > LDAP Queries page, verify the new query appears in the LDAP Query Name column.
10.2.5 Configuring a Mapping for LDAP Import The Email Firewall LDAP import mapping configuration consists of the following: • • • •
548
selecting a query browsing the Email Firewall directory for a destination folder into which users will be placed enabling or disabling the mapping moving mapping(s) up and down in the mapping order
Chapter 10: Administrative Tools
Before performing an LDAP import, be sure you have an existing Email Firewall Directory object into which to place the imported users. If not, create one before proceeding with the import. See 5.3 Email Firewall Directory on page 220 for more information on using the Email Firewall Directory structure and hierarchy. To configure a mapping sequence: 1.
In the Directory > LDAP Queries page, verify your new Test query is listed.
2.
Click Import Sequences to open the Directory > Import Sequences page.
3.
In the Sequence field, type a name for the mapping and click Create.
4.
In the Directory > Import Sequences > Edit Import Sequence page, type a meaningful Description in the text box and click Create.
5.
In the Directory > Import Sequences > Edit Import Sequence > Edit Import Step page: 5a. Use the Query drop-down list to select a query, for this example,
select test. 5b. Beside the Destination Folder heading, click Browse and then in the Select Destination Folder pop-up, click Open to navigate to the directory folder where you want to place the imported user records. See Figure 10.11. Figure 10.11: Selecting an LDAP Import Destination Folder
10.2 Setting Up LDAP Directory Imports
549
5c. Click Select to specify the folder, commit the information to the
session, and close the pop-up page. 5d. In the Directory > Import Sequences > Edit Import Sequence >
Edit Import Step page, Destination Folder heading, verify the path and folder you selected is listed. All Email Firewall policies that apply to the selected folder will apply to the users who are imported here using LDAP Import. 5e. Use the drop-down list to select Enabled if it is not already
selected. 5f. Click OK. 6.
In the Directory > Import Sequences > Edit Import Sequence, verify the Query, Destination and State information is correct.
7.
Click Save.
8.
In the Directory > Import Sequences page, verify the new sequence is listed in the Sequence column.
10.2.6 The Email Firewall LDAP Import Process When you perform the LDAP Import, the following events occur:
550
1.
The import is aborted if any query of an enabled mapping in the series fails.
2.
The combined query results are processed to remove duplicate users (selected by email address). The order of the import steps are determinative in selecting which duplicates to discard.
3.
The Email Firewall Directory is searched for each entry in the query results, by email address.
4.
Add and Move modifications are generated. Update modifications may also be generated, if a previously imported record has been modified in the external directory so that its attributes need to be updated.
5.
These modifications are applied directly if Preview Changes is not selected, even if Clean Up Directory is selected.
Chapter 10: Administrative Tools
• If Clean Up Directory is selected: Do not perform a directory clean up if you have temporarily disabled a query (for example, if it was disabled because a particular server is down). Performing a directory clean up will delete all users who are not returned by the disabled query.
• Email Firewall will read all previously imported users from the directory. • Email Firewall will generate Delete modifications for user records not found in the query results. Depending on the size and complexity of your directory environment and your data source, this may take some time.
6.
If Preview Changes is selected, modifications, including add and delete modifications, are displayed for review before being applied.
10.2 Setting Up LDAP Directory Imports
551
10.3 Performing the LDAP Import Once you have identified an LDAP import data source, configured a query using the data source, and created a sequence that includes a mapping of the query to a Email Firewall Directory folder, you can perform the import. You may also want to create an import schedule to automate the process. To perform the LDAP Import: If you have previously performed an LDAP Import, be sure to prevent updates on any user records you do not want moved or changed by this import. See 10.3.3 Stopping Updating of User Records on page 557 for more information. 1.
In the Directory > Directory Import page, Import Now tab: 1a. Mark the Perform Cleanup checkbox if you want Email Firewall to read all previously imported user records and delete them if they are not found in the current query. (Manually added and user records for which updates are prevented are not affected). See 10.3.4 Cleaning Up the Directory on page 558 for more information. 1b. Mark the Preview Changes checkbox if you want to see the changes to your directory before accepting the users who will be imported to or deleted from your Email Firewall Directory. (Recommended)
2.
Click Import Now.
If you marked the Preview Changes checkbox: 3.
In the Preview of Requested Directory Modifications tab, review the total number of users to be added, moved, updated and deleted, and the total number of operations that will be performed.
4.
In the Currently Requested Directory Modifications tab, review the planned import, before committing to the import. 4a. Review the users by User Name who will be imported. 4b. Review the Operation to be performed by the planned import: Move, Delete, Add.
4c. Review the folder From which they are being moved (if any) and
the folder To which they are being added or moved.
552
Chapter 10: Administrative Tools
4d. In the Action column:
• Click Details to see more information about any particular user. • Click Delete to remove any user modification, or mark the checkbox beside any number of user modifications you want to omit from the import, and click Remove Checked Rows. 5.
Click Apply Directory Modifications to complete the import and open the LDAP Import Report pop-up page and review the import operations performed.
6.
On the Completed Directory Modifications tab, review the operations performed.
7.
On the LDAP Import Log File tab, optionally: • Click View Log to review the log file in your browser. • Click Save Log as File to keep a permanent record of the import.
8.
Click Close to complete the import review.
10.3.1 LDAP Import Scheduling Once you have identified an LDAP import data source, configured a query using the data source, and created a sequence that includes a mapping of the query to a Email Firewall Directory folder, you can schedule regular directory imports. The Import Scheduling service will not work on a replication subscriber. Import will occur only on the publisher. For more information, see the Tumbleweed Email Firewall Best Practices Guide.
To set up LDAP Import scheduling: If you have previously performed an LDAP Import, be sure to prevent updates on any user records you do not want moved or changed by this import. See 10.3.3 Stopping Updating of User Records on page 557 for more information. 1.
In the Directory > Directory Import page, Scheduled Imports tab, use the Sequence drop-down list to select the sequence to import.
2.
Click Create.
10.3 Performing the LDAP Import
553
3.
In the Directory > Directory Import > Edit Scheduled Import page, see Figure 10.12, specify the schedule. The schedule can be set to run on specified days of the week, or set to run periodically based on number of minutes, hours or days. 3a. For weekly runs, mark the Run every week on radio button and
mark the checkbox(es) to specify the days and complete the time fields. 3b. For periodic runs, mark the Run every radio button and complete the fields to specify the periodicity in number of Minutes, Hours or Days. 4.
Click Save.
Figure 10.12: Setting Up an LDAP Import Schedule
5.
554
In the Directory > Directory Import page, verify the new schedule appears on the Scheduled Imports tab.
Chapter 10: Administrative Tools
How Deleting Directory Import Sequences Affects User Records An imported user record is not deleted by deletion of an Import Sequence. When an Import Sequence is deleted, that sequence's ID is removed from the list of IDs associated with each user record that was imported by that sequence. If a user record was imported only by the deleted sequence, that user record cannot be removed using LDAP Import (with Perform Cleanup selected), because Perform Cleanup only removes user records imported previously by the sequence currently being used for import. If the user record was also returned by another sequence, then the user record will be deleted during an import using that sequence, if that user record is no longer imported by that sequence. To delete an import sequence, in the scheduled sequence's row, click Delete.
10.3.2 Creating LDIF Files LDAP Data Interchange Format (LDIF) files are commonly used to exchange directory information between directory servers. These files are also used when Email Firewall does not have a direct network connection to the LDAP directory source, or when directory entries require modifications prior to being imported into Email Firewall. Attribute filtering is not supported when importing from an LDIF file. All the records with the object class of ‘person’ will be imported into the Email Firewall Directory.
To create an LDIF file: 1.
Use a text editor such as WordPad to create a new text file.
2.
Type entries in the following format:
dn: uid=, ou=, o= sn: givenname: middlename: objectclass: person mail: cn:
10.3 Performing the LDAP Import
555
Each line is separated by a paragraph, and each entry can be separated by two or more paragraphs. More parameters can be added depending on your needs. Following is a typical LDIF file user entry: dn: uid=bfree, ou=People, o=Tumbleweed.com cn: Bjorn Free sn: Free givenname: Bjorn objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson ou: Human Resources ou: People l: Santa Clara uid: bfree mail:
[email protected] telephonenumber: +1 408 555 1212 facsimiletelephonenumber: +1 408 555 1234 roomnumber: 3307 userpassword: etiquette 3.
Save the file.
To use the LDIF file in LDAP Import: 1.
Configure the file as a data source in the Directory > LDAP Sources page. See 10.2.3 Identifying the Data Source for LDAP Import on page 540 for instructions. Figure 10.13 shows the Data Source > Edit Source page where you identify your LDIF file.
2.
Type the path and file name, or use Browse to locate the file and select it. If entering a path and file name, this path must be accessible from all machines using the source for import (e.g. systems running the Import Scheduling service), and for this reason a UNC path is recommended. Then click Save.
3.
556
Continue with the LDAP Import steps described in 10.2.4 Configuring a Query for LDAP Import on page 545 and 10.2.5 Configuring a Mapping for LDAP Import on page 548.
Chapter 10: Administrative Tools
Figure 10.13: LDIF File as LDAP Import Data Source
10.3.3 Stopping Updating of User Records User Records in your directory that were imported using LDAP Import can be “pinned” using the Stop Updates option so that subsequent imports will not change their location, delete them or modify their user record information. Stopping updates is useful if you want to group a set of user records by a common attribute not defined at the data source. For example, there might not be an attribute to define users with the title Engineer who are also contractors. However, you can create an Email Firewall Directory folder named Contractors, and then move those users’ records into that folder and prevent them from being updated there. Once updates are stopped, their user records will not be moved back to the engineering folder during the next LDAP import. The fields in the user record are not editable for an imported user record, unless Stop Updates is selected. When Stop Updates is selected, the user record Name,
Delivery Address and Email Alias fields are now editable. If the record can be
10.3 Performing the LDAP Import
557
updated by directory import, then these attributes cannot be modified manually, as the changes would be lost during the next import. To stop updates of LDAP-imported users: 1.
In the directory folder containing the user records you want to pin, mark the checkbox beside each user record you want to prevent from being updated.
2.
Click Stop Updates. Users who are added manually are not affected by LDAP Import modifications.
To allow user records to be updated, click Restart Updates.
10.3.4 Cleaning Up the Directory Before performing an LDAP Import, if you mark the Clean Up Directory checkbox, Email Firewall will read all previously imported user records from the directory. Do not perform a directory clean up if you have temporarily disabled a query (for example, if it was disabled because a particular server is down). Performing a directory clean up will delete all user records in that sequence that are not returned by the disabled query.
Cleanup will delete user records previously imported by the sequence that are no longer returned by that sequence (not all imported records), if they are not found in the current import results. A user will not be deleted if it is still imported by another sequence. If your directory includes a large number of user records, directory cleanup could take some time. If you do not want particular user records deleted during cleanup, be sure to prevent an update on the user record first. See 10.3.3 Stopping Updating of User Records on page 557.
558
Chapter 10: Administrative Tools
10.3.5 Email Firewall LDAP Import Log File The Email Firewall LDAP Import log file contains information generated by the import. For import using the Web Administration component on the Web Administration server, the log file can be viewed and downloaded from the Web Administration server as a file named ldiMMDDHHMM.log (where MMDDHHMM corresponds to the time the file was created). To view or save the log after LDAP Import: 1.
In the Currently Requested Directory Modifications tab: • the Get Log File button appears on this page if there are no modifications to apply. Click Get Log File to open the page with both the Completed Directory Modifications tab and the LDAP Import Log File tab. • If there are modifications, then the title of this button is Apply Directory Modifications. Click this button to apply the modifications. Email Firewall then opens the page with the Completed Directory Modifications tab and the LDAP Import Log File tab.
2.
Review the information and message on the tabs, including the log file size. Then, click View Log to view the log, or click Save Log as File to open the download pop-up dialog where you can specify the location where you want to save the log file.
10.3 Performing the LDAP Import
559
10.4 Using the Command Line Program Tools This section describes the Email Firewall command line program tools and utilities: • •
MMSLDIFImportConfig EMFSave
To invoke the command line program tools: 1.
Click the Start button, Run command to open the Run window.
2.
Type cmd in the Open field (or use the drop-down arrow to select cmd) to open the command (DOS) window.
3.
Type the path to, and the command for, the tool you want to run, followed by the tool parameters, then press Enter.
A user name and password with access to the Email Firewall database is required.
10.4.1 MMSLDIFImportConfig This tool is used when an organization wants to set up Email Firewall Directory Import to use an LDIF file stored in the Email Firewall database as a data source. The tool is not needed when the data source is configured to use an LDIF file specified as a file path. The MMSLDIFImportConfig command line tool enables dynamic updates to the LDIF file content. The tool uploads the data used in the LDIF source file to the Email Firewall database. This ensures that the LDIF data used for directory import is current with the version of the data in the organization’s LDIF file. However, any subsequent changes to the original LDIF file are not reflected in the previously uploaded file. To use this tool, the organization’s LDAP server is set up so that a script dynamically generates an LDIF file from the organization’s LDAP server data. Then, the Email Firewall Directory Import is set up to use that LDIF file as a data source for LDAP import. See 10.2 Setting Up LDAP Directory Imports on page 534 for information. This tool allows updates to the LDIF file content in the Email Firewall database. It provides a way for the Email Firewall LDAP
560
Chapter 10: Administrative Tools
Import to pick up changes to an LDIF file that is being dynamically generated. Because this tool can be invoked from a script, you can schedule the upload of the current contents of an LDIF file to the database. MMSLDIFImportConfig is installed with the Email Firewall Content Service, but can be run on any machine. Usage: MMSLDIFImportConfig -f -l [-s -g] [-u -p
Table 10.2: MMSLDIFImportConfig Tool Parameters Tool Parameter
Description
-f
Specifies the file to be uploaded.
-l Specifies the configured LDIF source in the LDAP import data source configuration to be updated with the specified file -s
Name of the Email Firewall 6.1 SQL Server
-g
Catalog Name of the Email Firewall Database
-u
User Name used to log in to the Email Firewall Database
-p
Password used to log in to the Email Firewall Database
10.4.2 EMFSave The EMFSave command line tool is a command line version of the EMFSave tool described in 10.9 Using EMFSave on page 592. It is provided for administrators who want to create scripts to perform the EMFSave. It supports all the options available in the EMFSave UI version. The following commands can be executed from the command prompt: • •
Copy Restore
To invoke the tool, in the command window type C:\Program Files\Tumbleweed\Email Firewall> EMFSave /?
A valid User name and Password are required to access the Email Firewall database.
10.4 Using the Command Line Program Tools
561
The file C:\Program Files\Tumbleweed\Email Firewall\cmdlinelog.txt that contains the usage of this tool will be created. Usage: EMFSave [options] (copy | restore) dbname zipfile tempdir [password]
The database name, zip file name and path and the temp directory must be specified. Password is optional. Other options supported are described in the following table. Table 10.3: Options Supported by EMFSave Command Line Utility
562
Option
Description
-config
save or restore configuration data
-directory
save or restore directory data
-eventlog
save or restore event log
-message
save or restore message data
-report
save or restore report data
-security
save or restore security data
-privatekey
save or restore private key data
-diagnostics
save or restore system diagnostics data
-sqljobs
save or restore SQL jobs
-continue
continue without showing the End Zip Wait Dialog
-qall
save or restore all queues
-qarchive
save or restore archive queue
-qdead
save or restore dead letter queue
-qdefer
save or restore defer queue
-qdetention
save or restore detention queue
-qinbound
save or restore inbound queue
-qoutbound
save or restore outbound queue
-qpartition
save or restore partition queue
Chapter 10: Administrative Tools
Table 10.3: Options Supported by EMFSave Command Line Utility (Continued) Option
Description
-qquarantine
save or restore quarantine queue
-qredirect
save or restore redirect queue
-qreturn
save or restore return queue
-neventreport n
save or restore event log and report in last n number of hours
-feventreport "mm/dd/yyyy hh:mm:ss" save or restore event log and report from mm/dd/yyyy hh:mm:ss -teventreport "mm/dd/yyyy hh:mm:ss" save or restore event log and report to mm/dd/yyyy hh:mm:ss -nmessage n
save or restore messages in last n number of hours
-fmessage "mm/dd/yyyy hh:mm:ss"
save or restore messages from mm/dd/yyyy hh:mm:ss
-tmessage "mm/dd/yyyy hh:mm:ss"
save or restore messages to mm/dd/yyyy hh:mm:ss
10.4 Using the Command Line Program Tools
563
10.5 Using the Word List Tester The Email Firewall Word List Tester is an application that helps you validate word lists and check processing time for both word and address lists before they are added to your Email Firewall policies. Improperly formed word and address lists can cause unexpected policy errors and substantially decrease performance. You can save the results of the tests for future reference. The tool allows you to performs the tasks shown in Figure 10.14. Figure 10.14: Word List Tester
10.5.1 Validating Word Lists The Validate Word List option allows you to validate the entries in a word list file before using them in Email Firewall policies. The character set used in word list files should be UTF-8. This character set is normally supported by most common text editors. For example, when using Notepad, you can select to Save As, and in the Encoding heading, use the dropdown list to select UTF-8. If the file contains non-ASCII characters, these also
564
Chapter 10: Administrative Tools
can be uploaded and imported as long as the character set used in the file is UTF-8. If you obtained the word list file by exporting it from Email Firewall, it should already use the UTF-8 encoding. If you are manually editing such word list files, remember to use the UTF-8 encoding when saving the file. Word List Tester will interpret the content of the word list files as UTF-8. However, if the file contains illegal UTF-8 content, the Word List Tester will silently ignore the illegal UTF-8 content and process the remaining content. When you are adding the word list in Web Admin, however, any phrases that have illegal UTF-8 content will be reported. To validate a Word List: 1.
Go to Start > All Programs > Tumbleweed Email Firewall > EMFWordListTester.
2.
Select the File menu, Validate Word List command.
3.
In the Select Word List File dialog, navigate to the location of the word list you want to validate, and click Open to select it. The file must be in the format of a text file.
4.
Review the results of the test. Figure 10.15 shows a sample validation.
Figure 10.15: Word List Validation Result
10.5 Using the Word List Tester
565
5.
If you want to save the results, select the File menu, Save Result command.
6.
Correct any errors in syntax in the word list file, and check the file again.
7.
When the file is free of errors, it can be added to your Email Firewall word lists and used in policies. For information about adding Word Lists to Email Firewall, see 6.2.2 Word Lists on page 258.
10.5.2 Checking Word List Processing Time A word list should be validated before checking for processing time. If a word list is not valid, it cannot be time processed.
Some word lists, especially those using multiple wildcard characters (*) in text strings or in regular expressions, can result in long processing times and effectively cause Email Firewall to hang. To avoid this performance penalty, check your word list processing time with the tool. To validate a word list’s processing time:
566
1.
Go to Start > All Programs > Tumbleweed Email Firewall > EMFWordListTester.
2.
Select the File menu, Check Word List Processing Time command.
3.
In the Select Word List File dialog, navigate to the location of the word list you want to process, and click Open to select it. The file must be in the format of a text file.
4.
Review the results of the test. Figure 10.15 shows a sample result.
Chapter 10: Administrative Tools
5.
If you want to save the results, select the File menu, Save Result command.
Figure 10.16: Word List Processing Time Result
10.5.3 Checking Address List Processing Time Some word lists, especially those using multiple wildcard characters (*) in text strings or in regular expressions, can result in long processing times and effectively cause Email Firewall to hang. To avoid this performance penalty, check your word list processing time with the tool. To validate an address list’s processing time: 1.
Go to Start > Programs > Tumbleweed Email Firewall > EMFWordListTester.
2.
Select the File menu, Check Address List Processing Time command.
3.
In the Select Address List File dialog, navigate to the location of the address list you want to process, and click Open to select it. The file must be in the format of a text file.
4.
Review the results of the test.
5.
If you want to save the results, select the File menu, Save Result command.
10.5 Using the Word List Tester
567
10.6 Using the PrivateKeyWizard Tool The PrivateKeyWizard tool is used to perform four private key operations within Email Firewall. These options are shown in Figure 10.17. For a discussion about using third-party certificates in Email Firewall security, see 8.10 Third-Party Certificates and Email Firewall on page 397. In a replicated environment, the first, third and fourth options shown in Figure 10.17 should only be performed against the publisher. The second option does not modify any database information and can be run on machines connected to the subscriber. Figure 10.17: Selecting the Private Key Operations Options
568
Chapter 10: Administrative Tools
The PrivateKeyWizard tool is started using the Start > All Programs > Tumbleweed Email Firewall > PrivateKeyWizard series of commands.
10.6.1 Specifying a New Password To specify a new password with which to protect the private keys in the database: 1.
Start the PrivateKeyWizard tool to open the Choose a Private Key Operation dialog. See Figure 10.17.
2.
Mark the Specify a new password with which to protect the private keys in the database radio button and click Next.
Figure 10.18: Specifying the Database
10.6 Using the PrivateKeyWizard Tool
569
3.
In the Select the Email Firewall Database dialog: 3a. Complete the Server and Catalog fields to identify the database in
which to perform the private key operations. 3b. Complete the Username and Password fields using the username
and password that are used to logon to the specified database. 4.
Click Next.
Figure 10.19: Changing the Private Key Password
570
5.
In the Change Protection Password dialog, type the Old Password, New Password, and type the new password again in the Confirm New Password field.
6.
Click Finish.
Chapter 10: Administrative Tools
Two operations are performed: • The private keys stored in the database are unprotected using the old password and re-protected using the new password. • The new password is set in the registry of the local machine. 7.
After the private key(s) in the database have been protected using the specified new password, you should set the same password in the local registry of all machines that run the Policy Engine service, SMTP Relay service, Archive service or the Web Admin components. This is done by running the PrivateKeyWizard tool on each of those machines and performing the Input the password used to protect the private keys in the database procedure.
This option should be used as part of general good security practice of changing passwords at regular intervals.
10.6.2 Inputting a Password to Protect Private Keys This option is used on distributed machines that have an SMTP Relay, Policy Engine, Archive Service or a Web Admin component, after specifying a new password. To input the password used to protect the private keys in the database: 1.
Start the PrivateKeyWizard tool to open the Choose a Private Key Operation dialog.
2.
Mark the Input the password used to protect the private keys in the database radio button, see Figure 10.20, and click Next.
10.6 Using the PrivateKeyWizard Tool
571
Figure 10.20: Selecting the Input the Password Option
3.
In the Select the Email Firewall Database dialog, see Figure 10.18, complete the Server and Catalog fields to identify the database in which to perform the private key operations. Complete the Username and Password fields using the username and password that are used to logon to the specified database. The Database access information is requested to check whether the given password is the correct one that was used to protect the private key in the database.
4.
572
Click Next.
Chapter 10: Administrative Tools
Figure 10.21: Selecting a Password to Protect Private Keys
5.
In the Select a Password dialog, complete the Password and Confirm fields. See Figure 10.21.
Password
6.
Click Finish. This operation stores the password in the registry of the local machine. This operation will also use the password to decrypt the private keys in the database, to validate that the specified password is correct. If not correct, the administrator is prompted with a dialog that provides an option whether to store the password or not.
10.6 Using the PrivateKeyWizard Tool
573
10.6.3 Importing Private Keys from a PKCS#12 File This option is used when importing TLS certificates. It may also be used for importing EMF or MMS SPN certificates. This option replaces the MMSPrivateKeyImport command line tool available in previous versions of Email Firewall (MMS). To import private keys from a PKCS#12 formatted file: 1.
Start the PrivateKeyWizard tool to open the Choose a Private Key Operation dialog.
2.
Mark the Import private keys from a PKCS#12 formatted file radio button, see Figure 10.22, and click Next.
Figure 10.22: Selecting the Import Private Key Option
574
Chapter 10: Administrative Tools
3.
In the Select the Email Firewall Database dialog, see Figure 10.18, complete the Server and Catalog fields to identify the database in which to perform the private key operations. Complete the Username and Password fields using the username and password that are used to logon to the specified database.
4.
In the PKCS 12 File Selection dialog, click the ellipses button (...) to access the Open dialog. See Figure 10.23.
Figure 10.23: Selecting the PKCS#12 File
10.6 Using the PrivateKeyWizard Tool
575
5.
In the Open dialog, navigate to the PKCS#12 file that contains the private key and the corresponding certificate that you want to import, and select it. See Figure 10.24. PKCS#12 files usually have the extension .p12, but sometimes PKCS#12 files have the extension .pfx.
Figure 10.24: Selecting the PKCS#12 File
6.
576
After it is selected, in the PKCS 12 dialog, click Next.
Chapter 10: Administrative Tools
Figure 10.25: Selecting the PKCS#12 Import Options
7.
In the PKCS 12 Import Options dialog, see Figure 10.25, optionally mark the Trust root keys imported from file checkbox to specify that the root keys imported from the file should be trusted. If you select this option, the certificate of the CA or the issuer, also known as the Root certificate, is also imported as a “Trusted Root,” if the Root certificate is available in the PKCS#12 file. 7a. If you marked the Trust root keys imported from file checkbox,
mark the checkbox(es) to specify the purposes for which this Root certificate should be used to trust certificates. 8.
Click Next.
10.6 Using the PrivateKeyWizard Tool
577
9.
In the PKCS12 Passwords dialog, enter the password used to protect the PKCS#12 file and the password that is used to protect the private keys in the database. See Figure 10.26. The File Protection Password is the password that protects the PKCS#12 file. The Private Key Password should be the same password that was entered when running the installer, or the password last set using the Private Key Wizard tool.
Figure 10.26: Identifying the PKCS#12 File and Database Passwords
10. Click Finish.
The certificate is imported and shown in the Set Up > Secure Domains & Local Certificates (and SPN Setup) page on the Local Certificates tab. If the option was selected, the Root Certificate is imported and shown on the Trusted Root Keys tab. Any intermediate CA certificates present in the PKCS#12 file are imported and shown on the Set Up > S/MIME Certificates page. 578
Chapter 10: Administrative Tools
The associated private key is also imported. It is encrypted using the Private Key password before being stored in the database.
10.6.4 Importing PGP Keys The Import PGP Secret Key File option is used to import PGP keys. PGP key files have the extension .asc. To import private keys from an .asc file: 1.
Start the PrivateKeyWizard tool to open the Choose a Private Key Operation dialog.
2.
Mark the Import PGP Secret Key File radio button, see Figure 10.27, and click Next.
Figure 10.27: Selecting the Import PGP Secret Key File Option
10.6 Using the PrivateKeyWizard Tool
579
3.
In the Select the Email Firewall Database dialog, see Figure 10.18, complete the Server and Catalog fields to identify the database in which to perform the private key operations. Complete the Username and Password fields using the username and password that are used to logon to the specified database.
4.
In the PGP Secret Key File Selection dialog, click the ellipses button (...) to access the Open dialog. See Figure 10.28.
Figure 10.28: Selecting the Import PGP Secret Key File Option
580
5.
In the Open dialog, navigate to the PGP key file that contains the PGP key that you want to import, and select it.
6.
In the PGP Secret File Passwords dialog, enter the password used to protect the PGP Secret Key and the password that is used to protect the private keys in the database. See Figure 10.29.
Chapter 10: Administrative Tools
The File Protection Password is the password that protects the PGP Secret Key file. The Private Key Password should be the same password that was entered when running the installer, or the password last set using the Private Key Wizard tool. Figure 10.29: Selecting the Import PGP Secret Key File Option
7.
Click Finish. The PGP key is imported and shown in the Set Up > Secure Domains & Local Certificates (and SPN Setup) page on the PGP Keys tab.
10.6 Using the PrivateKeyWizard Tool
581
10.6.5 Removing Certificates and PGP Keys To remove or renew a certificate (and its private key) or an external PGP keypair that were imported using the PrivateKeyWizard tool, simply import the new certificate or external PGP key pair using this tool and then delete the old certificate or external PGP key pair. To delete an old certificate, go to the Local Certificate section of the Secure Domains & Local Certificates (and SPN Setup) page and click Delete in the row of the certificate you want to delete. When you remove a certificate from the Local Certificate section, the associated private key is also removed. To delete an old external PGP key, go to the PGP Keys section of the Secure Domains & Local Certificates (and SPN Setup) page, click Delete in the row of PGP Key Id that is associated with the PGP key pair you want to delete.
10.7 Using the Email Firewall Diagnostics Utility The Email Firewall Diagnostics utility helps to diagnose problems that occur during Email Firewall runtime. The tool captures system information and displays a list with diagnostic messages in a Windows interface. Diagnostic tool results are accurate only for the components that are installed on the machine on which the tool is run.
For database diagnostic work the utility uses Windows Authentication. This means that the administrator who starts the testing must have permissions to browse the Email Firewall database, as well as check SQL server settings. The EMFDiagnostics utility runs the following diagnostic tests sequentially: •
582
•
SQL Server Related Tests - tests diagnosing the database or any SQL Server settings. Email Firewall Related Test - tests that test Email Firewall settings.
•
Windows Related Test - Performance Counter.
Chapter 10: Administrative Tools
All tests report a “Test failed status” if an error (e.g., a database connection error) prevents the test from performing its tasks.
You cannot run any of the tests individually.
In addition to the previous three test categories, which are available through the Diagnostic Utility’s user interface, there are additional tests that are performed only when the Diagnostic Utility is run in automated mode. Their purpose is to generate additional information which can be reviewed by Tumbleweed’s Global Support team when there is an unresolved problem.
10.7.1 SQL Server Related Tests These tests diagnose the database and any SQL Server settings. They are: •
•
•
•
Recovery Model Warns if SQL Server’s recovery model does not match a certain predefined value (currently “Simple”). Filegroups Tests the Email Firewall database file groups. For each file group provides space usage information. Warns if there is low free space (more than 80% usage). Issues an error if “automatic grow” is enabled, as well as if the free space is critically low (more than 90% usage). Jobs Provides information about the SQL Server Jobs: owner, last run time, next run time, as well as last run outcome. Warns if any job’s last run outcome is different than “Succeeded”. For example, a currently running job may influence other tests, thus a warning must be issued. Replications Checks the Email Firewall database replication settings, and if replication is set up, compares it to a pre-defined healthy model. Warns if the current replication settings do not match the healthy scenarios.
10.7 Using the Email Firewall Diagnostics Utility
583
•
• •
• •
•
Transaction Log Inspects the Email Firewall Database transaction log, providing information about space usage. Warns for low free space (more than 80% usage). Issues an error if the free space is critically low (more than 90% usage). Autoshrink Warns if the Email Firewall Database’s auto-shrink setting is enabled. Locks Provides a list of the locks applied on the Email Firewall database. Warns if there are table-level locks. Open Transactions Lists the transactions open on the Email Firewall database. Tables Compares the Email Firewall database tables (and their columns, indexes and keys) to a pre-defined healthy model. Warns if there are differences. Stored Procedures Compares the Email Firewall database stored procedures to a pre-defined healthy model. Warns if there are differences.
10.7.2 Email Firewall Related Tests This category includes all the tests that test Email Firewall settings. They are: •
•
584
Open Relay Status Checks for open-relay status. Warns if the default network connection is flagged as “internal,” as well as if the relay accepts mail for external recipients. System Test Inspects: • Whether the Resin service is running. • Whether the SQL Server service is running. • Whether the World Wide Web service is running. • Whether the TCP Hidden Flag is set to FALSE. • Whether the Windows version is the one required by Email Firewall.
Chapter 10: Administrative Tools
•
•
• Whether the SQL Server version is the one required by Email Firewall. • Whether the browser version is the one required by Email Firewall. • The free space on the drive where Email Firewall is installed. • The number of files and the free space in current user’s temp folder. -Node error is issued if the free space is less than 1GB or if the number of files is 65536 or higher. -Node warning is issued if that number is greater than 51200. • Whether the JRE version is the one required by Email Firewall. • Whether the SQL Server used by Email Firewall and the one used by Resin are the same server. Warns if any of the above is not true (for the temp folder test, if node warning or error is issued). Thread Settings Provides information about the thread intercept and thread slope settings for the: • Archive Service • Content Engine • Secure Redirect • SMTP Relay -outgoing thread -partition thread -return thread Issues an error if the registry settings for any of the threads cannot be retrieved. Routing Rules Tests an SMTP relay server. Checks the DNS response times for the server (using the DNS servers specified in the Email Firewall Database) and the SMTP response times for every available IP address returned for the relay server (the time needed to connect to the SMTP server and receive a valid SMTP response). Warns for invalid SMTP responses. • A separate instance of this test is run for every relay host specified in the routing rules in the Email Firewall Database. In addition, if the default routing rule has “Use DNS” specified, some common domains are also tested, such as yahoo.com, tumbleweed.com, hotmail.com, microsoft.com. Warns if any of the servers do not respond or cannot be resolved.
10.7 Using the Email Firewall Diagnostics Utility
585
10.7.3 Windows Related Tests Currently there is only one type of test here: •
Performance Counter Collects 20 samples (one per second) for a performance counter. The performance counters currently tested are: • SQLServer:Latches / Total Latch Wait Time (ms) • SQLServer:Latches / Latch Waits/sec • SQLServer:Latches / Average Latch Wait Time (ms) • PhysicalDisk / Avg. Disk Queue Length • TCP / Segments/sec • TCP / Segments Sent/sec • TCP / Segments Retransmitted/sec • TCP / Segments Received/sec
10.7.4 Additional Tests These additional tests are performed only when the Diagnostic Utility is run in automated mode using EMFSave. Their purpose is to generate additional information which can be reviewed by Tumbleweed’s Global Support team when there is an unresolved problem. These include: • • • • • • • • •
586
IME naming dump. SQL analysis (using sqldiag.exe). System information (using Windows System Information). Active network connections (using netstat.exe). Application and System logs. Resin logs. Version information for all files in the Email Firewall directory. Dump of Email Firewall errors and major warnings (using the MMSSpMMSSaveEventLog stored procedure). Tumbleweed registry keys (using regedit.exe).
Chapter 10: Administrative Tools
10.7.5 EMFDiagnostics Utility in Distributed Installations When the EMFDiagnostics tool is run in a distributed installation, the results are accurate only for the components that are installed on the machine on which the tool is run. For example, when the EMFDiagnostics tool is run in a distributed installation from the machine where only the EMF database and the Database Tools are installed, a Resin Service warning may be displayed stating that the service is not running. The actual issue is that Web Admin is installed on a different machine than the Database Tools, so the EMFDiagnostics tool is not able to detect whether or not that service is running. Therefore, in a distributed installation it is recommended that the EMFDiagnostics tool be run, and the results be reviewed, only for the components and services that are installed on the machine on which the tool is run.
10.7.6 Diagnostic Utility Usage The tool is expected to be used as follows: 1.
Run the tool.
2.
Review the results.
3.
Take appropriate action based on any errors and/or warnings.
4.
Re-run the tool to verify that the errors and/or warnings do not appear.
5.
If the errors or warnings are not resolved, send the output (by running it from EMFSave) to Tumbleweed Global Support for further analysis using the normal support process.
To run the EMFDiagnostics utility: 1.
Go to Start > All Programs > Tumbleweed Email Firewall > EMFDiagnostics.
2.
Enter the User Name and Password to access the database.
10.7 Using the Email Firewall Diagnostics Utility
587
3.
From the Execute menu, choose Execute All Tests or click the green Run icon on the toolbar. The results are displayed as shown in Figure 10.30.
Figure 10.30: EMFDiagnostics Utility Displaying Result
4.
Review the results listed and take appropriate action. Each error or warning message is followed by suggestions on how it can be fixed. Figure 10.31 shows a sample Diagnostic Utility message.
Figure 10.31: Error and Warning Messages and Suggested Solutions
588
Chapter 10: Administrative Tools
5.
Double-click the message to view further details regarding the error or warning and how to fix it.
6.
Run the tool again to check that the error and warning messages are no longer listed.
7.
If the error or warning messages are still persisting, save the output and send it to Tumbleweed Global Support. To save the output, click the Save icon on the toolbar or choose File > Save.
Diagnostic information can also be captured from the EMFSave utility described in 10.9 Using EMFSave on page 592. When you save diagnostic details using EMFSave, note that: • •
The messages do not appear in the interface, but are directly saved into the .zip file. Additional information is logged in the emfsave.zip file. This information does not appear in the interface when you run the EMFDiagnostics utility.
10.7 Using the Email Firewall Diagnostics Utility
589
10.8 Using the EMFDebugLogCapture Tool The EMFDebugLogCapture.exe tool allows low level debug trace messages generated by the Email Firewall services to be captured. The debug output from an Email Firewall service is captured while the service is running, and the output can be saved to a text file, if desired. The tool then creates a debug trace log that the Email Firewall administrator can use to capture debug information. This tool has a graphical user interface. Instructions for its use are displayed when the tool is started. The tool stores in memory up to 10MB of the most recent trace messages generated by the selected service. (This limit can be changed using the Buffer Size setting in the UI.) These trace messages can be saved to a file, which can then be sent to the Tumbleweed support department for diagnosing problems that may be occurring. To use the EMFDebugLogCapture.exe tool: 1.
With your browser, select the Start > All Programs > Tumbleweed Email > EMFDebugLogCapture series of commands to start the tool.
Firewall
A list of the Email Firewall services installed on the host machine is shown in a drop-down list. See Figure 10.32. 2.
Select the service for which you want to capture debug information.
3.
Adjust the Maximum log size to set the maximum amount (in MB) of logging to save in the log file.
4.
Specify the Log file name. When one-half of the Maximum log size (as specified in the previous step) is reached, the pre-existing log file will be renamed as a backup file (.bak) and the current logging information will become the current log file.
5.
Then, click OK.
6.
In the dialog asking if you want to restart the selected service, click Yes. The selected service must be restarted in order for it to detect that debug log tracing should be done. If you click No, EMFDebugLogCapture will terminate.
7.
EMFDebugLogCapture then displays this dialog: New trace messages will now be captured. It will restart the selected service and generate the debug trace, storing in memory up to 10MB (or the configured limit) of the most recent trace messages. Captured log information will be periodically (every 250K of logging captured) flushed to the specified file.
590
Chapter 10: Administrative Tools
8.
In the New trace messages will now be captured dialog, click Exit to display a dialog asking if the service should be restarted.
9.
Click Yes to restart the service. The service must be restarted to terminate debug logging. If you click No, you will have to restart the service manually to terminate debug logging.
Figure 10.32: EMFDebugLogCapture Tool
10.8 Using the EMFDebugLogCapture Tool
591
10.9 Using EMFSave The EMFSave tool is used to backup and restore an organization's Email Firewall configuration and data. It is also used to copy configuration information to a .zip file that can be sent to Tumbleweed Technical Support to reproduce the deployment configuration when investigating problems. Before running EMFSave you should have sufficient privileges to create a temporary database on the database server. You will need a valid Username and Password to access the database. There should also be sufficient space on the local disk to hold the temporary EMFSave database. To avoid using too much disk space, the error logs that need to be copied should be reduced to as narrow a duration as possible. A command line version of this tool is also available. See 10.4.2 EMFSave on page 561. For additional information on Email Firewall SQL Server database configuration and maintenance, see the Tumbleweed Email Firewall Best Practices Guide.
10.9.1 EMFSave and Administration Data Specific server Administrator configuration data and settings are not saved or restored by EMFSave. These items should always be backed up using SQL server backups rather than EMFSave. These items include: • • • • • • • • •
592
Admin Accounts Admin Permissions Admin Preferences Admin Message Queue Filter Properties Admin Message Queue Filters Admin Queue Aging Admin Queue Thresholds Admin Roles Event Log Filters
Chapter 10: Administrative Tools
10.9.2 EMFSave and Replication The emfsave.zip backup file created using EMFSave on a machine using replication is useful for support purposes, but it cannot be directly restored to a machine with a replication-enabled database. The file can be restored to a nonreplication machine, or, if you are running Email Firewall with replication, you must first remove replication, then restore the file, then re-enable replication. For additional information on restrictions with EMFSave when used in a replication setup, see the Tumbleweed Email Firewall Best Practices Guide, 4.2.1 Using EMFSave with Replication for more details.
10.9.3 Starting EMFSave To start EMFSave, use the Start, Program Files, Tumbleweed Email Firewall, EMFSave series of commands. EMFSave should be run only on the machine where the database server is located.
To begin the save: 1.
Select the database to be saved, using the correct Database Name, Username and Password. The Email Firewall database is named EMFMail by default, but the name is configurable during installation.
2.
Specify the location where the Email Firewall Save File is stored. By default, the path specified in the Email Firewall Save File field is the path specified when you installed Email Firewall. Use Browse to save to a different location. The file is saved as a .zip file.
3.
Optionally, click Password to open the Password dialog box and specify a password to protect the data on the emfsave.zip file.
4.
Specify the location of the Temp Directory where the temporary Email Firewall database files are stored before compression. When operating, EMFSave creates a temporary working database while it copies items from the main Mail database. By default, the location is the Temp folder used by the Email Firewall services to store temporary files. Click Browse to save the file to a different location. If you change the location, be sure there is adequate disk space to save all the database files you are backing up.
10.9 Using EMFSave
593
E m a i l F i r
In a cluster environment, the location for storing the Email Firewall database temporary files must be part of the cluster resource in order for restore to function properly. See 10.9.5 Using EMFSave in a Cluster Environment on page 601.
e w a l l
Figure 10.33 shows the initial EMFSave fields for Database Name, Userlocation, and Temp Directory location.
name, Password, EMF Save File
Figure 10.33: Specifying the Database Name and Save Locations
The Private Keys are saved in the EMFSave database protected by the same password as they were in the EMFMail database. When restoring the Private Keys, the same password should be set in the Email Firewall component machines that access this Private Key data. 5.
594
Figure 10.34 shows the types of data that can be copied or restored. Mark the checkboxes in the Copy and Restore Options group box to specify what type of data is saved. Note that if you select Security Data, you can optionally select to save Private Keys data.
Chapter 10: Administrative Tools
Figure 10.34: EMFSave Copy and Restore Options
6.
To ensure that all of the required data is saved, in some cases you must select more than one Copy and Restore data option. 6a. If you have set up any queues to send a notification and to log an
event, in order for EMFSave to copy the correct configuration data for copy and restore, you must mark both the Configuration Data and the Directory Data checkboxes. 6b. If you have set up global options for Annotations (In-line Annotation Settings) or Notifications (Global Notification Settings), in order for EMFSave to copy the correct configuration data for copy and restore, you must mark both the Configuration Data and the Directory Data checkboxes. 6c. If you have installed the Dynamic Anti-spam Service, in order for EMFSave to copy the correct configuration data for copy and restore, you must mark both the Configuration Data and the Directory Data checkboxes. 6d. In order to copy messages in the queues, you must mark the Messages checkbox in the Copy and Restore group box, see Figure 10.34, and then also mark the checkbox for the specific 10.9 Using EMFSave
595
queues (or all queues) in the Select Message Queue(s) to Copy dialog, see Figure 10.37. 6e. An MMSSave that was created before the release of Secure Messenger 6.0 should not be restored after the installation of Secure Messenger 6.0. 7.
To capture and save details from use of the Email Firewall Diagnostics tool, mark the EMF Diagnostics check box. To save System diagnostic data, mark the System diagnostic data checkbox.
8.
In the Additional Copy Options group box, see Figure 10.35, you can select the time range from specified periods of Email Firewall operation before starting the save operation. If your database is large, be very careful to select only a brief time range when copying the Event Log or Message Queues. Otherwise, it will take a very long time to generate the .zip file and the generated file will be so large it will not be practical to send it over the Internet to Tumbleweed support.
9.
If you marked the Event Log or Report Data checkbox: 9a. In the Additional Copy Options group box, Event Log and Reports
section, see Figure 10.35, click Select Time Range to open the
596
Chapter 10: Administrative Tools
Select Time Range dialog and specify the save data period. See Figure 10.36. Figure 10.35: Time Range and Copy Options
Figure 10.36: Save Data From This Time Range
10.9 Using EMFSave
597
9b. Mark the Last X hours or Between Times radio button. 9c. Specify the time range. 9d. Click OK. 10. If you want to copy messages in the queues, you must have marked the Messages
checkbox in the Copy and Restore Options group box:
10a. Click Select Time Range to specify the save data period. See
Figure 10.36. 10b.Click Select Queue(s) to Copy to open the Select Message
Queue(s) to Copy dialog. See Figure 10.37. 10c. Mark the radio button to save All Queues or Selected Queues.
If you marked Selected Queues, mark the checkbox(es) for the specific queue message data to save. 10d.Click OK.
Figure 10.37: Selecting the Message Queue Data to Save
11. In the EMFSave tool, click Copy Selected Items.
598
Chapter 10: Administrative Tools
12. Depending on the size of the data files being saved, this may take some
time. A confirmation dialog appears when the save is complete. See Figure 10.38. Figure 10.38: Confirming the EMFSave
13. Check the file location and verify the emfsave.zip file appears in the
directory folder. 14. Extract the emfsave.zip file and open the contents.txt file to verify
that the data you wanted to copy was successfully copied. If you wanted to copy messages in the queues and they were not copied, verify that you marked both the Messages checkbox in the Copy and Restore Options group box and also selected the queue(s) in the Select Message Queue(s) to Copy dialog.
10.9.4 Restoring EMFSave Files After configuration or other data has been saved, you can restore it from the emfsave.zip file. When restoring from an emfsave.zip, all Email Firewall services should be stopped before the restore takes place.
10.9 Using EMFSave
599
To restore from the emfsave.zip file: 1.
Start the EMFSave program using the Start, Program Files, Tumbleweed Email Firewall, EMFSave series of commands.
2.
In the EMFSave program UI, click Restore from Save File.
3.
In the Question dialog, see Figure 10.39, click Yes to overwrite the Email Firewall data currently in the database.
Figure 10.39: EMFSave Overwrites Data Currently in the Database
4.
If the restore was successful, the dialog in Figure 10.40 appears.
Figure 10.40: Successful Restore Confirmation
5.
600
If you receive an error message, take specific note of the error message and your actions preceding the message, and contact Tumbleweed Technical Support.
Chapter 10: Administrative Tools
Missing Data and Restore Errors When starting the EMFSave tool Restore operation, if you are attempting to restore components that are missing from the backup file, an EMFSave error details the items that are missing in the archive file. To complete the restore, you should change your EMFSave Restore options to reflect only the files in the EMFSave backup file. If you are using EMFSave from the command line, the -continue option can be used to continue the restore despite the error condition of the missing data.
10.9.5 Using EMFSave in a Cluster Environment For proper operation of EMFSave in a cluster environment, only the virtual server name and the instance name may be used. This is because when EMFSave is used to copy data to the new emfsave.zip file, Email Firewall needs to create a temporary EMFSave database so that data can be copied to this temporary database, detached, and then zipped up. In order to create a temporary EMFSave database in a clustered environment, the database files for the EMFSave database must reside on a disk that is part of the Cluster Resource. If EMFSave attempts to connect to the database using a local hostname, the connection will fail. For proper operation in a cluster environment, the Temp directory setting in EMFSave must point to a directory accessible to the virtual SQL Server. For example, if Email Firewall stores its database files on disk resource R:, then there should already be a dependency set for the virtual SQL Server on R:, and so it is sufficient for the Temp directory setting in EMFSave to point to a path on R:. For more information on using Email Firewall in a cluster environment, see the Tumbleweed Email Firewall Best Practices Guide.
10.9 Using EMFSave
601
10.10 Using the Email Firewall Update Service The Email Firewall Update Service is a web-based service that helps you to keep your software up-to-date. The Update Service allows you to: • • •
View updates for the software you are using. View a list of available updates and read about those updates. Easily install the updates that you choose.
To start the tool: 1.
On the machine where Email Firewall is installed, select Start > All > Tumbleweed Email Firewall > Check for Updates.
Programs
2.
602
Click Show Updates to check whether any updates are available. See Figure 10.41.
Chapter 10: Administrative Tools
Figure 10.41: The Email Firewall Update Service Tool
10.10 Using the Email Firewall Update Service
603
3.
If updates are available, this information is shown in the Available Updates pane. See Figure 10.42.
Figure 10.42: Updates Are Available
When there are updates available, you can either install them immediately, or download them for installation at a later date.
604
Chapter 10: Administrative Tools
4.
Click Get Update to access the update.
5.
Click Install Now to download and apply the update immediately. See Figure 10.43.
Figure 10.43: Selected Updates Ready to Install
If there are messages, the Learn More button is displayed. Click Learn More to view the informational messages. 10.10 Using the Email Firewall Update Service
605
6.
Select a download location. See Figure 10.44.
Figure 10.44: Select a Download Location
606
Chapter 10: Administrative Tools
7.
Allow the download to progress to completion. See Figure 10.45.
Figure 10.45: Update Downloading
10.10 Using the Email Firewall Update Service
607
8.
Review the Update Status and close the tool. See Figure 10.46. Or, if additional updates are available, repeat the steps to download additional updates.
Figure 10.46: Update is Complete
608
Chapter 10: Administrative Tools
10.11 Using the Configuration Editor The Configuration Editor provides a means of viewing, editing and deleting Email Firewall configuration values that are not otherwise exposed through the Email Firewall Web Admin. The Configuration Editor also allows you to create new configuration values. The Configuration Editor should only be used under strict instruction and guidance from a Tumbleweed Support representative or following explicit instructions in Email Firewall documentation.
Modifications to the Email Firewall configuration using the Configuration Editor can significantly impact the proper functioning of Email Firewall. The tool has two elements: Table Name: This selection list contains a list of all Email Firewall tables which contain configuration parameters. Select the appropriate table which contains the configuration value you would like to view, edit, delete or create. Key Name: This selection allows you to type the name of the configuration value
contained in the selected table. You can specify a configuration value in any or all of three formats. The formats are: • • •
Integer Value Unicode String Value Non-Unicode String Value (8 bit)
To use the tool to view, edit or delete an existing configuration value: 1.
In the Email Firewall main menu, click Setup.
2.
In the Setup page click Configuration Editor.
3.
Beside the Table Name heading, use the drop-down list to select the Email Firewall table for which you would like to find a configuration value.
4.
In the Key Name field, type the name of the configuration value.
5.
Perform one of the following procedures: • To view or edit an existing configuration value, click Find to see the current values for the specified Key Name.
10.11 Using the Configuration Editor
609
• To edit the configuration value, make any necessary modifications to the configuration values and click Update. Be sure to select the checkbox next to the value format you want to be saved for the configuration value. If you mark the checkbox for the Unicode or Non-Unicode value formats and do not specify a value in the text field, the configuration will store an empty string for the given value format, e.g. Unicode String Value = "".
Click Save to save the changes to the configuration value. • To delete a configuration value, click Delete. To use the tool to create a new configuration value: 1.
In the Email Firewall main menu, click Setup.
2.
In the Setup page click Configuration Editor.
3.
Beside the Table Name heading, use the drop-down list to select the Email Firewall table in which you would like to create a new configuration value.
4.
In the Key Name field, type the name of the new configuration value.
5.
Click Create.
6.
Mark the checkbox beside the value format you want to specify and type the value using the format selected. If you mark the checkbox for the Unicode or Non-Unicode value formats and do not specify a value in the text field, the configuration will store an empty string for the given value format, e.g. Unicode String Value = "".
7.
610
Click Save to save the new Key Name and configuration value.
Chapter 10: Administrative Tools
11
Email Firewall Reports
The Email Firewall reporting tool creates reports that show how Email Firewall is operating in your environment. These reports are based on events logged to the Email Firewall Event Log. Whenever a message is handled by the Email Firewall Policy Engine or Relay and the logging level is set to Normal, an event is logged. The Email Firewall reporting tool uses this Event Log data to produce the reports described in this chapter. Several of these reports are based on weekly or monthly statistics. When setting up or running reports, keep in mind that the reports do not use standard calendar weeks or months. Instead, they report on weeks or months that start on the day that your selected time range starts. Yearly ranges are based on the calendar year, but monthly and weekly ranges are not calendar based, but based on the week or month starting when the selected time range starts. For example, if you choose the time range of “This Year” when running the report, then the week starts on Wednesday because January 1, 2003 is a Wednesday. This chapter contains the following sections: 11.1 11.2 11.3 11.4 11.5 11.6 11.7
Setting Up Email Firewall Reports ........................................ 612 Volume Reports ....................................................................... 616 Frequency Reports.................................................................. 624 User Reports ........................................................................... 627 Audit Reports .......................................................................... 629 Customizing Email Firewall Reports...................................... 630 Printing and Saving Reports .................................................. 635
611
11.1 Setting Up Email Firewall Reports Select Reports from the left Menu to view the list of reports. The first time you click Show Report after logging in, a security warning may appear. Click Yes to view the reports. (This gives the permissions needed by the downloaded applet to render the reports.) If you do not want to see this warning every time you access reports after logging in, mark the Always trust... checkbox.
There are four types of reports: • • • •
Volume Frequent Activity Specific User (Sender or Recipient) Audit
Each report type contains a number of individual reports. Figure 11.1 shows a partial list of reports, which are grouped by retention period for user convenience. You can customize these default reports for your organization. You can also create your own custom reports. See Appendix D, Creating Custom Reports.
11.1.1 Global Reports Setup The data used to produce reports is based on the Event Log data in the Report tables and the Report Detail Events tables. The length of time this data is kept in the database and can be used in the reports statistics is configured in the Setup > Event Logging page, Event Aging tab.
Summary Events
The Event Log aging configuration for the Report Summary Events and Report Detail Events is independent of the aging configuration for the Policy Engine Events, Relay Events and Audit Events. The data for Reports events other than Audit reports does not depend on the other aging configurations, so you do not need to synchronize these data expiration actions when setting up Event Log aging.
612
Chapter 11: Email Firewall Reports
When setting up Event Log aging, keep this in mind: • •
• •
The Volume reports use data from the Report Summary Events tables. Among the non-Volume reports, the Frequent Sending IP Addresses and Frequent SPF and Caller ID Violators reports also depend on the Report Summary Events tables. All other reports except Audit reports use data from the Report Detail Events tables. Audit reports depend on the Audit Events tables.
The Report Summary Events data occupies much less space than the Report Detail Events data. When setting up the reports data aging, it is better to specify a longer aging time for the Report Summary Events than for the Report Detail Events. When set up this way, reports that depend on the Report Summary Events tables will contain data to report on a longer date range. For more information about setting up Event Log aging, see 4.1.3 Setting Up Event Aging on page 188. Automated event log export is available to save the Event Log events in a location other than the database. This allows you to free up database space while still retaining Event Log information. See 4.1.4 Event Log Export on page 189 for more information.
11.1 Setting Up Email Firewall Reports
613
Figure 11.1: Email Firewall Reports
614
Chapter 11: Email Firewall Reports
To set up global report settings: 1.
In the main menu, click Reports.
2.
In the Reports page, click Setup Reporting.
3.
In the Reports > Event Logging page, scroll to the Event Aging tab. This page can also be reached using Setup > Event Logging.
4.
Beside the Report Summary Events heading: 4a. The default setting is to Delete events older than 180 days. To
change this setting, enter a different number in the days field. 4b. Or, mark the radio button to Never delete events. Selecting this
option may cause the database to grow quite large; be sure you have sufficient room to store this data. 5.
Beside the Report Detail Events heading: 5a. The default setting is to Delete events older than 30 days. To
change this setting, enter a different number in the days field. 5b. Or, mark the radio button to Never delete events. Selecting this
option may cause the database to grow quite large; be sure you have sufficient room to store this data. 6.
Beside the Audit Events heading: 6a. The default setting is to Delete events older than 7 days. To change
this setting, enter a different number in the days field. 6b. Or, mark the radio button to Never delete events. Selecting this
option may cause the database to grow quite large; be sure you have sufficient room to store this data. 7.
Click Save.
11.1.2 Reporting Statistics and Queues Issues When reviewing the Volume and Frequency reports, keep in mind that messages released or reprocessed from the Quarantine and Detention queues are recorded twice. This occurs because messages released from these queues are sent back through the Policy Engine. This affects volume and frequency reporting statistics.
11.1 Setting Up Email Firewall Reports
615
If the action on a quarantined or detained message is to Release to the recipient, only the composition phase policies are applied. This allows message encryption and the unencrypted message policies to be applied, if applicable. If the action on a quarantined or detained message is to Reprocess or Release back to the Policy Engine, then all policies are applied again, including both composition and decomposition phase policies. In this case, the Policy Engine may change a message, for example, to add an annotation, or to strip a header or a virus.
11.2 Volume Reports Volume reports show the number and size of messages, attachments, and attachment types, without regard to the sender or recipient of the message. The data displayed in the reports is configured in the Reports > Customize page. See 11.6.1 Customizing Volume Reports on page 631 for more information on customizing volume reports. Volume report entries are generated by the SQL Server Database Agent. Therefore there may be up to a one hour delay in the Volume report information.
For reporting purposes, the size of message/package and attachments are rounded up to the next highest KB. For example, a 78-byte attachment will be displayed as 1KB; a 1.2 KB attachment will be displayed as a 2KB attachment; a 10-byte package will be displayed as 1KB. Messages released or reprocessed from the Quarantine and Detention queues are recorded twice, affecting volume and frequency reporting statistics. This behavior is necessary because the Policy Engine may change a message whenever it passes through the engine, for example, to add an annotation or to strip a header or a virus.
Volume reports use data from the Report Summary Events table. All reports that use data from the Report Summary Events table are not realtime reports. By default, the database table that is used to create this report is configured to update every hour. For example, messages sent between 1:01 pm and 1:59 pm will not appear on the report until 2:01 pm. The update interval can be configured through the SQL database. 616
Chapter 11: Email Firewall Reports
The Message Volume and Size and Spam Volume reports use different meanings when calculating statistics for Inbound and Outbound messages. These reports calculate volume based on the following: • • • •
the number of messages from External to Internal networks is A the number of messages from Internal to Internal networks is B the number of messages from Internal to External networks is C the number of messages from External to External networks is D
The report calculations based on the above are: For Message Volume and Size report: Inbound = A + D Outbound = B + C Total = A + B + C + D
For Spam Volume report will show ALL inbound messages, if the option Do not scan messages received from internal networks on the Set Up > Dynamic Antispam Service Settings is ENABLED. This means A + D and should match the numbers on the Message Volume and Size report. If this option is DISABLED, the Spam Volume report will show A + B + C + D.
11.2.1 Attachment Volume and Size This report displays two line charts and two tables that show the total number of email attachments and the total size of those attachments (in MB) sent to the Email Firewall server over the specified report time interval. The first table is a summary table. If you selected to include subtotals in this report, the second table shows the totals, in addition to the subtotals (listed by hour, day, week, or month depending on your selected interval). If you selected not to include subtotals in this report, the two tables will contain the same information.
11.2.2 Message Volume and Size This report displays three line charts and two tables that cover message volume and size for the specified report time interval. The first chart, Total Message Volume, shows the total number of Inbound and Outbound email messages sent through the Email Firewall server over the specified report time interval. The second report, Total Messages Size, shows the total size in MB of the total number of Inbound and Outbound email messages sent through the Email 11.2 Volume Reports
617
Firewall server over the specified report time interval. The third chart, Total Message per Host, shows the total number of email messages sent through each Email Firewall host over the specified report time interval. If Centralized Event Logging and Reporting is configured and enabled, this third chart shows the total message volume for the central Email Firewall, as well as for each of the linked satellite Email Firewalls. If Centralized Event Logging and Reporting is not configured and enabled, this chart will only show the total message volume for the single Email Firewall host. All three charts display on the first page along with a summary table that provides the same totals as provided in the Total Message Volume and the Total Message Size charts for the specified report time interval. If you selected to include subtotals in this report, the first table shows the subtotals (listed by hour, day, week, or month depending on your selected time interval) in addition to the totals. If you selected not to include subtotals in the report, then the two tables will contain the same information. This report distinguishes messages based on their network source. The Inbound statistics are the count of all messages received by Email Firewall from external networks during the report time interval. The Outbound statistics are the count of all messages received by Email Firewall from internal networks during the report time interval. Internal and External network definitions are based on the SMTP Relay’s Set Up > Network Connections settings. The Total is the sum of both Inbound and Outbound statistics shown in the report.
11.2.3 Message Volume by Policy Disposition Report This report displays one bar chart and two tables. The bar chart shows the total number of email messages per policy disposition over the specified report time interval. The first table, a summary table, provides the total number of email messages per policy disposition, in addition to the sum of all policy dispositions over the specified report time interval. If you selected to include subtotals in this report, the second table shows the subtotals (listed by hour, day, week, or month depending on your selected time interval), in addition to the total sum of all policy dispositions. If you selected not to include subtotals in the report, then the two tables will contain the same information. Policy dispositions shown in the report include: • •
618
Delivered Quarantined
Chapter 11: Email Firewall Reports
• •
Dropped Returned (included in tables only)
For purposes of this report, message counts for Delivered Normally include the number of all messages which are deferred, detained and delivered normally. Message counts for Delivered via Messenger include all messages redirected to a Secure Messenger server.
11.2.4 Attachment Volume for a Specific Attachment Type This report displays two line charts and two tables that show the total number of email attachments and the total size of those attachments (in MB) sent to the Email Firewall server over the specified report time interval. The first table is a summary of totals shown in the two line charts. If you selected to include subtotals in this report, the second table shows the subtotals (listed by hour, day, week, or month depending on your selected time interval) in addition to the totals. If you selected not to include subtotals in this report, the two tables will contain the same information. When customizing this report, in addition to the regular report data, you must specify the attachment types, by extension, (for example, .doc, .txt, .html, etc.) to include in the report. The size reported in the table may appear inflated for messages with multiple attachments.
11.2.5 Virus Type and Volume This report displays two line charts and two tables that show virus types and total volume of each virus type the Email Firewall Policy Engine caught over the specified report time interval. The first line chart, Number of Virus Types, shows the number of different virus types the Email Firewall Policy Engine caught. The second line chart, Number of Virus Detected, shows the total number of each type of virus caught. The first table is a summary of totals shown the two line charts. If you selected to include subtotals in this report, the second table shows the subtotals (listed by hour, day, week, or month depending on your selected time interval), in addition to the totals. If you selected not to include subtotals in this report, the two tables will contain the same information.
11.2 Volume Reports
619
11.2.6 SPF Volume Report This report displays one chart and a table that show all messages received over connections where SPF testing was enabled, broken down by testing status, over a configurable period of time. The SPF test volume report statistics are based on the SPF protocol specification, which can be viewed at http://spf.pobox.com/spfdraft-200406.txt. As required by the specification, an SPF client (the Email Firewall Inbound SMTP Relay is the SPF client) evaluates an SPF record and produces one of seven results: •
Passed
The message meets the publishing domain’s definition of legitimacy. MTAs proceed to apply local policy and may accept or reject the message accordingly. This test result is included in the report. •
Failed
The message does not meet a domain's definition of legitimacy. MTAs may reject the message using a permanent failure reply code. (Code 550 is recommended. See RFC2821 section 7.1.) Email Firewall does reject the message with code 550. This test result is included in the report. •
Soft Failed
The message does not meet a domain's strict definition of legitimacy, but the domain cannot confidently state that the message is a forgery. MTAs should accept the message but may subject it to a higher transaction cost, deeper scrutiny, or an unfavorable score. In Email Firewall, messages receiving a soft fail SPF test result are accepted. Returning code 450 to the SMTP client would imply that the message was rejected with a transient error. This test result is included in the report. •
Neutral
The SPF client must proceed as if a domain did not publish SPF data. This result occurs if the domain explicitly specifies a “?” value, or if processing “falls off the end” of the SPF record. This test result is included in the report. •
Untestable
The SPF protocol specification describes two error conditions. “Error” indicates an error during lookup; an MTA should reject the message using
620
Chapter 11: Email Firewall Reports
a transient failure code, such as 450. “Unknown” indicates incomplete processing; an MTA must proceed as if a domain did not publish SPF data.
•
These two error conditions are included together in the report’s Untestable statistics. By default, Email Firewall will accept mail that invokes an error during SPF testing. However, there is a Relay configuration option available to change this, so that messages experiencing an error will be rejected with code 450. This option is not exposed in Web Admin but can be modified using the Configuration Editor. None The domain does not publish SPF data. This test result is not included in the report.
In addition to the SPF protocol specification tests, the SPF Volume Report includes the total number of messages processed for clients that publish SPF data.
11.2.7 Caller ID Volume Report This report displays one chart and a table that show all messages received over connections where Caller ID testing was enabled, broken down by testing status, over a configurable period of time. Testing status includes Passed and Failed. The test results statistics also include the total number of messages received over connections where Caller ID testing was enabled, and the number of messages received over these connections that were untestable.
11.2.8 Spam Volume Report The spam volume report is useful when the Dynamic Anti-spam Service (DAS) is installed. The purpose of this report is to show the effectiveness of the DAS Spam Analysis Engine (SAE) by reporting the total volume of email messages that DAS scanned. This report displays two pie charts, one percentage-area chart, one line chart, and two tables to relay spam volume for the specified report time interval. The pie chart on the left of the first page is the Message Volume Summary chart. For each of the following categories of email that DAS scanned and tagged,
11.2 Volume Reports
621
This chart provides the percentage of the total of all email DAS scanned for each of the following email categories: • • •
High spam (high confidence spam) Moderate spam (moderate confidence spam) Legitimate
Each category is represented by a slice of the pie in a unique color. The pie chart on the right of the first page is the Spam Category Summary chart. This chart breaks down the messages tagged as High and Moderate spam into the following subcategories: • • • •
Adult Broadcast Scam Not classified (unclassified)
The percentage-area chart, Percentage of Spam Received, provides the total percentages of the High spam and Moderate spam out of the total email messages that the DAS scanned for the specified report time interval. The line chart, Number of messages released, displays the total number of email messages that were tagged as spam and were released from a quarantine queue to the recipient for the specified report time interval. The two tables provide the following information for the specified report time interval: Notes: Spam messages are broken down into the subcategories of Adult, Broadcast, Scam, and Unclassified. • • • • •
• •
622
Total number and total size (in MB) of All messages Scanned by DAS. Total number and total size (in MB) of messages tagged as Spam. Out of the all the Spam messages, the number of messages tagged as High spam and those tagged as Moderate spam. Total number and total size (in MB) of messages tagged as Adult content Out of the Adult content category, the number of messages tagged as Adult Content/High confidence and those tagged as Adult Content/Moderate confidence. Total number and total size (in MB) of Broadcast Content. Out of the Broadcast content category, the number of messages tagged as Broadcast content/High confidence and those as tagged Broadcast content/Moderate confidence.
Chapter 11: Email Firewall Reports
• •
•
Total number and total size (in MB) of messages tagged as Unclassified Spam. Out of the Unclassified spam category, the number of messages tagged as Unclassified spam/High confidence and those tagged as Unclassified spam/Moderate confidence. Total number and total size (in MB) of Released Spam. The Released Spam category are the messages that have been released from a quarantine queue.
If you selected to include subtotals (by hour, day, week or month) in this report, then the first table shows the above listed information by hour, day, week, or month depending on your subtotal selection. The second table provides the cummulative totals for each category listed above, in addition to the percentage of the total number associated with the given count. If you selected not to include subtotals in this report, the two tables will contain the same information minus the percentage numbers.
Interpreting the Spam Volume Report This report shows the total number of messages, spam messages (High and Moderate combined) and adult content messages. Because of the overlap between the spam and adult content messages, the number of spam and adult messages can be greater than the total number of messages. The “Released Spam” data provides an approximation of the number of false positives, assuming that the false positive messages are released from the Quarantine queue by an administrator or the intended recipient (using PQM). False positive messages are reported in the time interval in which the message is released by the administrator, unlike the other categories (total, spam and adult) which are reported in the time interval in which the message was first seen by the policy engine. False positive messages may be counted on each message partition, so a message that was sent to 100 recipients will be counted as 1 in the total, spam and adult categories, but may be counted as more than 1 in the false positive category. For the false positive messages, the size of the message is not shown.
11.2 Volume Reports
623
11.3 Frequency Reports Frequency reports show which policies are violated most often, which domains send and receive the highest number of messages, and which user sends the greatest number of virus-infected messages. See 11.6.2 Customizing Frequency Reports on page 632 for more information on customizing frequency reports.
11.3.1 Frequently Detected Virus This report displays one chart and a table that show the types of viruses that have been detected, and the number of times each type was detected, over a configurable period of time.
11.3.2 Frequent Policy Violation This report displays one chart and a table that show which Email Firewall policies were violated, and the total number of violations of each selected policy, over a configurable period of time. The report is sorted in ascending or descending order, starting with the policy that experienced the greatest or least number of violations.
11.3.3 Frequent Receiving Domains This report displays one chart and a table that show the recipient domains that received the most email messages over a configurable period of time. A recipient domain is defined in the SMTP Relay configuration. The report lists the number of messages received and the size (in KB) of all messages received by each domain.
11.3.4 Frequent Recipient Policy Violation This report displays one chart and a table that show the most frequent recipients of email messages that trigger Email Firewall policy violations, over a configurable period of time. The report lists the number of messages received in violation of each policy. 624
Chapter 11: Email Firewall Reports
11.3.5 Frequent Sender Policy Violation This report displays one chart and a table that show the most frequent senders of email messages that trigger Email Firewall policy violations, over a configurable period of time. The report lists the number of messages sent in violation of each policy.
11.3.6 Frequent Sending Domains This report displays two charts and a table that show the domains that sent the most email messages over a configurable period of time. A sending domain is defined in the SMTP Relay configuration. The report lists the number of messages sent and the size (in KB) of all messages sent by each domain.
11.3.7 Frequent Sending IP Addresses This report displays two charts and a table that show the external IP addresses and domains that sent the most and the largest email messages, broken down by total, spam, viruses, size (in KB) and number of connections used, over a configurable period of time. Whether an IP address or domain is external is defined in the SMTP Relay configuration. This report uses data from the Report Summary Events table. All reports that use data from the Report Summary Events table are not realtime reports. By default, the database table that is used to create this report is configured to update every hour. For example, messages sent between 1:01 pm and 1:59 pm will not appear on the report until 2:01 pm. The update interval can be configured through the SQL database.
11.3.8 Frequent Virus Sender This report displays one chart and a table that show the most frequent senders of viruses that have been detected by the Email Firewall Policy Engine, and the number of times each sender sent a virus, over a configurable period of time.
11.3 Frequency Reports
625
11.3.9 Frequent SPF and Caller ID Violators The report displays a table that shows the IP address of senders of messages that violated the SPF or Caller ID protocols, and the number of messages sent by those senders, over a configurable period of time. The report data can be selected for a configurable number of IP addresses that either sent the highest number of these messages (Top senders), or IP addresses that sent the fewest number of these messages (Bottom senders). IP addresses can be displayed in ascending or descending order. For each IP addresses, the number of SPF messages that were passed, neutral, soft failed, failed and percentage failed is shown. Also for each IP address, the number of Caller ID messages that were passed, failed and percentage failed is shown. The total number of both SPF and Caller ID messages that failed the tests is also shown. This report uses data from the Report Summary Events table. All reports that use data from the Report Summary Events table are not realtime reports. By default, the database table that is used to create this report is configured to update every hour. For example, messages sent between 1:01 pm and 1:59 pm will not appear on the report until 2:01 pm. The update interval can be configured through the SQL database.
11.3.10 Frequent Senders Released from Quarantine This is the Personal Quarantine Manager statistics report. The report displays one chart and a table that show the senders of messages that were released from Quarantine and/or requested for white listing by the intended recipient, and the number of messages sent by those senders, over a configurable period of time. The report data can be selected for a configurable number of senders who either sent the highest number of these messages (Top senders), or senders who sent the fewest number of these messages (Bottom senders). Senders can be displayed in ascending or descending order. The data shown in the report for the specified time interval corresponds to all messages released or requested for white listing during the report time interval. The data does not display all messages sent during the report time interval that were subsequently released or requested for white listing. Information about each sender, plus the subject, date and recipient of each message from that sender, is listed in the table, as well as whether a particular message was released or white listed.
626
Chapter 11: Email Firewall Reports
11.4 User Reports User reports show attachment and message volume for specific email users identified by email address, policy violations for individual senders and recipients, and viruses caught in messages from individual users. When configuring these reports, administrators must provide sender and recipient email addresses in addition to the normal report information in order to view these reports. See 11.6.3 Customizing User Reports on page 633 for more information on customizing user reports. Messages released from the Quarantine and Detention queues are recorded twice, affecting volume and frequency reporting statistics. This behavior is useful because the Policy Engine may change a message whenever it passes through the engine, for example, to add an annotation or to strip a header or a virus.
For Specific Sender reports you can generate reports for a domain. To report against all senders in a domain, just enter the sending domain name instead of the sender email address in the field. For example, to generate a report on all senders from a specific domain (which would be the equivalent of *@tumbleweed.com), enter the domain name in the format tumbleweed.com.
11.4.1 Attachment Volume for Specific Recipient This report displays two charts and a table that show the number of email attachments and the total size of those attachments received by an individual user (identified by email address) over a configurable period of time.
11.4.2 Message Volume for Specific Recipient This report displays two charts and a table that show the number of email messages and the total size of those messages (in KB) received by an individual user (identified by email address) over a configurable period of time.
11.4 User Reports
627
11.4.3 Policy Violation for Specific Recipient This report lists the number and type of policy violations detected by the Email Firewall Policy Engine for an individual email recipient (identified by email address) over a configurable period of time. The report lists the names of the policies that have been violated and the number of times each was violated.
11.4.4 Attachment Volume for Specific Sender This report displays two charts and a table that show the number of email attachments and the total size of those attachments sent by an individual user (identified by email address) or domain (identified by domain name) over a configurable period of time.
11.4.5 Message Volume for Specific Sender This report displays two charts and a table that show the number of email messages and the total size of those messages (in KB) sent by an individual user (identified by email address) or an individual domain (identified by domain name) over a configurable period of time.
11.4.6 Policy Violation for Specific Sender This report lists the number and type of policy violations detected by the Email Firewall Policy Engine for an individual email sender (identified by email address) or an individual domain (identified by domain name) over a configurable period of time. The report lists the names of the policies that have been violated and the number of times each was violated.
11.4.7 Virus Detected for Specific Sender This report lists the name of viruses detected by the Email Firewall Policy Engine in email messages sent by an individual email user (identified by email address) or an individual domain (identified by domain name) and the number of times it was detected, over a configurable period of time.
628
Chapter 11: Email Firewall Reports
11.5 Audit Reports Audit reports show the actions that have occurred to the Email Firewall Directory, and identifies the administrator who performed those actions. Only a Primary Administrator has authority to view and control audit reports. See 11.6.4 Customizing Audit Reports on page 634 for more information on customizing audit reports.
11.5.1 Directory and Policy Audit This report lists the directory and policy audits made by all administrators. The information is displayed based on when the action occurred, with the latest administrative audit action listed first.
11.5.2 Directory Audit This report lists the actions performed on the directory itself, including creating, modifying and deleting folders, domains and users. The information is grouped by directory name, and shows (by log in name) the administrator who took the action and the action taken (for example, add, update or delete), sorted by time.
11.5.3 Policy Audit This report lists the policies that were created, modified and deleted for any folder, domain or user. The information is grouped by policy name, and shows (by log in name) the administrator who took the action and the action taken (for example, attach policy to, remove policy from, enable or disable policy), sorted by time.
11.5.4 Directory and Policy Audit for a Single User This report lists the directory and policy audits made by individual administrators (identified by log in name), sorted by time. The reviewing administrator must identify the individual administrator by login name to view this report. 11.5 Audit Reports
629
11.5.5 Directory Audit for a Single User This report shows the number and type of directory audits made by individual administrators, identified by login name. The information is displayed based on time, with the most recent action listed first.The reviewing administrator must identify the individual administrator by login name to view this report.
11.5.6 Policy Audit for a Single User This report shows the policy modifications (add, edit, delete) made by an individual administrator, identified by login name. The information is displayed based on time, with the most recent action listed first. The reviewing administrator must identify the individual administrator by login name to view this report.
11.6 Customizing Email Firewall Reports Email Firewall reports can be customized to show information most useful to you. From the left menu, use the Reports command to open the Reports page. Click Show to open the Report > Customize page. The volume, frequency, user and audit reports types can be customized in different ways, as explained in the following sections. You can also save reports and print them for later reference. See 11.7 Printing and Saving Reports on page 635. Tumbleweed does not test your customized Email Firewall and therefore does not support these reports.
630
Chapter 11: Email Firewall Reports
11.6.1 Customizing Volume Reports The following features of volume reports can be customized, as shown in Figure 11.2: Figure 11.2: Customizing Volume Reports
• • •
Date Range Subtotals Title and Text
Each volume report presents the data in two charts and one table format. Because the data will be displayed in a chart format, when selecting the date range and subtotals, a reasonable subtotal period in relation to the total period selected will yield the most useful charts.
11.6 Customizing Email Firewall Reports
631
11.6.2 Customizing Frequency Reports The following features of frequency reports can be customized, as shown in Figure 11.3: Figure 11.3: Customizing Frequency Reports
• • •
Date Range Record Selection, Sorting Title and Text
Each frequency report presents the data in one chart and one table format. To make most effective use of the charting function, it is recommended that no more than 15 records be selected. Also note that the records can be selected to display in ascending or descending order.
632
Chapter 11: Email Firewall Reports
11.6.3 Customizing User Reports The following features of user reports can be customized, as shown in Figure 11.4: Figure 11.4: Customizing User Reports
• • •
Specific user Date Range Title and Text
Each user report presents the data in either one or two charts and one table format, depending on the underlying report type (volume, frequency, or policy violation).
11.6 Customizing Email Firewall Reports
633
11.6.4 Customizing Audit Reports The following features of audit reports can be customized, as shown in Figure 11.5: Figure 11.5: Customizing Audit Reports
• •
Date Range Title and Text
Each audit report presents the data in a table format.
634
Chapter 11: Email Firewall Reports
11.7 Printing and Saving Reports You can print and save your reports using the buttons on the Reports page. Figure 11.6: Printing and Saving Reports Buttons
11.7.1 Printing Reports To print reports: 8.
When viewing a report, click the Printer icon to open the Print Options pop-up page.
9.
Make your selection among the radio buttons and options shown in Figure 11.7.
Figure 11.7: Email Firewall Print Reports Print Options
11.7 Printing and Saving Reports
635
10. Click OK to open your browser Print pop-up page where you can select the
printer.
11.7.2 Saving Reports To save the data in your Email Firewall reports, you can export the report data to a file in 13 different formats: • • • • • • • • • • • • •
636
.pdf .ps .ps (level 2) .ps (level 3) .rtf .htm .htm (single page) .htm (concatenated pages) .csv (comma separated) .csv (semicolon separated) .csv (data only) .xls .xml
Chapter 11: Email Firewall Reports
To export reports: 1.
Click the Save icon to open the Export pop-up page. See Figure 11.8.
Figure 11.8: Saving a Report
2.
Use the drop-down arrow to select the format and click OK.
3.
Click Search to select a location to save the file.
4.
Click OK.
11.7 Printing and Saving Reports
637
5.
When the export is complete, the Information pop-up dialog displays. See Figure 11.9.
Figure 11.9: Export and Save of Report File Complete
6.
638
Click OK to complete the export process.
Chapter 11: Email Firewall Reports
A
File Types Scanned
This appendix describes the file-type scanning performed by Email Firewall and lists the types of files recognized. File scanning consists of four types of actions: • • • •
Decompression of compressed files Decomposition of embedded files Scanning for recognized file types Scanning for words, phrases, strings or tags
This appendix contains the following sections: A.1 A.2 A.3 A.4 A.5
General Overview .................................................................... 640 “All Supported” File Types ..................................................... 645 Groups...................................................................................... 651 File Types Recognized ............................................................. 655 File Types Scanned .................................................................. 659
639
A.1 General Overview Email Firewall can recognize and act upon a wide variety of file types. It can also scan a subset of these file types for specific words, phrases, or strings, analyze their content, and act upon them. To invoke file type recognition, Email Firewall policies can be written to scan for particular file types, for file types embedded in other files, and for attachments by file type. To invoke content analysis, policies can be written to scan for words, phrases, or strings in most of the popular word processing, graphics, spreadsheet, database, multimedia, compressed and presentation formats. Policies can also specify that HTML tag names and tag attributes be included in addition to tag values when scanning message body content and attachments. On a global basis, Email Firewall can physically scan attachment files and then, prior to scanning for text, replace all sequences of non-printable characters with a single whitespace character in the text that is extracted for content analysis. See Scanning Bytes of Non-Text Attachments on page 93 for more information.
A.1.1 File Types and File Type Lists Provided When you install the Email Firewall default policies, a selection of popular file types is provided in default attachment lists. See Figure A.1. You can use these lists, or create your own lists for policies that scan for attachment types. To create your own attachment type list and to view the specification styles and file types you can select, see the instructions in 6.2.8 Attachment Lists on page 268. As seen in Figure A.1, Email Firewall provides default attachment lists to scan for the following potentially harmful file types: • • • • • •
640
Appendix A
All executable file types. See A.2.5 All Supported Executable Files on page 647. All file types that cause decomposition errors. All compressed file types that cause decompression errors. Files with long filenames. Multimedia attachment file types or file names (See Figure A.2). Standard Mime type with attachment name or type message/partial.
Figure A.1: Email Firewall Attachment Lists
Figure A.2 shows the file types used in the default Multimedia Attachments attachment list. This list is used in the default Multimedia Attachments Deferral policy, but you can also use this list to create new policies to scan for multimedia file types, and then block them, quarantine them, or specify any of the other Email Firewall policy actions when these file types are detected.
641
Figure A.2: Multimedia Files Attachment List
A.1.2 Scanning Limitations Email Firewall cannot scan for words, phrases, or strings in all the file types it can recognize. It also cannot scan for words, phrases, or strings in the graphic and multimedia formats, nor can it scan embedded fonts in portable document format (.pdf) files. However, it can detect these types of files, and you can
642
Appendix A
define policies to detect and block these file types. See Adobe Portable Document Format (PDF) on page 660 for more information. Email Firewall can scan metadata such as author, title and date in MP3 and TIFF files. It can also scan non-embedded font content in PDF files.
Similarly, Email Firewall cannot check for specific words, phrases, or strings in password-protected files. However, you can define policies to detect and block password-protected file types.
A.1.3 Compressed Files and Embedded Objects Email Firewall is able to decompress most compressed file formats. It can also decompose most popular file formats for text-scanning by the Policy Engine. See A.5 File Types Scanned on page 659.
Embedded Objects in Microsoft Office Files Microsoft Office files (e.g. Word or Excel documents) can contain other files or documents (known as “objects”) embedded within them. Depending on the format in which these Office documents are saved, Email Firewall may be able to extract and process the embedded objects. The extraction of embedded objects is only possible when the Office documents are saved using Microsoft's compound document format. This is the native format for each Office product, for example, .doc for Word, .xls for Excel and .ppt for PowerPoint. Objects embedded within non-native formats such as RTF currently cannot be processed by Email Firewall. In addition, Email Firewall can handle only certain types of embedded objects, as follows: •
• •
If the embedded object is itself an Office document, stored in compound document format, then Email Firewall will extract and process it as if it was an individual attachment. If the object is an executable (e.g., an .exe file), then Email Firewall can identify it as such so that a policy may detect that condition. Other types of embedded objects currently cannot be extracted and processed by Email Firewall.
643
Limitations in File Type Decompression and Decomposition Email Firewall policies that detect executable files do not detect self-extracting zip files. Although self-extracting zip files have an .exe extension, Email Firewall classifies them as compressed rather than as executable. To enforce policies for all executable files, including self-extracting .zip archives, create a policy to check for files named *.exe in addition to all attachments whose file type is “executable file.” Email Firewall allows three minutes for decomposition of an embedded message or document. If decomposition takes longer than three minutes, Email Firewall logs a decomposition failure event instead of performing the action specified in the policy. You can catch messages that create this type of decomposition problem using the Basic Mail Filtering policy Decomposition errors. If you do not want messages that cause decomposition failures to be delivered normally, modify the default policy to specify a different policy action, or create a new policy, and then apply the policy to the appropriate directory object. RAR Compressed Archive (.rar) files version 3.3 or higher are detected. However, support has not been added for decompressing these very large files. Email Firewall also cannot distinguish between password protected and unprotected .rar files. Therefore, a policy to detect password protected files will not be triggered by a password protected .rar file.
644
Appendix A
A.2 “All Supported” File Types Email Firewall provides a list of attachment file types that can be used in policies that scan for particular file types. The file types preceded by the word “All” in the Email Firewall Attachments File Types drop-down list contain the files listed in the sections below. Other file type groups that appear on this dropdown list are described in A.3 Groups on page 651.
A.2.1 All Supported Compressed Files • • • • • • • • • • • •
ARC File CAB File LZH Compress LZH Self-Extracting Compress PKZIP format RAR format Self-UnZIPing.exe StuffIt for Macintosh Unix compress Unix TAR Unix GZip ZIP
A.2.2 All Supported Database Files • • • • • • •
DBase III, IV, V Microsoft Access 1.0, 2.0 Microsoft Project Microsoft Project 2000 Microsoft Access Paradox (*) Reflex
645
A.2.3 All Supported Document Files • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 646
Appendix A
Adobe Acrobat (PDF, PS) (*) Adobe FrameMaker (*) Ami Pro FrameMaker MIF (text only) IBM DCA/FFT IBM DCA/RFT Ichitaro 8 Interleaf 6 Lotus WordPro 97 (Win32 only) Lotus WordPro for SmartSuite for the Millennium (Win32 only) Lotus WordPro 96 (Non-Windows platforms - text only) MacWrite II Microsoft Word (*) Microsoft Works DOS 1.0 WP Microsoft Works DOS 2.0 WP Microsoft Works Win 3.0 WP Microsoft Works Win 4.0 WP MultiMate 3.6 MultiMate 4.0 MultiMate Advantage 2 MultiMate Note Navy DIF PerfectWorks for Windows PostScript (*) Professional Write 2 Q&A Write 3 Rainbow Rich Text Format Samna Wang PC (IWP) WordPerfect (*) WordPro 96/97 Wordstar 2000
• •
Wordstar 3.0, 4.0, 5.0, 6.0, 7.0 XyWrite / Nota Bene
A.2.4 All Supported Drawing Files • • • • • • • • • • • • • • • •
Adobe Illustrator AutoCAD (*) Computer Graphics Metafile Corel Draw (*) Enhanced Windows Metafile Harvard Graphics DOS 2.0 Chart Harvard Graphics DOS 3.0 Chart Harvard Graphics DOS 3.0 Presentations IGES Drawing File Format Micrografx Designer Microsoft Visio OS/2 Metafile Windows Metafile Windows Metafile [5000] Windows Metafile [5005] Windows Metafile [5006]
A.2.5 All Supported Executable Files Some old .exe files that use an old DOS format will not be detected. Nor will self-extracting .zip files with a .exe extension. However, you can create policies that check for these extensions. See Special Considerations for File Names and File Types on page 271 for a more detailed discussion of this topic.
• • •
.com .exe .dll
647
•
.scr
A.2.6 All Supported Image Files • • • • • • • • • • • • • • • • • • • • • • • • • •
Adobe Photoshop Ami Draw CCITT Group 3 Fax CCITT Group 4 Fax Compuserve (GIF) EPS (TIFF Header only) EXIF GEM Image JFIF (JPEG not in TIFF format) JPEG File Interchange JPEG Kodak Multi-Resolution Image Format Lotus PIC Macintosh PICT Macintosh PICT2 Macintosh PICT2 Binary MacPaint Multipage PCX Portable Network Graphics Sun Raster Tagged Image File Format (TIFF) (*) Targa Windows Bitmap (BMP) (*) Windows Cursor Windows Icon WordPerfect Graphic
A.2.7 All Supported Multimedia Files • 648
Appendix A
Help files (the A.3.5 Help Files on page 651 group)
• • • • • • • • • •
Macromedia Director MIDI File MPEG 6 MPEG Audio MP2 MPEG Audio MP3 Quicktime Movie RealAudio RealMedia Windows Audio (WAV) Windows Video (AVI)
A.2.8 All Supported Password-Protected Archive Files This group enables detection of special-casing protected files that are also archive files.
A.2.9 All Supported Password-Protected Files •
•
Password protected A Word document requiring a password to open the file encrypts the file, and Email Firewall considers that a password protected file which, though it cannot be scanned, can be detected and blocked. A Word document requiring a password only to modify the file is also recognized as a password protected file, even though the file is not encrypted. WordPerfect Encrypted
A.2.10 All Supported Presentation Files • • • •
Freelance 1.0, 2.0 for windows Freelance 1.0, 2.0 for OS/2 Freelance 96, 97 Microsoft Powerpoint (*)
649
A.2.11 All Supported Spreadsheet Files • • • • • • •
650
Appendix A
Enable Spreadsheet Lotus 123 (*) Microsoft Excel (*) Multiplan 4 Quattro/Quattro Pro (*) SuperCalc 5 Symphony
A.3 Groups Email Firewall provides a list of attachment file types. The file types listed in the Email Firewall Attachments File Types drop-down list contain both the “All” groups listed in A.2 “All Supported” File Types on page 645, and the following groups that are limited to a specific file type. The groups include the file type and version listed in this section.
A.3.1 Adobe Acrobat (PDF) •
Adobe Acrobat versions 1.1 to 1.4
A.3.2 Adobe Illustrator •
Adobe Illustrator 3.0
A.3.3 AutoCAD • • • •
AutoCAD DXF (Binary) AutoCAD DXF (ASCII) AutoDesk Drawing (DWG) AutoDesk WHIP
A.3.4 Corel Draw • • •
Corel CMX Corel Draw Corel Presentations
A.3.5 Help Files Windows Help (HLP)
651
A.3.6 Lotus 123 • • • • • •
Lotus Notes Bitmap Lotus Notes CDF Lotus 1-2-3 Lotus 1-2-3 Formatting Lotus 1-2-3 97 Lotus 1-2-3 Release 9
A.3.7 Microsoft Excel • • • •
Microsoft Excel Microsoft Excel 95 (5.0/7.0) Microsoft Excel 97/98 Microsoft Excel 2000
A.3.8 Microsoft PowerPoint • • • • •
PowerPoint PC PowerPoint MAC PowerPoint 95 PowerPoint 97 PowerPoint 2000
A.3.9 Microsoft PowerPoint with Macros Detects executables (e.g., .exe and .dll files) and macros embedded within supported Microsoft PowerPoint documents. See the previous section for supported versions.
A.3.10 Microsoft Word •
652
Appendix A
Mac Word 6
• • • • • • • • • • • •
Word for DOS 6.x Microsoft Word for PC Microsoft Word for PC Style Microsoft Word for PC Glossary Microsoft Word for PC Driver Microsoft Word for PC Miscellaneous File Microsoft Word UNIX WriteNow MAC Microsoft Word 95 Microsoft Word 97/98 Microsoft Pocket Word Microsoft Word 2000
A.3.11 Paradox •
Paradox
A.3.12 Quattro/Quattro Pro • •
Quattro Pro for DOS Quattro Pro for Window
A.3.13 Windows Bitmap (BMP) •
Windows Bitmap
A.3.14 WordPerfect • • • • •
Mac WordPerfect 1.x WordPerfect WordPerfect VAX WordPerfect Macro WordPerfect Spelling Dictionary, Thesaurus, Driver 653
• • •
654
Appendix A
WordPerfect Resource File WordPerfect Configuration File, Hyphenation Dictionary WordPerfect Miscellaneous File
A.4 File Types Recognized Table A.1: File Types Recognized A - D File Type
File Type
Ability (SS, DB, GR, WP, COM)
Audio Interchange File Format (AIFF) Sound
ACT Format
AutoCAD Drawing (DWG)
Adobe FrameMaker
AutoCAD DXF Graphics
Adobe FrameMaker Markup Language
AutoDesk Animator FLIC Animation
Adobe Maker Interchange Format (MIF)
AutoDesk Animator Pro FLIC Animation
Adobe Portable Document Format (PDF)
AutoDesk WHIP
AES Multiplus Comm Format word processor
AutoShade Rendering File Format
Aldus Freehand Mac
BinHex 4.0 encoded file
Aldus PageMaker (DOS)
CCITT Group 3 1-Dimensional
Aldus PageMaker (Mac)
COMET TOP Word
Alis word processor
Compactor / Compact Pro Archive
Amiga IFF (8SVX) Sound
Computer Graphics Metafile (CGM)
Amiga MOD Sound
Convergent Tech DEF Comm. format word processor
Apple Double
Corel CMX
Apple Single
Corel Draw (CDR)
Applix Asterix word processor
Corel Presentation
Applix Graphics
cpio Archive Format (UNIX/VAX/SUN)
Applix Spreadsheet
CPT Communication Format word processor
Applix Word
Creative Voice (VOC) Sound
ASCII File word processor/MS DOS Batch File format
Curses Screen Image (UNIX/VAX/SUN)
ASCII Spreadsheet (CSV)
Data Point VISTAWORD word processor
ASCII-armored PGP encoded
dBase Database
ASCII-armored PGP Public Keyring
DCS
ASCII-armored PGP signed
DCX Fax format
655
Table A.2: File Types Recognized D - J File Type
File Type
DDIF word processor
FTP Session Data
DEC WPS PLUS
GEM Bit Image
DECdx word processor
Graphics Environment Manager (GEM VDI)
Device Independent file (DVI)
Graphics Interchange format (GIF)
DG CEOwrite word processor
GZ Compress Encapsulation
DG Common Data Stream (CDS) word processor
Harvard Graphics
DIF Spreadsheet
Hewlett-Packard word processor
Disk Doubler Compression format
Honey Bull DSA101 word processor
DOS/Windows Executable (EXE, DLL)
HP Graphics Language (HP-GL)
DOS/Windows Object Library
HP Printer Control Language (PCL)
Dummy File (Internal)
HTML document
Dummy Print File (Internal)
HWP (Arae-Ah Hangul)
EBCDIC Text
IBM 1403 Line Printer
ENABLE Spreadsheet
IBM DCA-FFT word processor
Enable word processor
IBM DCA-RFT word processor
Encapsulated PostScript (EPS)
IBM DCF Script word processor
Enhance Window Metafile
IBM Display Write 4 word processor
Envoy word processor (EVY)
Informix SmartWare II Database
Excel Spreadsheet
Informix SmartWare II word processor
FileMaker (Mac)
Informix SmartWare Spreadsheet
Folio Flat file
Interleaf word processor
FPX Image
Kodak Multi-Resolution Image Format
Framework
JPEG File Interchange Format (JFIF)
Framework II
656
Appendix A
Table A.3: File Types Recognized K - U File Type
File Type
KPIF Chart Stream
Paradox (PC) Database
KW ODA G31D Raster Image (G31)
PC COM executable file
KW ODA G4 Raster Image (G4)
PC Object Module
KW ODA Internal G32D Raster Image (G32)
PC Paint Brush Graphics (PCX)
KW ODA Internal Raw Bitmap (RBM) Raster Image
PC True Type Font
Lasergraphics Language
PCD Image
Lotus 1-2-3 Spreadsheet
PeachCalc Spreadsheet
Lotus AMI Pro Draw (SDW)
Persuasion Presentation
Lotus AMI Professional word processor
PEX Binary Archive (SUN)
Microsoft Access
PGP Compressed Data
Microsoft Device Independent Bitmap
PGP Encrypted Data
Microsoft Excel Spreadsheet 95, 2000
PGP Public Keyring
Microsoft Office Drawing
PGP Secret Keyring
Microsoft PowerPoint (Mac)
PGP Signature Certificate
Microsoft PowerPoint (PC)
PGP Signed and Encrypted Data
Microsoft PowerPoint 95
PGP Signed Data
Microsoft PowerPoint 97, 2000
RAR Compressed Archive
Microsoft Project
Ultracalc Spreadsheet
Microsoft Project 4, 98
Unicode
Microsoft Project 2000
Uniplex (V6.01) word processor
Microsoft Publisher
Uniplex Ucalc Spreadsheet
Microsoft Visio
UNIX Compress Encapsulation UNIX SHAR Encapsulation UNIX TAR Encapsulation
657
Table A.4: File Types Recognized U - X File Type
File Type
(UNIX/VAX/SUN) Executable
WordMARC word processor
(UNIX/VAX/SUN) Link Library
WordPerfect 5.2 word processor
(UNIX/VAX/SUN) Object Module
WordPerfect 6.0 word processor
Usenet format
WordPerfect General File Format
UU Encoded Encryption File
WordPerfect Graphics V1.0 (WPG)
Verity XML (Internal)
WordPerfect Graphics V2.0 (WPG2)
Video for Windows
WordPerfect Mac word processor
Volkswriter word processor
WordPerfect word processor
VRML
WordStar 2000
Wang Office GDL Header Encapsulation
WordStar 6.0
WANG PC word processor
WordStar word processor
Wang WITA word processor
WPD format
WANG WPS Comm. format word processor
WriteNow word processor
Windows Animated Cursor
Writing Assistant word processor
Windows C++ Object Storage
X Bitmap (XBM)
Windows Help
X Pixmap (XPM)
Windows Micrografx Draw (DRW)
Xerox 860 Comm. format word processor
Windows Palette
Xerox Writer word processor
Word Connection word processor
XML
WordERA (V 1.0) word processor
XYWRITE / NOTA BENE WORD PROCESSOR
658
Appendix A
A.5 File Types Scanned This section lists the formats supported for text filtering by Email Firewall. Even if a file type is listed here, text can only be filtered for supported code sets.
A.5.1 A.5.2 A.5.3 A.5.4 A.5.5 A.5.6
Word Processing Formats ........................................................ 659 Picture Formats ....................................................................... 660 Presentation Formats............................................................... 661 Spreadsheet Formats................................................................ 661 Multimedia Formats................................................................. 661 Compression Formats .............................................................. 662
A.5.1 Word Processing Formats • • • • • • • • • • • • • • • • • •
Adobe Maker Interchange Format (MIF) v5.5 Adobe Portable Document Format (PDF) v1.1 to v1.4 Applix Word v4.2, 4.3, 4.4 Display Write v4.0 Folio Flat File v3.1 HTML v1.x, 2.x, 3.x IBM DCA/RFT vSC23-0758-1 Lotus AMI Pro v2.0, 3.0 Lotus AMI Professional Write Plus Lotus Word Pro v96, 97, Millennium Edition R9 (NT only) Microsoft RTF V1.0 Microsoft Word for Macintosh v4, 5, 6, 98 Microsoft Word for PC v2 to 6.0 Microsoft Word for Windows v1.0, 2.0, 6.0, 7.0, 8.0, 95, 97, 2000, XP Microsoft Works v1.0, 2.0, 3.0, 4.0 Microsoft Windows Write v1.0, 2.0, 3.0 Text All Unicode Text
659
• • • • •
WordPerfect for DOS through v6.1 WordPerfect for Macintosh v1.02 to 3.1 WordPerfect for Windows v5.x, 6, 7, 8, 9, 10 WordPerfect for Linux v6.0 XyWrite V4.12
Adobe Portable Document Format (PDF) Filtering PDF documents has the following limitations: • • •
Embedded fonts in a PDF file will not be translated correctly. They will usually be displayed using the replacement character, a question mark (?). Tables columns may have incorrect spacing, or table rows may be sorted incorrectly. Whitespace may not be used correctly in the filtered PDF. Spaces may be missing or spaces may be inserted where they are not required.
A.5.2 Picture Formats Email Firewall can filter the following graphics files when they are embedded or referenced within a document. • • • • • • • • • • • • • • • 660
Appendix A
AMI Draw Graphics (SDW) Applix Graphics V4.2, 4.3, 4.4 AutoCAD Drawing Exchange format (DXF) AutoCAD R13, R14, and R2000 AutoCAD Drawing format (DWG) AutoCAD R13, R14, and R2000 Computer Graphics Metafile (CGM) Corel Draw CDR (TIFF header) Encapsulated PostScript (TIFF header) Extended Metafile (EMF) EXIF Fax Systems (TIFF, CCITT, DCX) Groups 3 & 4 Graphic Interchange Format (GIF) JPEG File Interchange Format Lotus Pic (PIC) Macintosh PICT (raster content)
• • • • • • • • • • • •
MacPaint (Macintosh) Microsoft Excel Charts Microsoft Windows Animated Cursor Microsoft Windows Bitmap (BMP) Microsoft Windows Cursor/Icon Microsoft Windows Metafile (WMF) V3.0 PC PaintBrush (PCX) Portable Network Graphics (PNG) Sun Raster SGI RGB Tagged Image File (TIFF) (filters summary information) v3.0 to 6.0 Truevision Targa WordPerfect Graphics (WPG) v1.0, 2.0, 7.0
A.5.3 Presentation Formats • • • •
Corel Presentations v5.x to 8.0 Lotus Freelance Graphics v2.x, 96, 97, Millennium Edition R9 Microsoft PowerPoint v4.0, 95, 97, 2000, XP Microsoft PowerPoint for Macintosh 98
A.5.4 Spreadsheet Formats • • • • • • •
Applix Spreadsheets v4.2, 4.3, 4.4 Corel Quattro Pro v5.x to 8 Lotus 1-2-3 v2, 3, 4, 5, 96, 97, Millennium Edition R9 Microsoft Excel v3, 4, 5, 95, 97, 2000, XP Microsoft Excel workbook (.xlw) Microsoft Excel for Macintosh 98 Microsoft Works Spreadsheet v1.0, 2.0, 3.0, 4.0
A.5.5 Multimedia Formats •
MP3 (filters summary information) ID3 version 1 to 2
661
A.5.6 Compression Formats •
662
Appendix A
PKZip ZIP archive format
B
Code Set Support
This appendix provides an overview of how Email Firewall supports textscanning policies when the search words and message data use characters outside of the ASCII-7 character set. Also discussed are the extraction of nonEnglish text from attachments, the handling of text messages that do not conform to Internet standards, and the expected behaviors for other Policy Engine features when non-ASCII-7 text is used. To best understand the concepts described here, you should be familiar with the Email Firewall Policy Engine and related technologies. This appendix contains the following sections: B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8
Definitions and Concepts .......................................................... 664 Data In The Email Firewall Database...................................... 666 Extraction of Text From Message Content................................ 669 Policy Engine Expected Behaviors ........................................... 671 International Text Usage ........................................................... 674 Message Body and Attachments................................................ 677 Message Subject ........................................................................ 678 ISO Tables ................................................................................. 679
663
B.1 Definitions and Concepts The following sections provide a brief overview of some of the definitions and concepts relevant to this document.
B.1.1 Characters and Code Sets An email message, like any other piece of data on a computer, is just a sequence of bytes. The MIME standards tell us how to interpret that sequence of bytes as a message that potentially contains headers, text, and attachments of various types. The same is true of the message text itself; it is just a sequence of bytes. Obviously, most humans need to be shown this sequence of bytes as a sequence of characters in order for the message to be understood. The Unicode Consortium offers this definition of a character on its web site: Character: The smallest component of written language that has semantic value; refers to the abstract meaning and/or shape, rather than a specific shape (see also glyph), though in code tables some form of visual representation is essential for the reader's understanding.
A code set indicates how to interpret a sequence of bytes as a sequence of characters. In other words, it indicates how to map a sequence of bytes into a sequence of characters. This mapping can be defined in two parts. First, there is a character mapping from characters to numbers (or vice versa). Then, there is the encoding scheme that indicates how a sequence of bytes should be translated into a sequence of numbers. For code sets with less than 256 characters, there is a natural encoding scheme in which the binary value of each byte is the number to map. Note that there may be byte values that do not have a valid mapping in a particular code set. For example, the ASCII code set only defines a mapping for the number 0 through 127. There is no mapping defined for values 128 through 255, but it is certainly possible to encounter bytes with those values. Sometimes the term character set is used as a synonym for code set or character-encoding scheme. In particular, the MIME standards use this term. There are also some encoding schemes that are state dependent. This means that a byte or sequence of bytes can alter how subsequent bytes in the sequence are to be interpreted. The Japanese character sets ISO-2022-JP and Shift-JIS are both examples of state dependent code sets. 664
Appendix B
Unicode is a character mapping. The goal of the Unicode is to provide a number
for every character, no matter what language is being written. Unicode is widely accepted as the standard way to store international text data. There are several standard character-encoding schemes for Unicode including UTF-8, UCS-2, and UCS-4.
B.1.2 Message Text Parts RFC 2046 section 4 defines the standard for including text content in an Internet email message. In section 4.1.2, the charset parameter is described. This parameter value may be placed on the Content-Type header of a text part to indicate the character set (i.e. code set) that should be used in the interpretation and display of that text. If the charset parameter is not present, RFC 2046 states that US-ASCII set should be assumed.
The Policy Engine depends upon the charset parameter being set accurately in order to correctly interpret the text. If the charset parameter is deliberately set to an incorrect value, it is possible that text-scanning policies will fail to match words from that text. More about text/plain content is discussed in B.3.2 Handling Text From Unsupported or Unidentified Code Sets on page 669.
B.1.3 Non-ASCII-7 Text in Message Headers The SMTP protocol limits all Internet email message content to the ASCII-7 code set. This implies that non-ASCII data needs to be encoded using only characters from the ASCII code set. RFC 2822 is the standard for email message content. This standard also limits
message headers to the ASCII code set. When non-ASCII characters need to be included in a message header, the word or words containing those characters need to be encoded using one of the techniques described in RFC 2047. The details of the encoding techniques are not important for this document. However, it is important to know that when a word is encoded using these techniques, the code set of the decoded text is explicitly declared.
B.1.4 The Default Recipient Locale Email Firewall supports the concept of the default recipient locale in the Policy Engine. This is a configuration setting that tells the Policy Engine the default 665
language, locality, and character set that should be assumed for recipients in the Email Firewall user’s organization. This configuration parameter is not exposed in the Web Administrator user interface. The default value for this parameter declares that the default language is English, the default locality is the United States, and the default code set is ISO-8859-1 (which is widely used in the US and Western Europe and is handled correctly by most email clients). The default recipient code set affects several Policy Engine behaviors as described in B.3.2 Handling Text From Unsupported or Unidentified Code Sets on page 669.
B.2 Data In The Email Firewall Database Nearly all data entered into the Email Firewall database is stored as Unicode. This includes the text for policy events, notifications, and annotations. The characters in Email Firewall word lists are also stored as Unicode values.
B.2.1 Word List Data The words, phrases, and regular expressions on word lists are comprised of Unicode characters. It is expected that any printable character should be accepted as a valid input character for a word list item. That is, all Unicode characters may be used in words, phrases, and regular expressions. The only exceptions are the control characters (carriage return, line feed, form feed, etc.) Some characters have special meanings as wildcards, word separators, regular expression operators, and regular expression delimiters, so they may not be treated literally depending on the context in which they appear. The Policy Engine compiles each word list into a sequence of regular expressions to facilitate the matching of message text against the contents of the word list. This compilation happens once (in each instance of the Policy Engine service) the first time that the word list is used in a policy. If the word list is modified, the Policy Engine will notice the change and recompile the word list on the fly. See Appendix C, Using Regular Expressions for additional information about regular expression operators and class characters.
666
Appendix B
Special Treatment of Japanese Text On Word Lists When considering text entries (not regular expressions) on a word list, the Policy Engine examines the characters to determine whether or not the text may be Japanese. If the text is Japanese, the compiled regular expression does not indicate that white space or punctuation characters must delimit the words. This is done because the words in a Japanese sentence are not normally separated by spaces as is common in western languages. However, there is a known limitation with respect to the scanning of Japanese text in email messages. When Japanese text is entered into an email client application, the client may be required to break up that text into multiple lines in order meet the line length requirements of SMTP. Since there may be no white space characters in a sequence of Japanese characters, there is no natural place to insert the line break. Thus, it is possible that the line break will be inserted in the middle of a word. When a line break is inserted in the middle of a word, it will cause a policy that is scanning for that word to fail to be triggered. This is because the Policy Engine normally considers line breaks to be word separators and it does not know whether the line breaks in that message body part were intentionally inserted by the author or automatically inserted by the email client. Email client applications may avoid breaking up words by using one of the standard content transfer encoding methods (quoted-printable or base64) when Japanese text is written in a message body part. However, it is not currently possible to configure the Policy Engine to enforce the use of a particular transfer encoding for message text parts.
B.2.2 Issues With Handling Non-English Text There are some limitations to how Email Firewall handles non-English words. The problem stems from the fact that letters outside the supported character sets are treated as “end of word” characters, so that letters outside the supported character sets are treated as word separators. For example, if one enters the word “fran” on a word list, a policy should only match text where it finds those four characters in sequence with a word separator (like a white space or punctuation mark) before the ‘f’ and after the ‘n’. The problem that arises is that when the word separator characters at the end are not in a supported character set, the policy will trigger on the word. Consequently, the policy will trigger on a word like “fran” that has an additional Cyrillic, Arabic or Greek character at the end, for example, when it should not. 667
For another example, normally if you enter the word “rich” on a word list, the policy should only fire if it finds those four characters in sequence with a word separator before the ‘r’ and after the ‘h’. But because of the way word separator characters are considered, this means that the policy will trigger on a word that has a non-supported character immediately before “rich” when it should not. Note that this is only a problem at the end of words, not at the beginning. So in the first example, a word like “efran” would not match. All letters in the following code sets are treated as letters, and not as word separators: • • • • • • • • • •
ISO 8859-1 (Latin 1) ISO 8859-2 (Latin 2) ISO 8859-3 (Latin 3) ISO 8859-4 (Latin 4) ISO 8859-8 (Hebrew) ISO 8859-9 (Latin 5) ISO 8859-10 (Latin 6) ISO 8859-13 (Latin 7) ISO 8859-14 (Latin 8) ISO 8859-15 (Latin 9)
A weakness also exists with the regular expression capabilities. The operators \w and \W are provided as conveniences meaning “any word character” or “any non-word character” respectively. But they do not take non-English words into account since they only include (or exclude) the letters A through Z. There are no alternative operators that would include or exclude letters from other languages. You can avoid this limitation, but doing so involves writing long and complex regular expressions.
Personal Quarantine Manager and Character Sets The only supported and tested character set for use with PQM is en_US.iso8859-1. This means that all Quarantine Summary Notification (QSN) content is in the English language and uses the ISO-8859-1 character set for the inline text and HTML content of the notifications.
668
Appendix B
B.3 Extraction of Text From Message Content As mentioned in the B.2 Data In The Email Firewall Database on page 666, Email Firewall word lists are stored as Unicode characters. The regular expression processor in the Policy Engine works on Unicode data that will be compared against a sequence of Unicode-based regular expressions. Consequently, the Policy Engine must be able to map the characters extracted from a message to Unicode in order to compare the text against the contents of a word list. In order to map text to Unicode, the Policy Engine must know the code set of the content in the message. For the text/plain parts of an email message, the charset parameter is used to determine the code set. Similarly, when text is extracted from an attachment, it is necessary for the Policy Engine to know the code set of that text in order to convert it to Unicode.
B.3.1 Extraction of Text From Attachments The Policy Engine uses software from Verity to extract plain text from file attachments of certain types and from HTML text. This software effectively performs the conversion to Unicode for the Policy Engine at the same time that the text extraction takes place. Verity is able to successfully map text from a much larger number of character sets than is supported for plain text body parts. Consequently, Email Firewall is better at matching international text in attachments than it is at matching international text found in the message text or subject header.
B.3.2 Handling Text From Unsupported or Unidentified Code Sets There are five cases where the Policy Engine may need to consider text that cannot be reliably mapped to Unicode: • • •
A text/plain part with a charset parameter value that is not supported by Email Firewall. A subject header contains one or more RFC 2047 encoded words using a character set not supported by Email Firewall. Text is extracted from a document by the Verity libraries, but Verity was unable to identify the original code set for that text. 669
• •
A text/plain part with no charset parameter contains non-ASCII characters. A subject header contains non-ASCII characters (not RFC 2047 encoded).
All of these cases are handled exactly the same. The Email Firewall Policy Engine will attempt to map the bytes to Unicode assuming that the bytes are using the default recipient code set. This code set is ISO-8859-1. You may need to know when a message contains text that cannot be reliably mapped to Unicode by the Policy Engine. For this case, there is an option in the Policy Engine that indicates that a message should be marked as having an attachment causing a decomposition error whenever it contains text that cannot be reliably mapped to Unicode. By marking messages this way, you can write a policy to treat these messages differently (e.g., using quarantine or detention) if necessary. This option is enabled using Web Admin on the Setup > Policies page. See 2.7.3 Setting Up Other Global Policy Options on page 91 for instructions. When this Policy Engine option has been enabled, all of the cases described above cause the message to be marked as having an attachment with a decomposition error. An exception is made when a text/plain part has no charset parameter and all of the bytes in the text are safe ASCII codes. The safe ASCII codes are the printable characters (values 33 through 126) plus these control codes: horizontal tab (9), carriage return (10), form feed (12), line feed (13), and white space (32). Assuming the decomposition error option has been enabled, the Policy Engine will log an event with an ID value of 6082 whenever a text part is encountered that cannot be reliably mapped to Unicode.
B.3.3 Handling of Unmapped Characters When mapping message text to Unicode, Email Firewall will usually leave an unmapped code in the byte stream unchanged in the Unicode stream. In other words, when a byte sequence from the message text is not legal according to the rules of the encoding scheme being used, the encoded numeric value for that byte sequence is used in the Unicode character sequence given to the regular expression processor. However, it is possible that for state-dependent character-encodings, illegal input streams might cause a mapping error that will result in the message being placed in Quarantine (when a text scanning policy is applied to that message.)
670
Appendix B
B.4 Policy Engine Expected Behaviors This section describes the expected behaviors of the Policy Engine features when non-ASCII-7 text is used in the following areas: • • • • •
Annotations Notifications Events Subject Header Alterations MIME Header Policies
B.4.1 Annotations As mentioned earlier, annotation text is stored as Unicode in the Email Firewall database and may therefore include characters from practically all written languages. If there are characters in the annotation text that have no representation in the target character set, none of the text from that annotation will be added. A warning event will be logged in the Email Firewall Event Log. This may result in some empty attachments.
Inline Annotations Expected behavior is that the inline annotation text will be mapped from Unicode to the character set specified in the inline text/plain and text/html parts containing the message text. When there is no inline text part in the message, a new one is added for the inline annotation and the character set on that part will be the default recipient character set.
Attached Annotations Expected behavior is that the attached annotation will be a text/plain part with a charset value equal to the default recipient character set. The annotation text will be mapped to the default recipient character set before it is written into the attachment. Even assuming that all characters were successfully mapped from Unicode to the default recipient character set, whether the attachment is viewable on the recipient’s desktop depends on factors beyond control of Email Firewall. You
671
may also have no control over which application the recipient uses to view that attachment or what code sets are supported on that desktop.
B.4.2 Notifications Expected behavior for all notifications generated by Email Firewall is that the body of the notification message will be an inline text/plain part with a charset value equal to the default recipient character set. As mentioned earlier, notification text is stored as Unicode in the Email Firewall database and may therefore include characters from practically all written languages. If there are characters in the notification text that have no representation in the target character set, none of the text from that notification will be added. A warning event will be logged in the Email Firewall Event Log. This may result in some empty notifications.
B.4.3 Events Since event text is saved in the database as Unicode and the Email Firewall event log is in also in the database, no code set conversions are required to use the event text in the event. As a result, any user-defined events should be logged to the event log with the description text exactly as the user has defined it. When an event is logged at level major, the event is recorded in the Windows Event Log in addition to the Email Firewall event database. The Unicode characters from the user’s description are passed unchanged to the Windows event logging API. However, whether or not all characters will be correctly displayed by the Windows Event Viewer application is beyond the control of Email Firewall. What one sees in the Windows event viewer is likely to be dependent upon the “Regional Settings” on the machine where the event log is being viewed.
672
Appendix B
B.4.4 Subject Alteration For subject headers with no RFC 2047 encoded words, the expected behavior is that any added text will be mapped to the default recipient character set and then, if necessary, RFC 2047 encoded. A warning event can be logged if the text cannot be RFC 2047 encoded. For subject headers that originally included RFC 2047 encoded words when the message was received, the expected behavior is that any added text will be mapped to the character set already in use within that subject header. If a character in the text to be added has no mapping to the target character set, character code 63 is used – which is the question mark character in all western language code sets. In the cases where the original subject has RFC 2047 encoded words using an unsupported character set, Email Firewall logs a warning event (level = normal) and no subject alterations are made to the original subject. The same behavior occurs when the original subject has multiple RFC 2047 encoded words using different character sets, even if those character sets are supported. When the original subject includes non-ASCII characters that have not been RFC 2047 encoded, subject alterations will work as follows: •
•
Any words added to the subject will be RFC 2047 encoded if necessary (using the default recipient character set) but the original subject text will not be modified or re-encoded. No text deletion actions will be performed on the original subject. A warning will be logged (level = normal).
B.4.5 MIME Header Field Policies This section refers to the policy conditions available on the Basic Mail Filtering policies where one can test whether a MIME header exists, matches text, or contains text. This section does not refer to the MIME header security policies (remove MIME header, hostname hiding, address rewriting.) The implementation of the MIME header field policy conditions assumes that the headers have been correctly encoded using the techniques of RFC 2047. If an unsupported character set is used in the RFC 2047 encoding a Policy Engine warning will be logged (level = normal), and the policy condition will not be triggered.
673
For headers that contain non-ASCII characters that have not been RFC 2047 encoded, expected behavior is that the header contents will be mapped to Unicode in a byte-wise manner (each byte is directly converted to the numerically equivalent Unicode character) and the policy condition will attempt the text matching on that Unicode string. Code set specifications are supported for: • • •
Message body and attachments Message subject Notification and annotation generation
B.5 International Text Usage There are a variety of issues relating to the use of international character sets with Email Firewall. Following is a summary list. 1.
The Email Firewall Policy Engine supports ISO 8859 (1-9), ISO 8859-15, ISO-8859-8-I and ISO-8859-8-E, Unicode (UTF-7 and UTF-8), Windows1252 and Windows-1255, SJIS, EUCJP, and ISO 2022-JP encodings.
2.
The Email Firewall Policy Engine will not scan certain non-ASCII characters encoded in RFC 822 header fields. These characters include, but are not limited to: ƒ, Š, Œ, Ž, and ™. This issue does not affect text in the subject field. An error event is logged for each MIME header value that contains an unsupported character set or invalid ASCII characters.
3.
Attachment file names using 8-bit character encoded MIME headers are not displayed properly in the Web Admin UI. Email Firewall follows the RFC standards which provide that MIME headers should only contain ASCII (7-bit) characters.
4.
Email Firewall annotates emails and sends notifications using the same encoding as the original message. This may cause problems if the notification or annotation text is in Japanese. This could happen, for example, if an English ASCII-7 encoded message triggers a policy requiring a notification to be sent, but the notification text is in Japanese.
5.
674
Appendix B
When a message using an unsupported character set is encountered, Email Firewall will not add an annotation.
For example, Big5 is not a supported character set. When this unsupported character set is encountered, no annotation is appended to the message. 6.
The Euro symbol is not fully supported by Netscape Mail 4.77 and 4.79.
Japanese Character Issues Following is a list of known issues relating specifically to the use of Japanese character sets in Email Firewall. 1.
For Japanese text to be imported or exported properly, word lists, address lists, attachments, and tag text files must use Shift-JIS encoding.
2.
An English ASCII filename should be used in the Save dialog box Filename field when exporting words and phrases in a word list. If a Japanese filename is used, the filename appears as garbled text.
3.
In Japanese language locales, the use of half-width katakana text is not supported for use in annotation or notification text. Small katakana or full size katakana text should be used. Otherwise, the text is converted to random kanjii text.
4.
When generating a local certificate, using Japanese characters to specify the Organization Name results in an error message indicating that only English/ASCII text is accepted in the Organization Name field. To avoid this problem, always use English ASCII characters to specify the Organization Name.
5.
Microsoft Outlook users must select Encoding > Japanese (auto-select) in order to view Japanese UUEncode messages after they are modified by the Policy Engine.
6.
Annotations in Japanese may not display properly in certain messages. If the character set of the original message cannot support the characters included in the annotation, the annotation will not be displayed properly to the recipient (e.g., adding Japanese annotations to strictly English ASCIIencoded emails).
7.
UUEncoded messages typically do not contain character set information, so Japanese UUEncoded messages will not trigger word lists, etc. in Email Firewall.
8.
Several limitations exist regarding the use of Japanese characters in Email Firewall reports. Using Japanese characters as described below will cause errors in reporting. • Email Firewall reports do not work properly if the Email Firewall Administrator has logged in to Web Admin using Japanese Kanji 675
characters. To avoid this, always log in to Web Admin using English ASCII characters. • Email Firewall reports do not display organization names properly if they have been specified using Japanese Kanji characters. To avoid this, always specify organization names using English ASCII characters. • Email Firewall report titles do not display properly if they have been specified using Japanese Kanji characters. To avoid this, always specify report titles using English ASCII characters. • Japanese text is corrupted in exported reports. This applies to all exported formats (.html, .pdf and .rtf) and affects the directory name and am/pm time indication. 9.
When the text message format and encoding are NONE, and where the email client has inserted a line break in a Japanese word string, the Email Firewall Policy Engine cannot read the word properly. In the Japanese language (and some other languages), words are comprised of sequences of characters, but the words in a sentence or phrase are not normally separated by a space as is common in western languages. However, when Japanese text is entered into an email client application, the client may be required to break up that text into multiple lines in order meet the line length requirements of SMTP (RFC 2821). Since there may be no white space characters in a sequence of Japanese characters, there is no natural place to insert the line break. Thus, it is possible that the line break will be inserted in the middle of a word. When a line break is inserted in the middle of a word, it will cause an Email Firewall policy that is scanning for that word to fail to be triggered. This is because Email Firewall normally considers line breaks to be word separators and it does not know whether the line breaks in that message body part were intentionally inserted by the author or automatically inserted by the email client. Email client applications may avoid breaking up words by using one of the standard content transfer encoding methods (quoted-printable or base64) when Japanese text is written in a message body part. However, it is not currently possible to configure Email Firewall to enforce the use of a particular transfer encoding for message text parts.
676
Appendix B
B.6 Message Body and Attachments Message content is converted directly to Unicode. Code set support for message body and attachments includes the following: • • •
• • • •
• • • •
• •
US ASCII: 7-bit, US-only. ISO 8859-1: 8-bit. See Table B.1. Also known as Latin-1, covers most West European languages ISO 8859-2: 8-bit Also known as Latin-2, covers the languages of Central and Eastern Europe. See Table B.2. ISO 8859-3: 8-bit Also known as Latin-3. See Table B.3. ISO 8859-4: 8-bit Also known as Latin-4. See Table B.4. ISO 8859-5: 8-bit Also known as Latin/Cyrillic. See Table B.5. ISO 8859-6: 8-bit Also known as Latin/Arabic, covers only the basic alphabet for the Arabic language. ISO 8859-7: 8-bit Also known as Latin/Greek, covers modern Greek. ISO 8859-8: 8-bit Also known as Latin/Hebrew, covers Hebrew. ISO 8859-9: 8-bit Also known as Latin-5. See Table B.6. ISO 8859-15: 8-bit Also known as Latin-9 Contains the EURO sign and some important national letters. ISO 2022-JP: Japanese Covers a mixture of ASCII and JIS (Japanese Industrial Standard) X. SJIS: Japanese Also known as MS Kanji, covers the most common encoding method used on Japanese PCs.
677
•
• •
•
•
•
• •
EUC JP Extended Unix Code (EUC) for Japan. Supports JIS X 0201-1997, JIS X 0208:1997, and JIS X 0201-1990 character sets. UCS-2 Uniform Character Set-2 encoding. This is Unicode using 16-bit encoding. UTF-8 UCS Transformation Format-8. Also known as Unicode. UTF is a method for encoding 16-bit or 32-bit (UCS-4) representations so that data can be passed more reliably as text streams or in email messages. UTF-8 is the way in which Unicode is used under Unix, Linux, and similar systems designed around ASCII. UTF-7 A Mail-Safe Transformation Format of Unicode. UTF-7 transforms UCS encoded characters to a 7-bit encoding. UNICODE-1-1-UTF-7 7-bit encoding that is used to represent Unicode 1.1, as opposed to Unicode 1.0. UTF-16 The ISO/IEC encoding that is equivalent to the Unicode Standard with the use of surrogates. Allows the inclusion of certain UCS-4 codes in a UCS-2 encoded string. Windows-1252 Microsoft Windows Code Page 1252 for Western European languages. Windows-1255 Microsoft Windows Code Page 1255. Support for Latin/Hebrew.
B.7 Message Subject Message subject text is first converted to the local code page of the system, and then to Unicode. Some loss of data is possible if the subject text contains characters not in the local set. For content filtering of the message subject, the following code sets are supported: • • • • 678
Appendix B
US ASCII ISO 8859-1 ISO 8859-2 ISO 8859-3
• • • • • • • • • • • • • • • • •
ISO 8859-4 ISO 8859-5 ISO 8859-6 ISO 8859-7 ISO 8859-8 ISO 8859-9 ISO 8859-15 ISO 2022-JP SJIS EUC-JP UCS-2 UTF-7 UTF-8 UNICODE-1-1-UTF-7 UTF-16 Windows-1252 Windows-1255
B.8 ISO Tables ISO8859 is a family of single-byte encodings based on and compatible with other ISO, American National Standards Institute (ANSI), and European Computer Manufacturer's Association (ECMA) code extension techniques. The ISO8859 encoding defines a family of code sets with each member containing its own unique character sets. The 7-bit ASCII code set is a proper subset of each of the code sets in the ISO8859 family. While the ASCII code set defines an order for the English alphabet, the Graphic Right (GR) characters are not ordered according to any specific language. The language-specific ordering is defined by the locale. The following tables list the languages supported by the ISO code sets.
679
Table B.1: ISO 8859-1 and 15 Languages
Danish Dutch English Faroese Finnish French German Icelandic Irish Italian Norwegian Portuguese Spanish Swedish
Table B.2: ISO 8859-2 Languages
Albanian Czech English German Hungarian Polish Rumanian Serbo-Croatian Slovak Slovene
680
Appendix B
Table B.3: ISO 8859-3 Languages
Afrikaans Catalan Dutch English Esperanto German Italian Maltese Spanish Turkish
Table B.4: ISO 8859-4 Languages
Danish English Estonian Finnish German Greenlandic Lappish Latvian Lithuanian Swedish Norwegian
Table B.5: ISO 8859-5 Languages
Bulgarian Byelorussian English 681
Table B.5: ISO 8859-5 Languages
Macedonian Russian Serbo-Croatian Ukrainian
Table B.6: ISO 8859-9 Languages
Danish Dutch English Finnish French German Irish Italian Norwegian Portuguese Spanish Swedish Turkish
682
Appendix B
C
Using Regular Expressions
Email Firewall supports a range of UNIX regular expressions. Use these expressions when creating policies and word lists whenever the selection Regular Expression is available. This appendix contains the following sections: C.1 C.2 C.3 C.4
General Issues ........................................................................ 684 Operators................................................................................ 686 Character Class Operators .................................................... 687 Tutorial Examples................................................................... 690
In addition, Table C.1 lists each supported operator and its function in a regular expression. Table C.2 lists each supported character class and its function in a regular expression. Table C.3 shows tutorial examples of how regular expressions work.
683
C.1 General Issues In regular expressions, the backslash (\) and quote (“”) characters let you escape operators such as * or ? and do a search for special characters, \* or \], for example. In regular expressions, the blank character falls under the category of whitespace, and needs to be specially handled in order for the regular expression to be correctly recognized. For example, to specify the string “hi steve” as a regular expression, it must be specified as: “hi steve” enclosed in double quotes OR hi\ steve (blank explicitly escaped) OR hi\ssteve (blank specified as the whitespace \s).
C.1.1 Using Asterisks When used for text matching in Email Firewall policies, the asterisk (*) and question mark (?) characters function as text wildcards. In text searches, the * character matches zero or more instances of any character (A-Za-z0-9) in a word. When used for text matching in Email Firewall word lists, asterisks (*) function as wildcards. When used in regular expressions, the * character matches 0 or more occurrences of an expression: (exp)* The asterisk cannot be used as a text wildcard in a regular expression; however, the expression \w* would be its equivalent. When using regular expressions in Email Firewall word lists, keep the following in mind: •
•
684
Appendix C
When using the Advanced Add function to add regular expressions in word lists, regular expressions must be preceded by two asterisks (**) at the beginning of the line. This is how Email Firewall recognizes and identifies the item in the word list file as a regular expression. Using more than one asterisk in a single expression (e.g., *jackpot.com* or *tobacco.net*) so greatly increases the resources needed to scan messages for occurrences of this text that it effectively causes the Policy Engine to hang.
Using Question Marks In regular expressions, the ? character matches 0 or 1 occurrences of an expression. It cannot be used as a text wildcard in a regular expression; however, the expression \w would be its equivalent.
C.1.2 Incorrect Usage in Regular Expressions When a policy that uses a word list containing regular expressions is invoked, if a regular expression in that list is illegally formatted, Email Firewall logs a warning event and an error event to notify you. The message that invoked the word list with the illegally formatted regular expression is also quarantined with the tag “Internal Error.” Warning: Event Class Description: Wordlist compilation error Event Details: An error occurred while compiling the wordlist , possibly caused by a regular expression error. Error: Description: Internal Processing Error Details: An internal error has occurred; this message is being quarantined.
685
C.2 Operators The following table lists the Email Firewall regular expression operators and their function. Table C.1: Email Firewall Regular Expressions - Operators
686
Appendix C
Operators
Will match this
exp1|exp2
match either exp1 or exp2
exp1(exp2)
match exp1 followed by exp2 (parenthesis are not required)
exp?
match 0 or 1 occurrence of exp
exp*
match 0 or more occurrences of exp
exp+
match 1 or more occurrences of exp
exp{n}
match exactly n occurrences of exp
exp{n,}
match n or more occurrences of exp
exp{n,m}
match at least n, but no more than m occurrences of exp
(exp)
match exp (used for overriding precedence rules)
C.3 Character Class Operators The following table lists the character class operators, including special characters, and the actions they perform. Characters beginning with the forward slash character (\)must be escaped. Table C.2: Email Firewall Regular Expressions - Character Class Character Class
Will match this
.
match any single character that is not a line break. The only two characters not matched by the regular expression (.) are the carriage return (\x0D) and line feed (\x0A) characters.
c1
match this character as long as it is not a special character, such as an operator
\c1
match this character unless it is a special escape sequence
\n
match newline character
\r
match linefeed character
\t
match tab character
\v
match vertical tab character
\b
match backspace character
\f
match formfeed character
\a
match alert character
\\
match backslash character
\/
match forward slash character
\.
match period (dot) character
\|
match pipe character
\(
match open parenthesis character
\)
match close parenthesis character
\!
match exclamation point character
\?
match question mark character
687
Table C.2: Email Firewall Regular Expressions - Character Class (Continued)
688
Appendix C
Character Class
Will match this
\*
match asterisk character
\+
match plus sign character
\-
match minus sign or hyphen character
\{
match open curly brace character
\}
match close curly brace character
\^
match caret character
\$
match dollar sign character
\"
match double quote character
\[
match open square bracket character
\]
match close square bracket character
\<
match less than character
\>
match greater than character
\x00
match the NULL character
\w
match [_A-Za-z0-9]
\W
match [^_A-Za-z0-9]
\d
match [0-9]
\D
match [^0-9]
\s
match white space [\ \t\r\n\v\f] (see Note**)
\S
match non-white space [^\ \t\r\n\v\f]
\xhh
match character having hex value hh
\Xhhhh
match character having hex value hhhh
[c1c2c3c4-c5]
match either c1, c2, c3, or any character in the range c4 to c5
[^c1c2c3]
match any character but c1, c2, and c3
Table C.2: Email Firewall Regular Expressions - Character Class (Continued) Character Class
Will match this
“c1c2c3”
match every character between '’”’ (except escape sequences which are translated as above)
matches at the end of file
!exp
match expression only when it is preceded by the beginning of the input stream or by a non-word character*
* a non-word character is anything except: an underscore, a digit (0-9), or a linguistic character (alphabetic, syllabary, or ideographic) ** "\ " matches the space character hex=20
Expression Structure begin-line expression end-of-line-expression begin-line (optional) ^exp
match exp if it is at the beginning of a line
expression REGULAR-EXPRESSION (character classes and operators) end-of-line-expression (optional) exp$ match exp if it is at the end of the line (note: the new line characters are not consumed by the scanner)
689
C.4 Tutorial Examples These samples are not meant to be exhaustive, but are illustrative examples of what will (or will not) be matched when a policy is defined using regular expressions. Note the case sensitivity effect of enclosing the expression in square brackets, as shown in row 5. Table C.3: Email Firewall Regular Expressions Tutorial Examples But Will Not Match These Text Samples
This Regular Expression
Will Match These Text Samples
house
house House. HOUSE household doghouses DogHouse
thou seeth me
(house)|(HOUSE)
exactly the same as previous row of this table
exactly the same as previous row of this table
house|HOTEL
House hotel HOTel houseotel HOUShotel
doghous e nice hottel
hous(e|H)otel
houseotel houshoTEL
househotel houseHOTEL
[HOUSE]
HOUSE HO US nation
house hotel
[hH][o][u][s][e]
house House houses doghouses
HOuse HOUSE thou seeth me DoghousE
!house
house household
doghouse
690
Appendix C
Table C.3: Email Firewall Regular Expressions Tutorial Examples (Continued) This Regular Expression
Will Match These Text Samples
But Will Not Match These Text Samples
!house\W
house house. house,
houses household doghouse
abc*
ab abc abcabc abccCd xyzabc
acb
(abc)*
any text stream will match this expression
a(bc)*
a ad abc abcbc abcbcd xyzabc
bc
a(bc)?
a abc abcd abcbcbcbc xyzabc
ad
a(bc)?d
ad abcd
abcbcd
(abc)+
abc abcabcd mabcabc
(abc){2}
abcabcxyz abcabcabcabcxyz
abc abcd
ab{2}a
abba zabbas
aba ababa abbba
691
Table C.3: Email Firewall Regular Expressions Tutorial Examples (Continued) But Will Not Match These Text Samples
This Regular Expression
Will Match These Text Samples
ab{2,}a
abba abbba zabbbbas
aba
ab{2,3}a
abba abbba zabbbas
aba abbbba
\d{3}-\d{4}
555-1212xyz 01234-567890
555 1212
!\d{3}-\d{4}
555-1212xyz 555-121234567
0123-4567 555 1212
!\d{3}(\s|-)\d{4}\s
555-1212 999 0000 650-216-2000 tel:216-2000
555-12121212 999 0000 tel216-2000
692
Appendix C
D
Creating Custom Reports
This appendix provides information about how Email Firewall reports interact with the SQL Server database in generating reports, and provides procedures for how to add new reports based on the specific needs of an organization. The information provided here requires advanced-level understanding of SQL Server concepts and programming. To best apply the information described here, you should also be thoroughly familiar with the Email Firewall Policy Engine, Email Firewall default reports, and SQL Server database administration. These procedures are not intended for use by an administrator who is unfamiliar with SQL Server administration. This appendix contains the following sections: D.1 D.2 D.3 D.4
Creating and Installing a New Report ...................................... 694 Report Customization Section Selection ................................... 698 Parameter Field Order in the Report ....................................... 699 Report Categories ..................................................................... 701 Custom reports are not automatically migrated when upgrading to the next version of Email Firewall.
693
For information on how to create reports and/or how to interface these reports with the SQL database, refer to the appropriate administrator’s guide for either Crystal Clear or Crystal Reports depending on which reporting toolkit vendor you are using.
D.1 Creating and Installing a New Report D.1.1 Summary of Steps To add a custom report, these are basic steps that you need to follow: 1.
Create the report, making sure that the parameter fields order is consistent with the customization section that you selected.
2.
Put the report template in the correct location.
3.
Insert an report entry in the ReportList table, with the correct value for customizationSectionSelection.
4.
Add the proper resource strings to the report.properties file.
D.1.2 Creating and Installing the Report This section describes how to create and install a custom report. 1.
Design the report in Crystal Reports 8.0. Example: myReport.rpt
2.
Install the new report under the report directory. The location in the report directory depends on what level of source code access you have. There are two methods: 2a. Put myReport.rpt under \Email
Firewall\admin\web\reports directory and rebuild the mmsadmin.war. 2b. Put myReport.rpt under the installed directory, for example,
c:\inetpub\wwwroot\mmsadmin\reports. 3.
694
Appendix D
Configure the Web Admin to display the new report. To do this, you must insert the new myReport.rpt to the ReportList table. To do so:
3a. call the following script using the stored procedure
mmsSpAddReportEntry: exec mmsSpAddReportEntry 'name.Email Firewall.report.myReport', 'file.Email Firewall.report.myReport', 21 go 3b. mmsSpAddReportEntry:
Insert/update the report entry in the ReportList table. It takes the parameters shown in : Table D.1: ReportList Table Parameters Parameter
Description
@reportName:
String that is the resource string for the reportName or the reportName itself.
@reportFile:
String that is the resource string for the report filename or the filename itself.
@customizationSection:
Integer that indicates what report customization section to show. See D.2 Report Customization Section Selection on page 698 for details.
@reportCategory:
Default is null. Integer that indicates the report category (auditing|summary|user report).
@customFieldLabel:
Default is null. String that is the resource string used as the custom label for the input field input for the single field type report. This field is only used for the reports which select to show the single field selection. For example, “Message Volume Report for a Specific Recipient” has the label “Show report for this recipient”. “Directory and Policy Audit Report for a Single User” has the label “Show report for this auditor”. This uses the resource string stored in the database.
4.
Whenever you add a report entry in the database with the resource string in it, you must also add the string map to report.properties. For design reasons, the locale string and the resource string are added to the database, and the string maps must be placed in the resource files. 695
D.1.3 Example SQL Server Script for Adding Reports Following is an example of a script used to add reports to the Email Firewall database. if internationalization is not a concern for your organization, you can directly add the locale string to the database and the Web Admin service will be able to interpret them properly. For example, a report can be added using this: exec mmsSpAddReportEntry ‘Message Volume', 'messageVolumn.rpt', 7, 6 --- Insert volume reports exec mmsSpAddReportEntry 'name.Email Firewall.report.messageVolume', 'file.Email Firewall.report.messageVolume', 7, 6 go exec mmsSpAddReportEntry 'name.Email Firewall.report.specificAttachmentVolume', 'file.Email Firewall.report.specificAttachmentVolume', 39, 6, 'show.report.forThisAttachmentType' go --- Insert TopN reports exec mmsSpAddReportEntry 'name.Email Firewall.report.mostFrequentDetectedVirus', 'file.Email Firewall.report.mostFrequentDetectedVirus', 21, 3 go -- Insert Report For Specific Fields exec mmsSpAddReportEntry 'name.Email Firewall.report.specificRecipientAttachmentVolume', 'file.Email Firewall.report.specificRecipientAttachmentVolume', 39, 4, 'show.report.forThisRecipient' go exec mmsSpAddReportEntry 'name.Email Firewall.report.specificRecipientPolicyViolation', 'file.Email Firewall.report.specificRecipientPolicyViolation', 37, 4, 'show.report.forThisRecipient' go exec mmsSpAddReportEntry 'name.Email Firewall.report.specificSenderAttachmentVolume', 'file.Email Firewall.report.specificSenderAttachmentVolume', 39, 5, 'show.report.forThisSender'
696
Appendix D
go exec mmsSpAddReportEntry 'name.Email Firewall.report.specificSenderPolicyViolation', 'file.Email Firewall.report.specificSenderPolicyViolation', 37, 5, 'show.report.forThisSender' go -- Audit Reports exec mmsSpAddReportEntry 'name.Email Firewall.report.directoryAndPolicyAudit', 'file.Email Firewall.report.directoryAndPolicyAudit', 5, 1 go exec mmsSpAddReportEntry 'name.Email Firewall.report.singleUserDirectoryAndPolicyAudit', 'file.Email Firewall.report.singleUserDirectoryAndPolicyAudit', 37, 2, 'show.report.forThisAuditor' go
697
D.2 Report Customization Section Selection A single .jsp page is used to customize all the different kinds of Email Firewall reports. The customization page is summarized to different sections, so for different reports, the customization page will contain different combinations of the different sections. REPORT_CUSTOM_SECTION_DATE_RANGE (0x01): This section is for the user to choose date range for the report. This field is generally used for all the reports. REPORT_CUSTOM_SECTION_SUBTOTAL (0x02): This section is for the user to choose the interval period (by hour, day, week, etc.) This section is often used for the volume report. REPORT_CUSTOM_SECTION_TITLE_TEXT (0x04): This section is for the user to input the title and organization information for the report. This section is generally used in every report. REPORT_CUSTOM_SECTION_VIEWER_TYPE (0x08): This section is currently not used, because Crystal Clear only supports one viewer type. REPORT_CUSTOM_SECTION_RECORD_SELECTION_SORTING (0x10): This section is for the user to choose the sort order. It is often used in the FrequentXXX type report. REPORT_CUSTOM_SECTION_SINGLE_FIELD (0x20): This section is for the user to input the specific field information for doing the report. For example, “Message Volume Report for a Specific Recipient”, is for the user to input the recipient’s email address for the report. When adding the new custom report: 1.
decide what sections you want to display
2.
add up each section’s value to provide the value @customizationSection parameter for mmsSpAddReportEntry.
For example, a volume report (attachment volume or message volume) will always have the date range section, subtotal section, and title text section. So the value it adds up to will be 7.
698
Appendix D
D.3 Parameter Field Order in the Report The reporting commands Email Firewall passes to Crystal Clear use URL commands. In the URL, the parameters are passed through index but not named. The parameters are like: prompt0=xxx&prompt1=xxx, etc., so it is very IMPORTANT that the parameters passed through URL match the parameters in the report. Otherwise, you will run into unexpected errors. Following is an example of the algorithm used in the Web Administration service to build the parameters. StringBuffer
parameters = new StringBuffer (
900 ); int promptIndex = 0; if ( hasTitleSection ) { String prompt = "&prompt" + promptIndex++; parameters.append( prompt ) .append( "=" ) .append( companyName); prompt = "&prompt" + promptIndex++; parameters.append( prompt ) .append( "=" ) .append( reportTitle); } if ( hasDateRangeSection ) { String prompt = "&prompt" + promptIndex++; parameters.append( prompt ) .append( "=" ) .append( startTime ); prompt = "&prompt" + promptIndex++; parameters.append( prompt ) .append( "=" ) .append( endTime); } if ( hasSubtotalSection ) { String prompt = "&prompt" + promptIndex++; parameters.append( prompt ) .append("=" ) .append( interval); } if ( hasSortSection ) { String promptRowCount = "&prompt" + promptIndex++;
699
parameters.append( promptRowCount ) .append( "=" ) .append( recordCount ); String promptSortOrder = "&prompt" + promptIndex++; parameters.append( promptSortOrder ) .append( "=" ) .append( sortOrder ); } if ( hasSingleFieldSection ) { String promptSingleField = "&prompt" + promptIndex++; parameters.append( promptSingleField ) .append( "=" ) .append( singleFieldValue); } return parameters.toString();
For this example, a custom report has a title, date range and subtotal section. The report’s internal parameters are named. Based the above algorithm, the named parameter fields in the report template must be in the following order: 1.
CompanyName
2.
ReportTitle
3.
StartTime
4.
EndTime
5.
IntervalPeriod
If you need additional information to interpret this example, please consult your organization’s SQL Server administrator or your Tumbleweed Technical Support representative.
700
Appendix D
D.4 Report Categories There are different type of reports, categorized into the following categories: •
Volume Report: Attachment, Message Volume, Virus Type and Count, and Attachment Volume for a specific extension type. These reports are based on the summary tables. The summary tables are the data Email Firewall summarizes on an hourly basis from the report detail tables. The intention is for the summary table to persist without taking up too much disk space. The summary table data only gets recorded hourly, so you will have to wait for at least an hour for the data to show up in the report. A SQL Server Agent job is installed by the installer to create the summary on an hourly basis. If the summary report does not show up as expected, the first thing to check is whether the SQL Server Agent is enabled and running.
• • •
Audit Report: Report on the audit activity taken on policies and directories. Frequency Report: Report on the frequent recipient, policy, virus sender, etc. User Report: Diagnostic report on user activities.
For information and procedures for Email Firewall reports generally, see Chapter 11, Email Firewall Reports.
701
702
Appendix D
Index Symbols "A" records, searching for 47 .rar file detection, limitations 644
A A records 46 accepting SPN links 465 accounts setting up administrator accounts 21 actions backup actions in policies 209 dispositive actions in policies 208 in policies 208 in policies, defined 204 informational actions in policies 208 message action hierarchy 233 resetting queue actions 121 setting up quarantine queue aging actions 122 setting up queue actions 120 setting up retry intervals 124 severity of 235 severity, affects of 235 transformational actions in policies 208 active content in html, detecting 310 Active Directory, only Authenticated Account access
540 adding an alternate DNS server 41 adding custom X-headers to messages 315 adding policies to directory objects 302 address using as catch or exclude condition 211
address lists advanced add 266 creating 265 defined 265 example 266 format required 267 wildcards 266 wildcards caution 266 administration overview 7 administrative security 9 administrative tasks, generally 343 administrator accounts preferences 31 setting up 21 Adobe 651 Advanced Add attachment lists names and types 270 character set required 262 in address lists 266 in word lists 263 using with tags 277 Advanced Add, word lists and regular expressions 260 aging, in quarantine queue 119 aging, quarantine queue 122 aging, specifying in quarantine queue 122 All folder described 223 function and policies 246 Allow Security Stripping policy 388 alternate host for critical notifications 289 annotating all outbound mail with a disclaimer, example 282 703
annotations "Outbound Disclaimer" example 284 clean stamp 217 defined 278 global 279 skipping annotation text 281 using placeholders in annotation text 281 using placeholders in global annotations 280 annotations not skipped 325 anti-spam strategies, generally 329 applying policies, general rules 245 Archive, setting up 88 ASCII armored key file 400 associating an email address with a certificate 413 associating self-signed certificates 413 attachment lists described 268 file types 269 wildcards 270 wildcards caution 270 Attachment Volume and Size 617 Attachment Volume for Attachment Type 619 Attachment Volume for Specific Recipient 627 Attachment Volume for Specific Sender 628 attachments detection of infected 217 detection of long file names in 251 EXE block policy 250 file-stripping policies, using 303 Multimedia Attachments Deferral policy 251 security stripping of 388 using file stripping policy on 215 Attachments Policy Types 215 Attribute Mapping in LDAP import 536 Audit Reports 629 Audits, setting logging for 188 Authenticated Account access for Active Directory
540 authenticity of certificates 495 auto certificate association policy, usage 382 auto certificate association, and new certificates 383 AutoCAD 651 automatic certificate association, overriding 493 automatic certificate lookup, overriding 381 automatic downloads, virus pattern files 83 704
automatic lookup of user certificates 381 auto-responding to SPN link requests 461 auto-responding to SPN link requests, steps 463
B Backup Actions, in policies 209 backups in queues, troubleshooting 327 Basic Mail Filtering - Outbound Size Deferral 248 Basic Policy Types 211 BCC recipients, isolating on separate copies of message
95 best match algorithm 66 best match algorithm and wildcards, for SMTP Relay
66 bounce action 62 bounced notifications, deleting 44 browser sessions, using multiple instances 11 browser settings preferences 32
C cached CRL DPs 421 Catch Conditions, in policies 206 catch conditions, using address 211 catching mail that is not encrypted but should be 525 categorization of spam 340 Centralized Event Logging and Reporting 101 certificate responder, enabling for proxy security 479 certificate SubjectAltName field, email address in 424 certificates associating email address with 413 associating self signed 413 automatic certificate association 382 automatic lookup 381 cached CRL DPs 421 certificate responder 479 CRL checking 500 Direct Trust, defined 412
dynamic lookup 496 exchange and verify certificates for proxy security, example 495, 517 exporting 435 exporting certificates and root keys 436 generating 433, 442 how they become invalid 401 importing 495 new, and auto certificate association 383 obtaining CRLs overview 419 overrides of LDAP lookup certificates 381 overriding automatic certificate association 493 overriding automatic certificate lookup 381 PrivateKeyWizard, using the tool 438 proxy security and invalid server certificates, effects 402 proxy security, exporting certificate root key 478 proxy, overview 414 publishing as a root key 436 removing or renewing 582 rolling over invalid or expired certificates 497,
519
rollover checklist overview 404 rollover of local certificates 497, 519 rollover overview 403 self-signed 412 server, use in proxy security 413 third party certificate requirements 398 third-party 398 TLS and MX record issues 55 Trust According to Certificate Status, defined 412 trust concepts 412 updating local certificates 497, 519 usage in proxy security 479 verifying authenticity 495 character sets and importing lists 262 characters and code sets, defined 664 checking for SPN link requests 465 checking for SPN link response 465 Clean Stamp policies 217 cleaning up the directory for LDAP Import 558 client encryption and signature policies, creating 528 Client Encryption and Signature policy 385 Client Encryption and Signature policy, example 480 client-to-client security 385 how to set up 521 plaintext access policies 387
cluster environment EMFSave requirement 594 code sets and word lists 666 command line program tools 560 Compressed Files 645 conditions not configured properly 324 conditions, using in policies 206 confidence level 340 confidence X-headers 341 configuring a mapping for LDAP Import 548 a query for LDAP Import 545 a Secure Public Network 458 proxy security, example 474, 504 SPNs 458 Contact Information, Tumbleweed xxviii content type 340 content X-header 341 Convert UUencoded Attachments to MIME Format
216 copy and restore options, required selections 595 copying messages with EMFSave 595 Corel Draw 651 corrupted filter, removing 353 create and manage security 432 creating a custom header 469 creating a new Local Secure Domain, steps 459 creating a new policy, example 296 creating a plaintext access policy for recipient 521 creating a plaintext access policy for sender 523 creating a policy to check for successful SPN 467 creating an Event ID 194 creating and editing policies, generally 255, 329 Creating LDIF Files 555 creating proxy security policies, examples 480, 507 critical notifications, specifying an alternate host 289 CRL checking 500 CRL downloads specifying the HTTP Proxy Server 502 CRL source and download schedule 501
705
CRLs checking order 421 downloads overview 420 manually downloading 502 models for obtaining 419 overview of scheduling downloads 420 precedence of CRLs 421 scheduled downloads and the Download service
420 trusted root key required 420 custom header, creating for SPN policy 469 custom reports 693 Customizing Audit Reports 634 Customizing Frequency Reports 632 Customizing Reports 630 Customizing User Reports 633 Customizing Volume Reports 631
D data in the EMF database, how stored 666 data sources, in LDAP import 535 database tables affected by updates 351 tables updated 352 database connection, Quarantine queue and inbound messages 135 database data, how stored 666 Database Files 645 Dead Letter queue 116 decomposition error event ID 6082 670 decomposition errors 246 decomposition failures and large embedded files 644 decomposition of embedded files, time limitation 644 Decompression Errors policy 246 Default Directory Structure 222 default domain record location in External folder 223 using 220 default domain records 221 default policies described 245 Default Policies and Folders, overview 245 default policies, viewing 296 default recipient locale, explained 665 Defer queue 116 706
deferring message delivery 248, 250 defining Local Secure Domains 458 definitions, policy 204 delay and non-delivery notifications from SMTP relay
48 delayed messages, notifying sender 124 deleting bounced notifications 44 deleting quarantined messages 145 Delivery Status Notifications (DSNs) 46 denial of service attacks, and SMTP relay settings 37 Detect cert-query policy 482 Detention queue 116 digital signatures 495 Directory default structure 223 folders in 223 importing users 532 objects contained 220 Directory and Policy Audit 629 Directory and Policy Audit by Administrator 629 Directory Audit 629 Directory Audit by Administrator 630 Directory Import Active Directory Authenticated Account access
540 attribute mapping 536 cleanup 551 cleanup directory 552 configuring a query 545, 548 internal source identifier 538 LDIF files 555 mappings 535 overview 534 performing the import 552 preview changes 550, 552 process 550 process of events 550 saving the import log 553 scheduling imports 553 sequence 539 tools 532 viewing the import log 553 Directory Import, using Clean Up Directory checkbox
558 directory object has not inherited a policy 324 directory tool, find user 532 Directory Tools 532
directory, entries for proxy security 494, 516 disabling policies 237 disabling the policy engine 35 disclaimers adding to all messages 279 annotating all outbound mail, example 282 using placeholders in 280 disclaimers in outbound mail, example procedure 284 dispositions applying most severe, in policy actions 235 dispositive actions, in policies 208 DNS Blackhole Lookups (DNSBLs), specifying 42 DNS server, adding 41 Document Files 646 domain record using 220 domain records default 221 location in Internal folder 223 overview 221 domains records for 220 setting security for, in SPNs 466 download events 352 failures 352 files and database tables 352 manual downloads 353 Download service and CRLs 420 downloading CRLs 501 Drawing Files 647 duplicate notifications, how to prevent 292 Dynamic Anti-spam service manual updates 353 performance counters 348 Dynamic Anti-spam Update Service maintenance 353 Dynamic Anti-spam Update service download file format 351 overview 351 purpose 351 dynamic lookup of certificates 496
E Email Firewall Main Menu 12 embedded files too large cause decomposition failure
644 EMF Administration overview 7 EMF Directory objects in 220 policy inheritance in 324 EMF events, when logged as Windows event 198 EMF service restarts, set to automatic 21 EMF Services Status 19 EMFSave saving messages in the queues 595 EMFSave and missing files 601 EMFSave copy and restore options, required selections
595 EMFSave database temporary files, and cluster environments 594 EMFSave in a cluster environment 601 enabling and disabling the policy engine 35 enabling policies 237 encrypted messages analysis of 339 encryption and digital signatures, creating stripping policies 524 encryption and signature, policies to monitor message state 528 error handling 347 internal error and message disposition 340 errors, decomposition 246 errors, decompression 246 Event IDs creating 194 defined 295 using placeholders in 197
707
event log audits 188 configuration 187 custom event IDs for 194 filters for 192 filters, creating 192 logging level for reporting 186 overview 190 policy action events 194 policy engine options 187 setting up event logging 186 settings 194 events downloads 352 logging 351 when logged as Windows events 198 exact matching, setting up in SMTP relay 65 exchange and verify certificates, example for proxy security 495, 517 exclude condition, using address 211 Exclude Conditions, in policies 207 EXE Blocking policy 250 Executable Files 647 expected behaviors with non-ASCII text 671 exporting the certificate and root key 435, 436 exporting the Certificate Root Key, for proxy security
478 External Folder 223 External folder described 223 function and policies 248 External-to-External mail routing, disallowing 59 extraction of text and unmapped characters 670 extraction of text from message content 669
F false positives how to submit to the lab 359 how to submit using Web Admin 359 false positives, submitting samples generally 356 File 655, 656, 657, 658 file attachment stripping and viruses 215 policy, defined 215 708
File Attachment Stripping – Decompression Errors 246 File names and file types, understanding in attachment lists 271 file type lists provided 640 file types limitations 644 file types for attachment lists 269 file types recognized 655 file types scanned 639 files scanned compressed files and embedded objects, issues
643 limitations 642 password protection and 649 files types recognized default lists provided 640 file-stripping policies, how they work 304 filters corrupted filter removal 353 filter version 353 troubleshooting update failures 354 using 192 Find user 532 Find User tool 532 finding policies 296 Folders 221 folders All folder 223, 246 External folder 223, 248 Internal folder 223, 248 objects in directory 220 forwarding SPN link requests 464 Frequency Reports 624 Frequent Policy Violation 624 Frequent Receiving Domains 624 Frequent Recipient Policy Violation 624 Frequent Sender Policy Violation 625 Frequent Sending Domains 625 Frequent Virus Sender 625 Frequently Detected Virus 624 full filegroups, increasing size 139 full SQL filegroups, and SMTP relay 76 full SQL Server file groups 327
G gateway-to-gateway security 369 general rules about applying policies 245 generating a certificate 433, 442 global annotations 279 global policy settings archive 88 isolating BCC recipient messages 95 limitations in physical file scanning 93 marking text parts that use unsupported character sets 94 peak time 87 text scanning options 91 Groups 651
H harvesting S/MIME certificates 394 headers added by the engine 340 message categorization 340 Headers Type Policies 218 health information, preventing inadvertent sending 252 hiding the product name and version number 40 Hierarchy of Message Actions 233 HIPAA lexicon 252 hoaxes, blocking 247 host name, where used 77 How Severity of Action Affects Policy Enforcement
235 HTML Mobile Code, detecting with policies 310 html tags, scanning 296 HTTP Proxy server, specifying for CRL downloads
502
I Image Files 648 Imperfect SPN Message Received policy 372 Import Directory, overview of LDAP Import 534 Import, performing the LDAP import 552 importing certificates 495 PGP keys 579 private keys from a PKCS#12 file 574 709
importing LDAP users 532 importing lists 262 importing third-party certificates, concepts 397 importing third-party certificates, using PrivateKeyWizard tool 438 importing third-party PGP key pair, concepts 400 importing user records, limitation 540 inbound mail how to stop 34 stopping 36 Inbound Mail Characteristics 624, 625 Inbound Mail Characteristics report 627 Inbound Policy Violations report 628 Inbound queue troubleshooting backups 139 Inbound queue, stopping the relay from accepting messages 119 Inbound Size Deferral policy 250 increasing the file size for full filegroups 139 Infected Message (Recipient) policy 250 Infected Message (Sender) policy 250 Infected Message policy 217 informational actions, in policies 208 inheritance, how policy inheritance works, example
237 installation recovery options set 348 Intended Audience 2 internal error, message disposition 340 Internal Folder 224 Internal folder described 223 function and policies 248 internal networks message processing 340 Internal Source Identifier, in mappings 538 Introduction 1
J Japanese text on word lists, word lists Japanese text treatment 667
710
K key pair and certificate, generating 433, 442 key pairs determining size 409 private key 408 public key 408
L large message processing 338 LDAP source for certificate lookup 381 LDAP Import Applying Directory Modifications 553 Clean Up Directory 551 cleaning up the directory 558 cleanup directory 552 Currently Requested Directory Modifications tab, information in 552 default attribute mapping 536 Import Now 552 import steps, configuring a query 545, 548 internal source identifier 538 LDAP Import Log File tab, information in 553 limitation on importing 540 overview 534 Preview Changes 550 preview changes 552 process 550 Saving Log as File 553 scheduling 553 sequence 539 using 532 using LDIF files in 555 View import log 553 what happens 550 LDAP import performing the import 552 LDIF files attribute filtering 555 steps in creating 555 using 555 using in LDAP Import, steps 556 license and version number, location 14 licking policies, caveat 238 line breaks in a Japanese word string, and encoding NONE 676
lists address lists 265 and character sets 262 attachment lists 268 attachment lists file types 269 behavior in queue filtering 128 creating a new tag 275 double-checking configuration 327 importing 262 not configured correctly 327 overview 256 types of 257 updating 327 Local MX Hosts configuration 41 local secure domain, defining 458 Local Secure Domains, overview 370 locking policies 237 logging events filters for 192 settings 194 Logging In 10 logging level for reports 186 Long Filename Quarantine policy 251 Lotus 123 652
M mail queues, described 116 mail routing rules setting up exact matching 65 manual CRL downloads 502 Mappings, in LDAP import 535 Mappings, internal source identifier 538 Melissa virus, quarantining 305 message actions, hierarchy 233 message backlogs, increasing filegroup size 139 message content, how extracted 669 message disposition and internal errors 340 Message Header Fields, list of 219 message headers, removing 219 Message Protection Lab overview 355 Message Queues Status 17, 114 message size limit, setting in SMTP Relay 37 Message Volume and Size 617 Message Volume for Specific Recipient 627
Message Volume for Specific Sender 628 message/partial MIME type 247 messages adding internal mail to processing 346 address as a catch or exclude condition 211 automating spam submittals 357 avoiding loops in policy-based routing 99 encrypted or SPN 339 enhanced content scanning 93 from internal networks, processing 340 from Secure Response, processing 338 headers added 340 how to submit false positives 359 how to submit false positives using Web Admin
359 large message processing 338 moving from quarantine queue 134 moving from spam queue 345 notification to sender of message delay 124 processing by the engine, overview 337 processing large messages 346 processing time for 348 refused by the Policy Engine 139 stopping inbound messages 138 stuck in the Outbound queue 141 submitting unmarked spam generally 357 Microsoft DTC, enabling 102 Microsoft Excel 652 Microsoft Network DTC Access, enabling 102 Microsoft PowerPoint 652 Microsoft PowerPoint with Macros 652 Microsoft Word 652 mobile code, detecting 310 modifying the SMTP Relay Session Welcome and Postmaster information 40 monitoring messages based on their state of security
528 Most Frequent External Receiving Domains 619 Most Frequent External Receiving Domains report 619 Most Frequent External Sending Domains 619 Most Frequent External Sending Domains report 619 Most Frequent Internal Recipients 617 Most Frequent Internal Recipients report 617 Most Frequent Internal Senders 617 Most Frequent Internal Senders report 617 Multimedia Attachments Deferral policy 251 Multimedia Files 648 711
multipart/partial messages, policy to block 247 multipart/signed messages not caught 326 multiple browser sessions, how to use 11 multiple word lists, cautions 260 MX record and TLS validation 55 MX records 46
N Naming policies 206 negative weights in word lists 261 non-English text, issues 667 non-spam, submitting samples generally 356 Non-SPN Message Received From a SPN Domain (Inbound) policy 372 Normalize Email Addresses in MIME Headers policy
219 notifications alternate host for critical notifications 289 avoiding duplicates 292 Bcc message recipients, and Original Message Recipients option 291 creating 290 defined 287 deleting bounced notifications 44 double-checking address 327 from the SMTP relay 48 Original Message Recipients, how determined
291 placeholders 291 text length 290 using placeholders in 291
O off-peak hours 248, 250 open relay, preventing 50 OpenPGP and Email Firewall 368 ASCII armored key file 400 harvesting PGP keys 394 PGP Key Responders overview 395 OpenPGP Overview 365 OpenPGP overview 368 OpenPGP proxy security sample procedures 504 Other Documentation 4 712
outbound mail how to stop 34 Outbound Mail Characteristics 627 Outbound Mail Characteristics report 627 Outbound Message Archival policy 251 Outbound Policy Violations 628 Outbound Policy Violations report 628 Outbound queue troubleshooting backups 141 Outbound Size Deferral policy 248 Overview of anti-spam methods 330
P Paradox 653 Partial Message Block policy 247 Partition relay, function 33 password protected files, and scanning 649 Password-Protected Files 649 pattern files 326 pattern files updating 326 Peak Time, setting up 87 performance counters messages processed 348 setting up 349 starting and stopping 350 performing the LDAP Import 552 Personal Quarantine Manager 142 PGP trust model 408 PGP key importing 579 removal or renewal 582 PGP keys default expiration 407 harvesting 394 rollover 407 placeholders in annotation text 281 in Event IDs 197 in global annotations 280 in notifications 291 Plaintext Access policies 387 plaintext access policy, creating for recipient 521 plaintext access policy, creating for sender 523
policies action, severity of 235 actions, types of 208 actions, using 208 adding custom X-headers to messages 315 adding to directory objects 302 All folder 246 applying to directory objects 319 applying to internal users, example 301 attachments types, overview 215 backup actions 209 basic types, overview 211 building blocks 256, 330 catch conditions 206 catching health information 252 checking actions in 325 checking conditions in 324 checking exceptions in 325 clean stamp uninfected messages 217 conditions not configured properly 324 conditions, using 206 configuration errors 324 creating a custom header for SPN 469 creating a new policy example 296 creating with X-headers 315 default policies 296 default, described 245
Detect cert-query, for proxy security, example
482 disabled 324 disabling 237 dispositive actions 208 editing default policies to scan html tags 296 enforcement of 235 event log actions 194 exclude conditions 207 exclude conditions not configured properly 325 External folder 248 file-stripping, using 303 general example 205 general rules about applying 245 HIPAA Compliance 252 how severity of action affects 235 how to test 320 imperfect SPN message received 372 infected message 217 informational actions 208 inheritance 324 inheritance example 237 inheritance, explained 237 Internal folder 248 locking 237 locking, caveat 238 log actions 194 Melissa virus text policy 305 multiple policies invoked 235 multiple policy actions, hierarchy 235 new viruses 305 Non-SPN Message Received from SPN Domain (inbound) 372 normalize email aliases in MIME headers 219 override example 238 overrides, explained 237 overview 204 plaintext access 387 planning considerations 253 policy applied to wrong folder 324 policy enabled at wrong directory level 324 preventing overrides, example 238 protection against new viruses 305 Proxy Decrypt and Verify, for proxy security, example 484, 510 random selection 213 713
recipient versus sender 325 remove hostnames and subdomains from MIME headers 219 remove MIME headers 219 security types list 217 should be recipient (or sender) 325 similar actions in 325 SPN types 372 summary of 209 to check for successful SPN 467 transformational actions 208 troubleshooting 324 unable to encrypt and sign to SPN domain 372 using address as catch or exclude condition 211 using Find 296 using X-headers in 316 virus-stripping, using 303 Policies Applied to the All Folder 246 Policies Applied to the External Folder 248 Policies Applied to the Internal Folder 248 Policy Action Events, setting logging for 194 policy applied to wrong folder 324 Policy Audit 629 Policy Audit by Administrator 630 policy building blocks 256, 330 policy building tools 253 policy definitions 204 policy disabled 324 policy enabled at wrong directory level 324 Policy Engine enabling and disabling 35 setting logging for 187 policy engine and troubleshooting policy enforcement 326 Policy example 205 policy inheritance, example 237 policy override, example 238 policy overview 204 Policy Violation for Specific Recipient 628 Policy Violation for Specific Sender 628 Policy, defined 204 policy-based routing and infinite message loops 99 Postmaster Information, modifying 40 714
PQM Quarantine Summary Notifications, see also, QSNs 144 server health check for administrators 146 PQM Server overview 143 protocols 143 Presentation Files 649 preventing non-secure messages from being sent 525 preventing policy overrides, example 238 Printing and Saving Reports 635 Printing Reports 635 private keys, size limit 438 PrivateKeyWizard tool 397, 400 PrivateKeyWizard tool, using 568 PrivateKeyWizard, using the tool 438 processing time for messages 348 Product Updates 109 program tools command line tools 560 EMF Update Service 602 EMFSave 592 EMFSave in a cluster environment 601 MMSLDIFImportConfig 560 PrivateKeyWizard 568 protocol, SMTP over TLS 374 proxy certificate usage and certificate responder, enabling 479 proxy certificates 495 use in proxy security 414 Proxy Decrypt and Verify policy 384 Proxy Decrypt and Verify policy, example 484, 510 proxy decryption, in security 380 Proxy Encrypt and/or Sign policy 384 proxy encryption, in security 379 proxy security associating email addresses in 413 associating self-signed certificates 413 checklist for setting up 474, 504 Client Encryption and Signature policy example
480 completing, example 496 creating a folder for user record 494, 516 creating a user record 494, 517 creating user records for 494, 516
Detect cert-query policy, example 482 exchange and verify certificates, example 495,
517
exporting certificate root key 478 invalid server certificates, effect 402 policy examples 480, 507 proxy certificates in 414 Proxy Decrypt and Verify policy example 484,
510
proxy decryption 380 proxy encryption 379 proxy signature 380 proxy verification 380 sample procedures 474 server certificates in 413 proxy signature, in security 380 proxy verification, in security 380 publishing the server certificate as a root key, steps 436
Q QSNs message content 144 message X-header added 145 messages included in 144 new, contents of 145 recipient access to quarantined messages 145 reply address displayed 144 Web responses to requests 146 Quarantine queue moving messages 134 quarantine queue specifying aging parameters 122 Quarantine queue, about 116 quarantined messages when deleted 145 quarantined messages, recipient access to 145 Quattro/Quattro Pro 653 queries, in LDAP import 535 queue filtering, using lists in 128 queue, moving messages out of 345
queues configuration 119 limitation on search results 126 quarantine queue aging 122 resetting queue actions 121 retry queue, setting retry intervals 123 retry queue, setting up retry intervals 124 setting up quarantine queue aging actions 122 setting up queue actions 120 troubleshooting backups 327 Queues, status 17, 114
R random selection 213 randomize order of MX hosts 47 recipient policies, applying 325 recovery options 348 Redirect queue 116 regular expressions 683 regular expressions, incorrect usage events 685 regular expressions, operators and their function 686 relay stopping the relay from accepting incoming messages 119 Relay Host name specifying a common name 39 relay messages 77 relay service host name, where used 77 relay, adding a DNS server 41 Remove Host Names and Subdomains from MIME Headers policy 219 Remove MIME Headers policy 219 removing or renewing a certificate or PGP key 582 reports event logging level required 611 Inbound Mail Characteristics 627 Inbound Policy Violations 628 logging level required 186 Most Frequent External Receiving Domains 619 Most Frequent External Sending Domains 619 Most Frequent Internal Recipients 617 Most Frequent Internal Senders 617 Outbound Mail Characteristics 627 Outbound Policy Violations 628 spam volume 621 Requesting an SPN Link, steps 461 715
requirements for third-party server certificates 398 resetting queue actions 121 responding to SPN link requests, steps 463 restore components missing from backup file 601 Resume Block policy 251 retry interval, in retry queue 120 Retry queue 116 retry queue notification to sender of message delay 124 retry queue, setting retry intervals 123 rolling back filter version 353 rollover of expired certificates 497, 519 root key, exporting 435 root key, publishing 436 root keys purpose 383 root keys, exporting 436 Rules, in policies, defined 204
S S/MIME and Email Firewall 366 Certificate Responders overview 395 harvesting certificates 394 S/MIME Overview 365 S/MIME security Certificate Authorities 417 establishing trust relationships 416 saving configuration and directory data 595 saving messages in the queues 595 Saving Reports 636 scanning html tags 296 scanning limitations 642 scheduling CRL downloads 501 scheduling CRL downloads, overview 420 scheduling LDAP imports 553 search queues limitation 126 Secure Messenger description 108 Secure Response service message processing 338 security administrative 9 certificate removal or renewal 582 certificate rollover checklist 404 716
certificate rollover overview 403 Client Encryption and Signature policy example
480 client-to-client 385 client-to-client, setting up 521 completing the proxy security exchange, example
496 creating a recipient plaintext access policy 521 creating a sender plaintext access policy 523 Detect cert-query policy, example, for proxy security 482 enabling certificate responder 479 exporting certificate and root key 435 gateway-to-gateway 369 generating a certificate 433, 442 LDAP lookup and manual association of certificates 381 OpenPGP overview 365 PGP key removal or renewal 582 policies to monitor messages based on security state 528 policy types, listed 217 prerequisites 431 private key size limitation 438 Proxy Decrypt and Verify policy example, for proxy security 484, 510 proxy decryption 380 proxy encryption 379 proxy security, proxy certificates in 414 proxy security, server certificates in 413 proxy signature 380 proxy verification 380 rolling over certificates 497, 519 S/MIME overview 365 server-to-client, overview 375 server-to-client, setting up 474, 504 setup questions 431 setup, overview 430 UI functions 432 unencrypted message filter policy issues 527 updating local certificates 497, 519 user records in proxy security 494, 516 see also, PQM 142 self-extracting zip files, limitation in scanning 644 self-monitoring of services 348 sender policies, applying 325 sender-based unencrypted message filter issues 527 Sensitive Info Review policy 252
server certificate, exporting 435 server certificate, publishing 436 server certificates, using third-party 398 server-to-client PGP security, configuring 504 server-to-client proxy security understanding 375 server-to-client security, configuring 474 server-to-client security, understanding 375 service recovery options 348 self-monitoring 348 Session Welcome, modifying 40 setting security for the domain 466 Setting Up Administrator Accounts 21 Setting Up Administrator Preferences 31 Setting up Centralized Event Logging and Reporting
101 Setting Up Global Policy Settings 87 Setting up Product Updates 109 Setting Up Queues 105, 109, 116 Setting Up Relay Centers Relay Centers, setting up 32 Setting Up Virus Scanning Options 80 signed messages not caught 326 slack space, scanning of 93 SMTP A records 46 MX records 46 SMTP and SSL 373 SMTP Relay adding an alternate DNS server 41 delay and non-delivery notifications 48 delay and non-delivery notifications, explained 48 enabling Delivery Status Notifications (DSNs) 46 full SQL Server file groups 76 hiding the product name and version number 40 Host Name configuration parameter, effect 77 identification errors, troubleshooting 77 illegal characters, using to avoid open relay blacklisting 43 Local MX Hosts configuration 41 mail routing rules best match algorithm 66 randomize MX hosts option 47 recipient limit, setting 37 search for ’A’ records option 47
service not accepting messages, troubleshooting steps 76 Session Welcome and Postmaster Information, modifying 40 setting message size limit 37 setting up bounce action 62 setting up exact matching for a domain 65 specifying the Relay Host Name 39 SMTP relay partition function 33 preventing open relays 50 settings to prevent DoS attacks 37 stopping inbound messages 138 spam anti-spam strategies, generally 329 automating spam submittals to the lab 357 categorization and message headers 340 confidence 340 confidence X-headers 341 content 340 content rating X-headers 341 non-spam samples 356 policies, creating 316 relay settings to prevent DoS attacks 37 samples, submitting 356 Spam Analysis queue, moving messages 345 submitting unmarked messages generally 357 Spam Analysis Engine error handling 347 event log events 351 message processing 337 messages not analyzed by 338 processing internal mail 346 processing large messages 346 rolling back a filter version 353 scan performed 340 three-strikes rule 347 spam volume report 621 SPN configuring 458 creating a policy to check for, steps 467 link requests, responding to, steps 465 policies 372 server-to-client, setting up 474, 504 setting security for domain 466 717
SPN link requests accepting 465 auto-responding to requests 463 checking for 465 forwarding requests 464 setting up EMF to respond 463 steps 461 SPN link requests and auto-respond 461 SPN links enabling 461 SPN or encrypted message analysis 339 Spreadsheet Files 650 SQL Server full file groups 327 full filegroups stopping message processing 139 SMTP Relay and full file groups 76 SSL and TLS 373 Stop the relay from accepting incoming messages 119 stopping inbound mail 36 Stopping Inbound or Outbound Mail how to 34 stopping the relay from accepting more messages 138 SubjectAltName field, in certificates 424 Summary, of policy 209 support, technical xxvii System Status 14 system status Email Firewall Services 20, 104 Info and Alerts 15 Message Queues 17
T tags Advanced Add 277 archive tag 274 creating 275 queue tag 274 technical support xxvii testing policies, procedure 320 text extraction 669 text extraction and non-ASCII text, how handled 671 text extraction and unmapped characters 670 text extraction and unsupported or unidentified code sets 669 text extraction, from attachments 669 Text Scanning Options, setting up 91 718
third-party certificates, import tool 438 third-party certificates, using for security 398 three-strikes rule 347 TLS certificate domain name match 80 MX record with domain name required to validate certificate 55 troubleshooting 80 TLS and SSL 373 TLS protocol 374 tools, find user 532 tools, for policy creation 253 transformational actions, in policies 208 troubleshooting annotations not skipped 325 checking policy actions 325 checking policy conditions 324 checking policy exceptions 325 common lists 327 Inbound queue backups 139 inbound queue backups 139 inheritance 324 notification address 327 notification address is incorrect 327 Outbound queue backups 141 policy applied to wrong folder 324 policy configuration errors 324 policy disabled 324 policy enabled at wrong level 324 policy enforcement problems 324 policy should be recipient (or sender) 325 queue backups 327 recipient versus sender policies 325 SMTP Relay identification errors 77 SMTP Relay policy enforcement not enabled 326 SMTP Relay service 76 SMTP Relay service is stopped 326 virus pattern needs updating 326 virus scan engine needs updating 326 troubleshooting policy enforcement 324 troubleshooting TLS 80 troubleshooting update failures 354 trust according to certificate status 412 direct 412 trusted root keys and CRLs 420 trusting self-signed certificates 412
Tumbleweed contact information xxviii tutorials action, severity of 235 policy enforcement 235 Types of Reports 616
U Unable to Encrypt and Sign to SPN Domain policy 372 Understanding Policy Inheritance and Overrides 237 unencrypted message filter policies, troubleshooting
527 Unencrypted Message Filter policy 385 unencrypted message filter policy, creating 525 uninfected messages, clean stamp 217 UNIX regular expressions 683 unmapped characters, how handled 670 updates and database tables 352 database tables affected 351 download file format 351 failure due to MMSConfigData filegroup size 355 failure due to transaction log size 355 frequency 351 manually checking for 353 purpose 351 troubleshooting 354 updating local certificates 497, 519 user certificates automatic lookup 381 user records and automatic certificate association, policy explained 382 creating for proxy security 494, 516 in proxy security 494, 516 objects in directory 220 overview 222 User Reports 627 users importing 532 records for 220 using 303 using folders 221 UUencode to MIME, policy conversion 216
V verifying authenticity of a certificate 495 virus- and file-stripping policies 303 Virus Detected for Specific Sender 628 Virus Hoax Block policy 247 virus pattern file 80 virus pattern files enabling updates 83 Virus Policy Types, overview 217 virus scan engine 80 Virus Type and Volume 619 viruses and file attachment stripping 215 defining policies for new viruses 305 Melissa 305 new, defining policies for 305 text filtering policies to protect against 305 virus-stripping policies, using 303 virus-stripping policies, using 303 Volume Reports 616
W weighted word list, format required 260 weighted word lists and Advanced Add 260 construction 260 wildcards caution using in address lists 266 caution using in attachment lists 270 caution using in word lists 260 in SMTP Relay best match algorithm 66 using in address lists 266 using in attachment lists 270 using in word lists 259 Windows Bitmap (BMP) 653 Word Lists HIPAA lexicon 252
719
word lists advanced add 263 creating 263 defined 258 how data is stored 666 regular expressions and illegal formatting 685 using multiple lists 260 using negative word weights 261 weighted, construction 260 weighted, format required 260 weighted, using Advanced Add 260 wildcards 259 wildcards caution 260 wordlist compilation error 685 word separators, limitations on handling non-English text 667 WordPerfect 653
X X.509 certificates 367 X-headers applying policies to directory 319 confidence 340 content 340 creating a policy using 315 using in policies 316 X-headers, adding to messages 315
720
