Vous êtes sur la page 1sur 748

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 Intended Audience .......................................................................................... 2


1.2 Overview of Email Firewall 6.2 ..................................................................... 3
1.3 Other Documentation ..................................................................................... 4

Chapter 2 Setting Up Email Firewall Administration 7

2.1 Overview of Administrator Setup Tasks ........................................................ 8


2.2 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
2.3 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
2.4 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
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
2.5 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

iv Contents
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
2.6 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
2.7 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
2.8 Setting Up Event Logging .......................................................................... 100
2.8.1 Setting Up Event Logging .............................................................. 101

Contents v
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
2.9 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

Chapter 3 Working With Queues 113

3.1 Message Queues Status ..............................................................................114


3.2 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
3.3 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
3.4 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
3.5 Quarantine Queue Management .................................................................133
3.5.1 Setting Up a Model Spam Review Process .....................................134

vi Contents
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 185

4.1 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
4.2 Searching the Event Log ............................................................................190
4.3 Using Event Log Filters ..............................................................................192
4.3.1 Creating Event Log Filters ..............................................................192
4.3.2 Creating Custom Events .................................................................194
4.4 Searching for Message Events ....................................................................199

Chapter 5 Understanding Policies 203

5.1 Policy Overview .........................................................................................204


5.1.1 Definitions .......................................................................................204
Policy .........................................................................................204
Rules ..........................................................................................204
Actions ......................................................................................204

viii Contents
5.1.2 Example .......................................................................................... 205
Name ......................................................................................... 206
Catch Conditions ....................................................................... 206
Exclude Conditions ................................................................... 207
Actions ...................................................................................... 208
Backup Actions ......................................................................... 209
Summary ................................................................................... 209
5.2 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
5.3 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
5.4 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.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
5.5 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
5.6 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
5.7 Policy Building Tools .................................................................................253

x Contents
Chapter 6 Creating and Editing Policies 255

6.1 Introduction to Policy Building .................................................................. 256


6.1.1 Using Multiple Policy Actions ....................................................... 256
6.2 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
6.3 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 329

7.1 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
7.2 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
7.3 Dynamic Anti-Spam Service Architecture ................................................. 334
7.3.1 Mail Flow with the Dynamic Anti-spam Service ........................... 334
7.4 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
7.5 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 Introduction to Email Encryption and Authentication in EMF .................. 364


8.2 S/MIME and OpenPGP Overview ............................................................. 365
8.2.1 Email Firewall and S/MIME .......................................................... 366
8.2.2 Email Firewall and OpenPGP ......................................................... 368
8.3 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
8.4 Email Firewall Security using TLS ............................................................ 373
TLS Certificate Requirements .................................................. 374
8.5 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
8.6 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 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
8.8 Understanding Certificate Harvesting ........................................................394
8.8.1 S/MIME Certificate Harvesting ......................................................394
8.8.2 OpenPGP Key Harvesting ..............................................................394
8.9 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
8.10 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
8.11 Third Party PGP Keys and Email Firewall .................................................400
8.12 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
8.13 The PGP Trust Model .................................................................................408
8.14 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

xvi Contents
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 429

9.1 Setting Up Email Firewall Security ........................................................... 430


9.1.1 Email Firewall Security Prerequisites ............................................ 431
9.1.2 Using the Email Firewall Security Setup ........................................ 432
9.2 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.2.6 Obtaining Certificate Authority Root Certificates ..........................440
Obtaining Entrust Root Certificates ..........................................441
Obtaining Verisign Root Certificates ........................................441
9.3 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
9.4 Setting Up Certificates for TLS ..................................................................445
9.4.1 Creating a TLS Message Exchange Policy .....................................448
9.5 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
9.6 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
9.7 Setting Up for SMG Mode .........................................................................471
9.7.1 Set Up Differences in SMG Mode ..................................................471
9.8 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

xviii Contents
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.4.2 Notifications ....................................................................................672
B.4.3 Events ..............................................................................................672
B.4.4 Subject Alteration ...........................................................................673
B.4.5 MIME Header Field Policies ..........................................................673
B.5 International Text Usage ............................................................................674
Japanese Character Issues .........................................................675
B.6 Message Body and Attachments ................................................................677
B.7 Message Subject .........................................................................................678
B.8 ISO Tables ..................................................................................................679

Appendix C 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 693

D.1 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 cross-


reference.

Command The Courier New font indicates application


code or computer generated text.

<locale> Angle brackets indicate a user-specified com-


mand 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 proce-
dure.

The Note icon signals additional relevant


information.

The Warning icon signals important informa-


tion 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 support@tumbleweed.com

Global Support Helpline 650-216-2109

Global Support Request http://www.tumbleweed.com/dy/sup-


Form port/request/request_support.php

Customer Service, cust.services@tumbleweed.com


License Keys and Ship-
ping 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

Type of Contact Description

World Wide Web Visit the Tumbleweed Web site for general informa-
tion and current issues.
http://www.tumbleweed.com

Email Address Send email to the following address:


info@tumbleweed.com

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

xxviii Preface
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 Intended Audience ...................................................................... 2
1.2 Overview of Email Firewall 6.2 ................................................. 3
1.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:
• 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.

4 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
Setting Up Email Firewall
2 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 Overview of Administrator Setup Tasks...................................... 8
2.2 Administrative Security............................................................... 9
2.3 System Status ............................................................................ 14
2.4 Setting Up Admin Roles and Accounts ..................................... 21
2.5 Setting Up Relays ..................................................................... 32
2.6 Setting Up Anti-virus and Anti-spam........................................ 80
2.7 Setting Up Global Policy Settings ............................................ 87
2.8 Setting Up Event Logging....................................................... 100
2.9 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 Task Description and Procedures

1 Create additional administra- 2.4 Setting Up Admin Roles and Accounts on page 21
tors

2 (Optional) Set up Centralized 2.8.2 Setting Up Centralized Event Logging and Report-
Event Logging and Reporting ing 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 3.7 Using Personal Quarantine Manager on page 142
Manager

8 Set up the Dynamic Anti-spam 7.2 Dynamic Anti-spam Service Overview on page 332
Service

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

8 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 recom-


mended):
https://<machine name>/emfadmin

To login to Email Firewall on a non-secure server:


http://<machine name>/emfadmin

Setting Up Secure Login

To setup Web Admin so that SSL (https) is required:


1. Right-click My Computer and Select Manage.
2. Click Services and Applications and expand it.

10 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 sec-
tions of this guide for more detailed infor-
mation.

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
Alerts, Message Queues and Email Firewall Services tabs. A review of the
information on these tabs alerts you to the current Email Firewall operating
status.
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.
• 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.

16 Chapter 2: Setting Up Email Firewall Administration


• 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.

2.3.2 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:


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.

28 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:
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.

2.5 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 Relay Settings Configuration ................................................... 33
2.5.2 Global Relay Settings............................................................... 34
2.5.3 Limit Settings ........................................................................... 36
2.5.4 Identity Settings........................................................................ 38
2.5.5 Specifying the DNS Servers ..................................................... 41
2.5.7 Exceptions to Mail Delivery..................................................... 43
2.5.8 Miscellaneous Relay Settings ................................................... 45
2.5.9 Network Connections Concepts ............................................... 49
2.5.10 Domain-Based Authentication Protocols ................................. 51
2.5.11 Setting Up Network Connections ............................................. 54
2.5.12 Mail Routing Rules Overview .................................................. 57
2.5.13 Setting Up Mail Routing Rules ................................................ 60
2.5.14 Address Rewriting Concepts .................................................... 67
2.5.15 Setting Up Address Rewriting .................................................. 71

32 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
Connections checkbox.
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):
1. Unmark the checkbox beside the Route messages... option.
2. Click Save to commit the changes.

2.5.3 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.

• 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.

36 Chapter 2: Setting Up Email Firewall Administration


• Setting
Delay Closing Outbound Connection for X seconds after last send:
the outbound connection delay allows an existing connection to be reused
if more outbound mail arrives for that host.

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:
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.

2.5.4 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. Type the new server IP Address in the DNS Server IP Address field and
click Add.
2. Verify the new server address appears at the bottom of the DNS Server IP
Address column.

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 <user@example.com>. But
sometimes, a client may send a message to a recipient like <user> 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.
• 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

46 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 process-
ing, 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 Network or remote host is


have failed down

The remote server is temporarily refusing to Error response to MAIL


accept 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 Error response to HELO or


accept connections EHLO command

The remote server is temporarily refusing to Error response to RCPT


accept mail for the recipient command

The remote server is temporarily unable to Error response to DATA


accept this message 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 reverse-
DNS 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-draft-
20040209.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 end-
ing 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 mes-
sages 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:


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.

56 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 dis-
allow 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
• the routing rule when routing to an explicit relay host.
• the DNS when using an MX lookup.

58 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-exter-
nal 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. 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.

60 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 mike@example.com. 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 asso-
ciated 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 spe-
cific 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 Authen-
tication Required. With this option, the mail from/to domains and
the domain certificate are not compared and the result of the vali-
dation 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
user@mydomain.com will match the first rule, while an email address like
user@host.mydomain.com 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 <user@host.domain.com>, it will
search for a matching rule in the following order:
1. user@host.domain.com
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:


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.

66 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
user@example.com. 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
joe@foo.com. Specifier 8 would be the best mach for jane@biz.org.

Using this same list of match specifiers, consider the address user@foo.com.
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 <null>

*@example.com %1@widget.com <null>

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

user@host.example.com user@host.widget.com

joe@example.com joe@widget.com

jane@a.b.c.example.com jane@a.b.c.widget.com

ralph@foo.com ralph@foo.com

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.
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.

70 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 %1@xyz.com XYZ Mailbox

Start *@abc.com %1@xyz.com XYZ Mailbox

Start *@*.xyz.com %1@xyz.com XYZ Mailbox

Start *@xyz.com <null> XYZ Mailbox

XYZ Mailbox *_*@xyz.com %1.%2@xyz.com <null>

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. Verify the new rule appears in the Rule Name column and that the type of
rule is correct. See Figure 2.16.

72 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:


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.

74 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
downloads, use the text field and drop-down list to select Hours,
Days, Weeks or Minutes.
4b. Optionally, mark the Check for extra pattern files checkbox to
check for extra pattern files.
4c. If the FTP server should use passive mode, mark the Use Passive
Mode checkbox.
4d. To manually start an update, click Update Pattern File Now.
4e. 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
Filter Nowto start an update.

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 Anti-
Spam 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 X-
headers, 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.
• 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.

86 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 off-
peak 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. Click Save.

2.7.3 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 non-
text 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, mark the Scan all bytes of non-text attachments for text
strings checkbox.
4. Click Save.

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:


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.

96 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 Pol-
icy-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:


1. In the domain’s row, click Edit and make any changes.
2. Click Save.

98 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
Ahas a PBR policy which routes messages to machine B. Assume further that
machine B has a Redirect policy:
• 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
Event Logging and Reporting tab. See the section Enabling and Setting Up
Centralized Event Logging and Reporting below for more information on this
setup.

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.
5. Mark the Enable network DTC access checkbox.
6. Click Next.
7. Click Finish.

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.
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.

104 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 security-
related 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 multi-
dimensional 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
Proxy Server checkbox, and then enter your user name and password.
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 Message Queues Status .......................................................... 114
3.2 Setting Up Message Queues ................................................... 116
3.3 Setting Up Queue Searches .................................................... 126
3.4 Working With Messages in the Queues................................... 131
3.5 Quarantine Queue Management............................................. 133
3.6 Troubleshooting Inbound and Outbound Queues ................... 138
3.7 Using Personal Quarantine Manager .................................... 142
3.8 PQM Reports Sent to Users ................................................... 161
3.9 Using Policies with PQM ....................................................... 171
3.10 Personal Quarantine Manager Maintenance ......................... 175
3.11 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
• Outbound
• Spam Analysis
• Detention
• Retry
• Defer
• Redirect
• Secure Messenger
• Dead Letter
• Quarantine (Default 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 nonse-
cure messages. These messages are set aside for the mail adminis-
trator 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 administra-
tor, 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 requir-
ing 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 deliv-
ery 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 admin-
istrator. 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 redi-
rected 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 dur-
ing 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 Ser-
vice, 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 Ser-
vice 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. (Mes-
sages bypass the Spam Analysis queue if the Dynamic Anti-spam Ser-
vice 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 mes-
sages 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 rout-
ing 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
Now to manually reset the actions.

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.
Aging 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.

Figure 3.3: Queue Setup Aging

To set up Quarantine and Dead Letter queue aging actions:


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.

122 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. Click Save.

3.2.4 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:


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.

124 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:
• Queue Search 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.

3.3.1 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.
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.

128 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:


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.

3.3.4 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:
• The Message Text tab shows the message content.

132 Chapter 3: Working With Queues


• 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.

3.5 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 white-
listing 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 Anti-
Spam 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 pos-
itives.
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.

3.5.2 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 non-
responding 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:


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.

136 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:


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.

3.5.5 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
Undeliverable. 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.
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/delivery-
status 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.
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.

140 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 policy-
based 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:

• Server Settings
• Users

146 Chapter 3: Working With Queues


• Access Restrictions
• Notifications

3.7.3 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://<host>/MMSpqm?healthcheck where <host> 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:


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.

3.7.5 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. On the Notification Options tab, Notification Format heading, mark the Text-
based email radio button to send QSN messages in plain text. Using this

152 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 On-
demand 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. Click Save.

154 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:


1. In the left menu, click Setup > Personal Quarantine Manager Access
Restrictions.
2. To allow access to ALL messages EXCEPT those specifically excluded:

158 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
access only to messages with specified include tags.
3b. In the Include table, click Add to open the Select Tags pop-up
page.
3c. 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.
3d. 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.
3e. 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 On-
demand 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:<msg subject> Sender: <msg 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:
<address>.

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
Internal folder.

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
access...heading, mark the ONLY their quarantined messages tagged...
radio button.
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.,
everybody@mycompany.com) 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 Setting Up Email Firewall Event Logging ............................. 186
4.2 Searching the Event Log......................................................... 190
4.3 Using Event Log Filters ......................................................... 192
4.4 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:
• 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.

4.1.2 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 - Most events and high level message processing.


3. Trace - All message processing steps and actions taken.
4. Debug - 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:


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.

188 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:


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.

4.1.5 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


Search to view the default set of filtered events. Figure 4.1 shows a sample
Event Log search results page.

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 rela-
tively 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.
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.

4.3.2 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. 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.

196 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
Policy-based Routing 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.
This chapter contains the following sections:
5.1 Policy Overview...................................................................... 204
5.2 Policy Categories and Types .................................................. 210
5.3 Email Firewall Directory........................................................ 220
5.4 How Email Firewall Applies Policies .................................... 233
5.5 General Policy Planning Considerations ............................... 240
5.6 Default Policies and Folders.................................................. 245
5.7 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:
• 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

204 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:


• 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.

212 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 client-
to-client security policies, see:
• 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

5.2.6 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)

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

5.3 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:


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.

228 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
User@LocalDomain.Domain. 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:
• 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

234 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:
• 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.

5.4.2 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. 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.

5.4.5 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

How Users Are Exempted From What Happens If There Are Multiple
Type Of Policy Defined
The Policy Recipients On The Message?

Sender- or recipient - Modify the policy to exclude If the message is sent to any address
based policy to drop, messages where the message on the exempted user list, all recipi-
return, quarantine or is sent to exempted recipients, ents will receive the message
detain the message. who are listed on an address (including the non-exempted recipi-
list. ents.)

Sender-based policy to Make sure that the policy is not If the message is sent to at least one
drop, return, quarantine, applied to the exempted recipi- non-exempted recipient, no recipi-
or detain the message. ents in the Email Firewall direc- ents will receive the message
tory. (because the sender’s disposition is
more severe than the recipients’.)

Recipient-based policy Make sure that the policy is not If the message is sent to exempted
to drop, return, quaran- applied to the exempted recipi- users and non-exempted users, the
tine, or detain the mes- ents in the Email Firewall direc- message is partitioned so that the
sage. tory. exempted recipients get the mes-
sage, but the others do not.

5.5.5 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:
• 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.

244 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-to-
external 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 Introduction to Policy Building .............................................. 256
6.2 Lists and Tags ......................................................................... 257
6.3 Annotations ............................................................................. 278
6.4 Notifications ........................................................................... 287
6.5 Using Events as Policy Actions .............................................. 295
6.6 Creating Policies .................................................................... 296
6.7 Applying the Policy to a Directory Object ............................. 301
6.8 Using Virus- and File-Stripping Policies ............................... 303
6.9 Policy Protection Against New Viruses .................................. 305
6.10 Using Headers Type Policies.................................................. 313
6.11 Using DAS Message Properties.............................................. 315
6.12 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:


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.

256 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 Cautions on Using Text Wildcards in Lists ............................ 258
6.2.2 Word Lists ............................................................................... 258
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
6.2.6 Address Lists........................................................................... 265
6.2.7 Creating an Address List Example ......................................... 266
6.2.10 Exporting Lists ....................................................................... 273
6.2.8 Attachment Lists ..................................................................... 268
6.2.9 Creating an Attachment List Example.................................... 271
6.2.11 Tags......................................................................................... 274
6.2.12 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.
• 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.

6.2.2 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:
• 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.

258 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 *<expression>*. Testing shows that up to
fourteen *<expression>* 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"
• 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.

262 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:


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.

264 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. In the left menu, click Attachments to open the Attachment Lists page.
2. In the Attachment Lists page, Attachment List column, type Company
Spreadsheet in the field as the name of the new attachment list.

6.2 Lists and Tags 271


3. Click Create to open the Attachments > Edit Attachment List page.
4. 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

8. Click Save.
9. Verify the new “Company Spreadsheets” list appears in the Attachment
Lists page.

272 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

Placeholder Will Be Replaced With

$SERVER The server name

$DATE The date and time the message was processed

280 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

$REASON The reason the policy fired

$MESSAGE_ID The ID of the message

6.3.3 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:
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.

282 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.
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.

284 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 Epi-
log 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
foldertab.

Test the New Policy

To test the policy:


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.

286 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.

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.

290 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 noti-
fication

$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:
• sender name
• sender email address
• subject

292 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:


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.

298 Chapter 6: Creating and Editing Policies


7. Under the Message Contains Words heading, mark the Subject or Body
containscheckbox.

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 <directory object> 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.
6. Verify the new policy shows on the Policies on this <directory object> 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.

302 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:
• 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

6.8.1 How Virus-Stripping Policies Work


The default (and recommended) behavior of the Infected Message virus-
stripping 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 <user name>.” 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 <your name>.
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
<SCRIPT> 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 <SCRIPT> 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 Anti-
Virus 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 X-
headers 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-Spam-
Content header, the message disposition is to pass the message to the recipient,
even though the message also contains a spam property and X-MMS-Spam-
Confidence 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:
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.

320 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-Spam-
Confidence 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 quaran-
tine 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 Anti-
spam 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 Zoo@anteaters.com. Also blocked is
Boston.Zoo@anteaters.com.
• List contains climber@mountain.com. Also blocked is Hard.Core-
Climber@mountain.com.
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 Introduction to Stopping Spam ............................................... 330
7.2 Dynamic Anti-spam Service Overview ................................... 332
7.3 Dynamic Anti-Spam Service Architecture............................... 334
7.4 How the Engine Processes Messages ..................................... 337
7.5 Message Categorization ......................................................... 340
7.6 Dynamic Anti-spam Service Administration........................... 343
7.7 Dynamic Anti-spam Filter Downloads ................................... 351
7.8 Download Service Maintenance ............................................. 353
7.9 The Tumbleweed Message Protection Lab ............................. 355
7.10 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 anti-
spam 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 anti-
spam 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 multi-
dimensional 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 Anti-
spam 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:
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.

334 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
Email Firewall Engine
Web Admin
4

Email
Firewall
Spam
Analysis
3 Engine
Email SQL Server Database Service
Firewall Message Queues
5
SMTP
Relay Email
Service 2 Firewall
Archive
Service

6 1 Secure
Redirect
Secure
Response
Services

Internet Download
SMTP Email Service
FTP Server

336 Chapter 7: Dynamic Anti-Spam 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 Firewall-
specific 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 industry-
specific 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 X-
headers 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 X-
headers, 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 Anti-
spam 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 self-
monitoring. 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:
• 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.

350 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 Anti-
virus 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:


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.

7.8.5 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 false-
positive 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
spamlab.miss@tumbleweed.com. 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 spamlab.miss@tumbleweed.com.
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 spamlab.miss@tumbleweed.com. 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”
4. Create a user record in the External folder of your Email Firewall directory
for the address spamlab.miss@tumbleweed.com.
5. Apply the policy directly to this user record.

358 Chapter 7: Dynamic Anti-Spam Service


Submitting False Positives
Messages that are incorrectly marked as spam or other categorization errors
should be forwarded to spamlab.fp@tumbleweed.com. 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
spamlab.fp@tumbleweed.com 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
spamlab.fp@tumbleweed.com.

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
Comments
Identification Tool

Address Lists 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 filter-


ing engines is to bury content below the surface of the
HTML. The HTML presented in the email appears inno-
cent, 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 adminis-
trative overhead approach to handling spam.

Spam Analysis Ability to categorize potential spam messages as “adult


Engine spam” (i.e. pornographic and other clearly offensive
material), “high spam,” and “moderate spam” (i.e. mar-
keting newsletters). This capability allows you to setup
different actions based on the classification of the mes-
sage.

360 Chapter 7: Dynamic Anti-Spam Service


Table 7.1: Anti-spam Detection and Defense Tools (Continued)

Spam
Comments
Identification Tool

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 Expres- Related to Lexicons and Lexical analysis, a powerful


sion Engine regular expression engine gives you an additional layer
that is proactive at blocking Spam. An example of a sim-
ple 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 tac-
tic so words/messages are not recognized by scanners.

Relay and Server Attack detection and blocking capabilities are needed
Protection Heuris- both at the relay and server level to prevent Denial of
tics Service attacks, email born threats, and Directory Har-
vesting (DH) attacks.

Reporting and Detailed reports that show volume characteristics,


Auditing 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 Combining the Exact Match Lexical Analysis with Vari-
Lexical Analysis able 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
Comments
Identification Tool

End-User Empow- In addition to applying extensive gateway-based heuris-


erment tics 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 mes-
sage-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.

362 Chapter 7: Dynamic Anti-Spam Service


,

Email Encryption and


8 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 Introduction to Email Encryption and Authentication in EMF364
8.2 S/MIME and OpenPGP Overview .......................................... 365
8.3 Email Firewall Gateway-to-Gateway Security ....................... 369
8.4 Email Firewall Security using TLS......................................... 373
8.5 Email Firewall Server-to-Client Proxy Security..................... 375
8.6 Email Firewall Client-to-Client Security................................ 385
8.7 The Sender Signature Policy Type.......................................... 391
8.8 Understanding Certificate Harvesting.................................... 394
8.9 Understanding Certificate and PGP Key Responders............ 395
8.10 Third-Party Certificates and Email Firewall ......................... 397
8.11 Third Party PGP Keys and Email Firewall ........................... 400
8.12 Understanding Certificate Rollovers ...................................... 401
8.13 The PGP Trust Model............................................................. 408

363
8.14 Trust and Interoperability of S/MIME Certificates ................ 408
8.15 Frequently Asked Questions ................................................... 422
8.16 Commonly Used Security Terms ............................................ 424

8.1 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:
• 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.

364 Chapter 8: Email Encryption and Authentication Overview


• 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.

8.2 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

Mandatory Features S/MIME v3 OpenPGP

Message format Binary, based on CMS Binary, based on previ-


ous PGP

Certificate format Binary, based on Binary, based on previ-


X.509v3 ous PGP

Symmetric encryption AES AES


algorithm DES BLOWFISH
TripleDES (DES EDE3 CAST5
CBC) IDEA
RC2 TripleDES (DES EDE3
Eccentric CFB)
TWO FISH

Signature algorithm Diffie-Hellman (X9.42) ElGamal with DSS


with DSS

Hash algorithm SHA-1 SHA-1

MIME encapsulation of Choice of multi- multipart/signed with


signed data part/signed or CMS ASCII armor
format

MIME encapsulation of application/pkcs7- multipart/encrypted


encrypted data mime

8.2.1 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


8.3 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 gateway-
to-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
Tumbleweed Email Firewall
Email Firewall Server
Server

Email Client Email Client


0122

8.3 Email Firewall Gateway-to-Gateway Security 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
Tumbleweed Email Firewall
Email Firewall Server
Server

Email Client Email Client

0122
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

• 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

8.5.1 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:
• 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.)

378 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:
• 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.

380 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-to-


client 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 auto-
association 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-the-
middle 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:
• 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

386 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
secure-server@domainname.com) 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: <roel@tmwd.com> and the
message is encrypted using <roel@tmwd.com> certificate).
2. Message is routed through Email Firewall. Email Firewall cannot decrypt
the message so it is processed normally to <roel@tmwd.com> 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 <roel@tmwd.com> 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 security-


stripping 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 virus-
stripping 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 recipient-
based 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
Trusted according to certificate status,
the Policy Engine validates the signing
certificate for:
• 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@<EMF domain>, 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@<email_domain_name>.
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-key-
query@<email_domain_name>. 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 cert-
query@<domain_name>.com but it is signed using the corresponding local
secure domain's proxy signing certificate
(secure-server@<domain_name>.com).

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 cert-


query, 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-key-
query@<email_domain_name>. 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 third-
party 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 plain-
text 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
<secure-server@<domain_name> where domain_name represents the
domain name that is configured as the local secure domain and so is the
domain name that the certificate will represent.See 8.3.1 Understanding
Local Secure Domains on page 370. Since the certificate issued by
VeriSign for a secure web server will not contain the email address, it
cannot be used when Client-to-Client security policies are enabled. In this
case, the certificates issued by VeriSign for users can be used as the Email
Firewall Server Certificate.

The Email Firewall Server Certificate used to encrypt to the


Email Firewall Server (required when using the Client-to-
Client plain text access policy) can be different from the
Server certificate that Email Firewall uses for the SPN. Email
Firewall can decrypt a message as long as the private key
corresponding to the certificate used to encrypt the message
is in the Email Firewall database.

398 Chapter 8: Email Encryption and Authentication Overview


• The use of third party certificates as a Proxy Signing Certificate is not
supported when using the proxy security feature. This means that third
party certificates cannot be used by Email Firewall to issue proxy
certificates.
• When using the SPN feature for a particular local secure domain, the
domain certificate should be configured as both the SPN Signing Certificate
and the Proxy Signing Certificate, even if the proxy security feature is not
used for the domain.
• The CN (Common Name) attribute is displayed by the Web
Administration UI in the list of certificates. For this reason, the CN
attribute should identify the certificate with a descriptive name.
A number of VeriSign root keys are included with the Email Firewall product.
These can be viewed on the Set Up > 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@<domain>.
In an Email Firewall SPN certificate, the email address in the
subjectAltName is Secure-Server@<domain>.
• 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 Fire-
wall 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 auto-
matically 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 Third-
Party 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:
• S/MIME Operations 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-to-
client 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 looked-
up 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.

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 self-
signed. 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., <secure-server@domain.com>.
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
secure-server@company.com
• Proxy Certificate for a user named Casey Mann
CN (Common Name) Company Inc. Secure Server (proxy) (EA) Email
Address casey.mann@company.com
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.
• 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

416 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 <http://crl.verisign.com>.
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:
• 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)

420 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 server-
to-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 Setting Up Email Firewall Security........................................ 430
9.2 Setting Up Key Pairs and Certificates for S/MIME ............... 433
9.3 Setting Up PGP Keys ............................................................. 442
9.4 Setting Up Certificates for TLS .............................................. 445
9.5 Setting Up for Sender Signature Policies............................... 451
9.6 Setting Up a Secure Public Network ...................................... 458
9.7 Setting Up for SMG Mode...................................................... 471
9.8 Setting Up S/MIME Proxy Security ........................................ 474
9.9 Rolling Over S/MIME Certificates ......................................... 497
9.10 Downloading Certificate Revocation Lists ............................. 500
9.11 Specifying the CRL DP LDAP Lookup................................... 503

429
9.12 Setting Up OpenPGP Proxy Security..................................... 504
9.13 Rolling Over OpenPGP Proxy Domain Keys ........................ 519
9.14 Setting Up S/MIME and OpenPGP Client-to-Client Security 521

9.1 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:
• 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.

430 Chapter 9: Security Configuration


• 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.

9.1.1 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

Characteristics SPN SMG TLS

Interoperable with many other Some Yes Yes


vendors’ products

Content encrypted for mes- Yes Yes Yes


sages on the wire

SMTP envelope encrypted for No No Yes


messages on the wire

Content encrypted when mes- Yes Yes No


sage is stored on an intermedi-
ate server

Guarantees message integrity Yes Yes, digital No


between domains signatures are
applied

9.1.2 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:
• 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.

432 Chapter 9: Security Configuration


• Local Certificates - Generate, view, export and remove local S/MIME
certificates.
• 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.

9.2 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 pop-
up.
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. Verify that the new certificate appears in the Local Certificates tab.

434 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 cer-
tificates, 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:
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.

9.2.3 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. 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.
1. Mark the Enable Certificate Responder checkbox.
2. If this feature will be used for proxy certificates, mark the Enable Proxy
Certificate Usage checkbox also.
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: cert-
query@<email_domain_name>. 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
Certificatestab. 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 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 secure-
server@<domain_name>, 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 <secure-server@domain_name> 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/cgi-
bin/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/cgi-
bin/clearsales_cgi/leadgen.htm?form_id=3003&toc=w28860083553003000&ra=6
5.205.251.51&email=
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.

9.2.5 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:
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.

9.2.6 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
Roots, the intermediate CA certificates, if any, must be imported into Email
Firewall as S/MIME Certificates.

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@<email_domain_name> 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 key-
pair, 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. Follow the procedure in 10.6 Using the PrivateKeyWizard Tool on page


568 to complete the import.

9.4 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 keyEncipher-
ment bits set in the keyUsage extension in order for the certificate to be
used as both a TLS client and server certificate. The recommended prac-
tice for X.509v3 certificates used as a TLS certificate is that the fully qual-
ified 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. 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.

446 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:
• 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.

448 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 charac-
teristics:
• 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 Certifi-
cate”. 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
certificate.
2c. Click Export. Click Next.
2d. Select the option to export the private key.
2e. Select Personal Information Exchange. Click Next.
2f. Type a password two times to protect the PKCS#12 file.
2g. Record the password for later use; store in secure location.
2h. Type a file name for the PKCS#12 file.
2i. Click Finish.
3. 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 Fire-
wall 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 certifi-
cates. 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 pol-
icy 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 Sig-
nature 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 Sig-
nature 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 cer-
tificate 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) mes-
sage 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 Fire-
wall 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 opaque-
signing 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 fail-
ure 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 signa-
ture 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. 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.

9.5.3 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 con-
sider the Extended Key Usage extension. If that extension is present in a
certificate and it is marked as critical, Email Firewall will treat that certifi-
cate as invalid for S/MIME operations because it contains an unrecognized
critical extension. To work around this issue, either request a new certifi-
cate 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, mean-
ing that no more than one policy of that type can apply to a record in the
Email Firewall directory. “Infected Message” and Sender Signature” poli-
cies 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. Remove the policy temporarily from the parent folder.
2b. Apply the override policies to the sub-entries within the folder.
2c. Reapply the policy to the parent folder.
2d. Return to the sub-entries and disable the inherited folder-level
policy.
3. 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 incor-
rectly 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:
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.

9.6.1 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 certifi-
cate’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:
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.

460 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 Gateway-
compatible 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
message checkbox is marked. When this checkbox is marked, Email
Firewall will automatically respond to incoming SPN link requests with

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.
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.

9.6.4 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:


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.

466 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-SMIME-
VPN: 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:


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.

468 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:


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.

470 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. Interoper-
ability with other vendors’ gateways has
been demonstrated in the field, but not
guaranteed

Email address in the domain-authority@<domain> secure-server@<domain>


subjectAltName of
the certificate

RSA key length 1024-bit Configurable

Symmetric algorithm 3DES Configurable

Digital signature Optional Mandatory


applied

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

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.

472 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 <thisdomain.com> (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 <thisdomain.com>
(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 (<jsnyder@localdomain.com>) and an
external user named Selena Garcia
(<Selena.Garcia@externaldomain.com>). 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 <cert-
query@localdomain.com>.
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 (<jsnyder@localdomain.com>)
and external user Selena Garcia
(<Selena.Garcia@externaldomain.com>).

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 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
9.8.8 Enabling Automatic Certificate Association .......................... 490
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.3 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 <cert-query@localdomain.com>.
The policy notifies the administrator when it detects inbound signed messages
addressed to <cert-query@localdomain.com>. 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 cert-query@localdomain.com 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
Policies page.
4e. 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 Poli-
cies.
4f. In the Directory > Edit folder page, verify the Client Encrypt and
Sign policy now appears in the Policies on this folder tab.
4g. In the Client Encrypt and Sign row, click Lock so that the policy
cannot be disabled at another directory entry level.
4h. 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 cert-query@yourdomain.com.
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 signature-
verified 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:


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.

486 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


External S/MIME Proxy Security 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.

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
selena.garcia@externaldomain.com.
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
jsnyder@localdomain.com.
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: Selena.Garcia@externaldomain.com
To: cert-query@localdomain.com
Subject: jsnyder@localdomain.com
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
Name and the Email Domain, and the Email Domain for the replacement cer-
tificate is fixed.
To avoid confusion, the Organization Name should not be the same Organi-
zation Name that was used for the expiring certificate. Using a serial num-
ber 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. 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.

498 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:


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.

502 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 informa-
tion:
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
(<jsnyder@localdomain.com>) and an external user named Selena Garcia
(<Selena.Garcia@externaldomain.com>). 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 pgp-keys@localdomain.com. 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
(pgp-key-query@localdomain.com) 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 (<jsnyder@localdomain.com>)
and external user Selena Garcia
(<Selena.Garcia@externaldomain.com>).
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
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.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:
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.

506 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 pgp-keys@localdomain.com 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. Create the pgp-keys address list. Add pgp-keys@localdomain.com to the
address list where localdomain is the name of your local domain.
2. 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 pgp-
keys 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 signature-
verified 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:


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.

510 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:


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.

512 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
Directory page.
8b. Click the All and then the External folder.
8c. In the Entry field, type External OpenPGP 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 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:
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.

516 Chapter 9: Security Configuration


5. In the User Properties tab, Public Email Address field, type
selena.garcia@externaldomain.com.
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
jsnyder@localdomain.com.
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
pgp-keys@localdomain.com.
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: Selena.Gracia@externaldomain.com
To: pgp-key-query@localdomain.com
Subject: jsnyder@localdomain.com
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:
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.

518 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 organi-
zation 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 Fire-
wall 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-key-
query@<emaildomainname> with the email address of their internal
correspondent as the email subject. Email Firewall will process this pgp-
key-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 mes-
sage:
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 pgp-
keys@domain.com with subject line of domain.com. Once
you have obtained the S/MIME certificate or PGP key,
you should cc: encrypted messages to
secure-server@domain.com.
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 mes-
sage:
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
Sender 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 must install the attached Email Firewall Public Key
and cc: <secure-server@domain.com> 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. Apply both policies to the appropriate user records or folders.

524 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
Sender radio button.
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
Sender radio button.
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 Email Firewall Directory Tools .............................................. 532
10.2 Setting Up LDAP Directory Imports ...................................... 534
10.3 Performing the LDAP Import ................................................. 552
10.4 Using the Command Line Program Tools .............................. 560
10.5 Using the Word List Tester ..................................................... 564
10.6 Using the PrivateKeyWizard Tool........................................... 568
10.7 Using the Email Firewall Diagnostics Utility ........................ 582
10.8 Using the EMFDebugLogCapture Tool .................................. 590
10.9 Using EMFSave ...................................................................... 592
10.10 Using the Email Firewall Update Service.............................. 602
10.11 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
<http://www.imc.org/rfc2251>. 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
Address 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.
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 Sun ONE Schema Microsoft Exchange


Record Attribute Attribute 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 <domain>\<user> and not CN=<name>, CN=<domain> 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=<organization name>, 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 drop-
down 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 authenti-
cate an MS Exchange Server is represented by CN1=<name> and
CN2=<domain>.
14b.Click Update to commit the data to the session and close the pop-
up 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=<value>
or co=<value> 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=<value> or co=<value>, 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:
• 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

548 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:
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.

550 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. In the Directory > Directory Import page, verify the new schedule appears
on the Scheduled Imports tab.

554 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=<user-id>, ou=<org-unit>, o=<orgainzation>
sn: <last name>
givenname: <first name>
middlename: <middle name>
objectclass: person
mail: <RFC822 address>
cn: <full name>

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: bfree@tumbleweed.com
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. 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.

556 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<file path> -l<LDIF source>
[-s<server> -g<catalog>] [-u<userName> -p<password>

Table 10.2: MMSLDIFImportConfig Tool Parameters

Tool Parameter Description

-f<file path> Specifies the file to be uploaded.

-l<LDIF source> Specifies the configured LDIF source in the LDAP


import data source configuration to be updated with the
specified file

-s<server> Name of the Email Firewall 6.1 SQL Server

-g<catalog> Catalog Name of the Email Firewall Database

-u<userName> User Name used to log in to the Email Firewall Data-


base

-p<password> 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

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

562 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 drop-
down 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:


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.

566 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 data-
base:
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

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.

570 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. Click Next.

572 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


Password fields. See Figure 10.21.
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. After it is selected, in the PKCS 12 dialog, click Next.

576 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 Pri-
vate 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 Certifi-
cates page.

578 Chapter 10: Administrative Tools


The associated private key is also imported. It is encrypted using the Pri-
vate 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

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.

580 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 Pri-
vate 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 key-
pair 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:
• 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.

582 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 pre-
defined 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:
• 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.

584 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:
• 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).

586 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 cap-
tured) 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:
• 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

592 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 non-
replication 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 loca-
tion, be sure there is adequate disk space to save all the database files you
are backing up.

10.9 Using EMFSave 593


In a cluster environment, the location for storing the Email
E
m
Firewall database temporary files must be part of the cluster
a
i
l
resource in order for restore to function properly. See 10.9.5
F
i
r
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, User-
name, Password, EMF Save File location, and Temp Directory location.

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 com-
ponent machines that access this Private Key data.
5. 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.

594 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. If you receive an error message, take specific note of the error message and
your actions preceding the message, and contact Tumbleweed Technical
Support.

600 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
Programs > Tumbleweed Email Firewall > Check for Updates.
2. Click Show Updates to check whether any updates are available. See
Figure 10.41.

602 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. Click Save to save the new Key Name and configuration value.

610 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 Setting Up Email Firewall Reports ........................................ 612
11.2 Volume Reports ....................................................................... 616
11.3 Frequency Reports.................................................................. 624
11.4 User Reports ........................................................................... 627
11.5 Audit Reports .......................................................................... 629
11.6 Customizing Email Firewall Reports...................................... 630
11.7 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
Summary Events 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.
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 Anti-
spam 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:
• Delivered
• Quarantined

618 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/spf-
draft-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.
• 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.

622 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:
• .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

636 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. Click OK to complete the export process.

638 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 General Overview .................................................................... 640
A.2 “All Supported” File Types ..................................................... 645
A.3 Groups...................................................................................... 651
A.4 File Types Recognized ............................................................. 655
A.5 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:
• 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.

640 Appendix A
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 drop-
down 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
• 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

646 Appendix A
• 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


• Help files (the A.3.5 Help Files on page 651 group)

648 Appendix A
• 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
• Enable Spreadsheet
• Lotus 123 (*)
• Microsoft Excel (*)
• Multiplan 4
• Quattro/Quattro Pro (*)
• SuperCalc 5
• Symphony

650 Appendix A
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


• Mac Word 6

652 Appendix A
• 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
• WordPerfect Resource File
• WordPerfect Configuration File, Hyphenation Dictionary
• WordPerfect Miscellaneous File

654 Appendix A
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 Word Processing Formats ........................................................ 659


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

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.
• 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)

660 Appendix A
• 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
• PKZip ZIP archive format

662 Appendix A
B Code Set Support

This appendix provides an overview of how Email Firewall supports text-


scanning policies when the search words and message data use characters
outside of the ASCII-7 character set. Also discussed are the extraction of non-
English 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 Definitions and Concepts .......................................................... 664
B.2 Data In The Email Firewall Database...................................... 666
B.3 Extraction of Text From Message Content................................ 669
B.4 Policy Engine Expected Behaviors ........................................... 671
B.5 International Text Usage ........................................................... 674
B.6 Message Body and Attachments................................................ 677
B.7 Message Subject ........................................................................ 678
B.8 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.iso-
8859-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), Windows-
1252 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 head-
ers 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 Japa-
nese. This could happen, for example, if an English ASCII-7 encoded mes-
sage triggers a policy requiring a notification to be sent, but the
notification text is in Japanese.
5. When a message using an unsupported character set is encountered, Email
Firewall will not add an annotation.

674 Appendix B
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 ASCII-
encoded 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. How-
ever, when Japanese text is entered into an email client application, the cli-
ent 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 par-
ticular 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:
• US ASCII
• ISO 8859-1
• ISO 8859-2
• ISO 8859-3

678 Appendix B
• 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 General Issues ........................................................................ 684
C.2 Operators................................................................................ 686
C.3 Character Class Operators .................................................... 687
C.4 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:
• 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.

684 Appendix C
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 <listname>, 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

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)

686 Appendix C
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
Will match this
Class

. 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) charac-
ters.

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)

Character
Will match this
Class

\* 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

688 Appendix C
Table C.2: Email Firewall Regular Expressions - Character Class (Continued)

Character
Will match this
Class

“c1c2c3” match every character between '’”’ (except escape


sequences which are translated as above)

<<EOF>> 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


This Regular Expression Will Match These Text Samples
Samples

house house thou seeth me


House.
HOUSE
household
doghouses
DogHouse

(house)|(HOUSE) exactly the same as previous exactly the same as previous row
row of this table of this table

house|HOTEL House doghous e


hotel nice hottel
HOTel
houseotel
HOUShotel

hous(e|H)otel houseotel househotel


houshoTEL houseHOTEL

[HOUSE] HOUSE house


HO hotel
US nation

[hH][o][u][s][e] house HOuse


House HOUSE
houses thou seeth me
doghouses DoghousE

!house house doghouse


household

690 Appendix C
Table C.3: Email Firewall Regular Expressions Tutorial Examples (Continued)

But Will Not Match These Text


This Regular Expression Will Match These Text Samples
Samples

!house\W house houses


house. household
house, doghouse

abc* ab acb
abc
abcabc
abccCd
xyzabc

(abc)* any text stream will match this


expression

a(bc)* a bc
ad
abc
abcbc
abcbcd
xyzabc

a(bc)? a ad
abc
abcd
abcbcbcbc
xyzabc

a(bc)?d ad abcbcd
abcd

(abc)+ abc
abcabcd
mabcabc

(abc){2} abcabcxyz abc abcd


abcabcabcabcxyz

ab{2}a abba aba


zabbas ababa
abbba

691
Table C.3: Email Firewall Regular Expressions Tutorial Examples (Continued)

But Will Not Match These Text


This Regular Expression Will Match These Text Samples
Samples

ab{2,}a abba aba


abbba
zabbbbas

ab{2,3}a abba aba abbbba


abbba
zabbbas

\d{3}-\d{4} 555-1212xyz 555 1212


01234-567890

!\d{3}-\d{4} 555-1212xyz 0123-4567


555-121234567 555 1212

!\d{3}(\s|-)\d{4}\s 555-1212 555-12121212


999 0000 999 0000
650-216-2000 tel216-2000
tel:216-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 Creating and Installing a New Report ...................................... 694
D.2 Report Customization Section Selection ................................... 698
D.3 Parameter Field Order in the Report ....................................... 699
D.4 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. 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:

694 Appendix D
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 customiza-


tion section to show. See D.2 Report Cus-
tomization 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 exam-
ple, “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 address lists
advanced add 266
"A" records, searching for 47 creating 265
.rar file detection, limitations 644 defined 265
example 266
A format required 267
wildcards 266
A records 46 wildcards caution 266
accepting SPN links 465 administration overview 7
accounts administrative security 9
setting up administrator accounts 21
administrative tasks, generally 343
actions
administrator accounts
backup actions in policies 209
preferences 31
dispositive actions in policies 208
setting up 21
in policies 208
Adobe 651
in policies, defined 204
informational actions in policies 208 Advanced Add
message action hierarchy 233 attachment lists names and types 270
resetting queue actions 121 character set required 262
setting up quarantine queue aging actions 122 in address lists 266
setting up queue actions 120 in word lists 263
setting up retry intervals 124 using with tags 277
severity of 235 Advanced Add, word lists and regular expressions 260
severity, affects of 235 aging, in quarantine queue 119
transformational actions in policies 208 aging, quarantine queue 122
active content in html, detecting 310 aging, specifying in quarantine queue 122
Active Directory, only Authenticated Account access All folder
540 described 223
adding an alternate DNS server 41 function and policies 246
adding custom X-headers to messages 315 Allow Security Stripping policy 388
adding policies to directory objects 302 alternate host for critical notifications 289
address annotating all outbound mail with a disclaimer,
using as catch or exclude condition 211 example 282

703
annotations automatic lookup of user certificates 381
"Outbound Disclaimer" example 284 auto-responding to SPN link requests 461
clean stamp 217 auto-responding to SPN link requests, steps 463
defined 278
global 279 B
skipping annotation text 281
using placeholders in annotation text 281 Backup Actions, in policies 209
using placeholders in global annotations 280 backups in queues, troubleshooting 327
annotations not skipped 325 Basic Mail Filtering - Outbound Size Deferral 248
anti-spam strategies, generally 329 Basic Policy Types 211
applying policies, general rules 245 BCC recipients, isolating on separate copies of message
Archive, setting up 88 95
ASCII armored key file 400 best match algorithm 66
associating an email address with a certificate 413 best match algorithm and wildcards, for SMTP Relay
associating self-signed certificates 413 66
attachment lists bounce action 62
described 268 bounced notifications, deleting 44
file types 269 browser sessions, using multiple instances 11
wildcards 270 browser settings preferences 32
wildcards caution 270
Attachment Volume and Size 617 C
Attachment Volume for Attachment Type 619
cached CRL DPs 421
Attachment Volume for Specific Recipient 627
Catch Conditions, in policies 206
Attachment Volume for Specific Sender 628
catch conditions, using address 211
attachments
catching mail that is not encrypted but should be 525
detection of infected 217
categorization of spam 340
detection of long file names in 251
Centralized Event Logging and Reporting 101
EXE block policy 250
file-stripping policies, using 303 certificate responder, enabling for proxy security 479
Multimedia Attachments Deferral policy 251 certificate SubjectAltName field, email address in 424
security stripping of 388 certificates
using file stripping policy on 215 associating email address with 413
Attachments Policy Types 215 associating self signed 413
automatic certificate association 382
Attribute Mapping
automatic lookup 381
in LDAP import 536
cached CRL DPs 421
Audit Reports 629 certificate responder 479
Audits, setting logging for 188 CRL checking 500
Authenticated Account access for Active Directory Direct Trust, defined 412
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
dynamic lookup 496 cluster environment EMFSave requirement 594
exchange and verify certificates for proxy code sets and word lists 666
security, example 495, 517 command line program tools 560
exporting 435 Compressed Files 645
exporting certificates and root keys 436 conditions not configured properly 324
generating 433, 442
conditions, using in policies 206
how they become invalid 401
confidence level 340
importing 495
confidence X-headers 341
new, and auto certificate association 383
obtaining CRLs overview 419 configuring
overrides of LDAP lookup certificates 381 a mapping for LDAP Import 548
overriding automatic certificate association 493 a query for LDAP Import 545
overriding automatic certificate lookup 381 a Secure Public Network 458
PrivateKeyWizard, using the tool 438 proxy security, example 474, 504
proxy security and invalid server certificates, SPNs 458
effects 402 Contact Information, Tumbleweed xxviii
proxy security, exporting certificate root key 478 content type 340
proxy, overview 414 content X-header 341
publishing as a root key 436 Convert UUencoded Attachments to MIME Format
removing or renewing 582 216
rolling over invalid or expired certificates 497, copy and restore options, required selections 595
519 copying messages with EMFSave 595
rollover checklist overview 404 Corel Draw 651
rollover of local certificates 497, 519 corrupted filter, removing 353
rollover overview 403 create and manage security 432
self-signed 412
creating a custom header 469
server, use in proxy security 413
creating a new Local Secure Domain, steps 459
third party certificate requirements 398
third-party 398 creating a new policy, example 296
TLS and MX record issues 55 creating a plaintext access policy for recipient 521
Trust According to Certificate Status, defined 412 creating a plaintext access policy for sender 523
trust concepts 412 creating a policy to check for successful SPN 467
updating local certificates 497, 519 creating an Event ID 194
usage in proxy security 479 creating and editing policies, generally 255, 329
verifying authenticity 495 Creating LDIF Files 555
character sets and importing lists 262 creating proxy security policies, examples 480, 507
characters and code sets, defined 664 critical notifications, specifying an alternate host 289
checking for SPN link requests 465 CRL checking 500
checking for SPN link response 465 CRL downloads
Clean Stamp policies 217 specifying the HTTP Proxy Server 502
cleaning up the directory CRL source and download schedule 501
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

705
CRLs deferring message delivery 248, 250
checking order 421 defining Local Secure Domains 458
downloads overview 420 definitions, policy 204
manually downloading 502 delay and non-delivery notifications from SMTP relay
models for obtaining 419 48
overview of scheduling downloads 420 delayed messages, notifying sender 124
precedence of CRLs 421 deleting bounced notifications 44
scheduled downloads and the Download service
deleting quarantined messages 145
420
Delivery Status Notifications (DSNs) 46
trusted root key required 420
denial of service attacks, and SMTP relay settings 37
custom header, creating for SPN policy 469
Detect cert-query policy 482
custom reports 693
Detention queue 116
Customizing Audit Reports 634
digital signatures 495
Customizing Frequency Reports 632
Directory
Customizing Reports 630
default structure 223
Customizing User Reports 633 folders in 223
Customizing Volume Reports 631 importing users 532
objects contained 220
D Directory and Policy Audit 629
Directory and Policy Audit by Administrator 629
data in the EMF database, how stored 666
Directory Audit 629
data sources, in LDAP import 535
Directory Audit by Administrator 630
database
Directory Import
tables affected by updates 351
Active Directory Authenticated Account access
tables updated 352
540
database connection, Quarantine queue and inbound attribute mapping 536
messages 135 cleanup 551
database data, how stored 666 cleanup directory 552
Database Files 645 configuring a query 545, 548
Dead Letter queue 116 internal source identifier 538
decomposition error event ID 6082 670 LDIF files 555
decomposition errors 246 mappings 535
decomposition failures and large embedded files 644 overview 534
decomposition of embedded files, time limitation 644 performing the import 552
preview changes 550, 552
Decompression Errors policy 246
process 550
Default Directory Structure 222
process of events 550
default domain record saving the import log 553
location in External folder 223 scheduling imports 553
using 220 sequence 539
default domain records 221 tools 532
default policies viewing the import log 553
described 245 Directory Import, using Clean Up Directory checkbox
Default Policies and Folders, overview 245 558
default policies, viewing 296 directory object has not inherited a policy 324
default recipient locale, explained 665 directory tool, find user 532
Defer queue 116 Directory Tools 532

706
directory, entries for proxy security 494, 516 E
disabling policies 237
disabling the policy engine 35 Email Firewall Main Menu 12
disclaimers embedded files too large cause decomposition failure
adding to all messages 279 644
annotating all outbound mail, example 282 EMF Administration overview 7
using placeholders in 280 EMF Directory
disclaimers in outbound mail, example procedure 284 objects in 220
dispositions policy inheritance in 324
applying most severe, in policy actions 235 EMF events, when logged as Windows event 198
dispositive actions, in policies 208 EMF service restarts, set to automatic 21
DNS Blackhole Lookups (DNSBLs), specifying 42 EMF Services Status 19
DNS server, adding 41 EMFSave
Document Files 646 saving messages in the queues 595
domain record EMFSave and missing files 601
using 220 EMFSave copy and restore options, required selections
domain records 595
default 221 EMFSave database temporary files, and cluster
location in Internal folder 223 environments 594
overview 221 EMFSave in a cluster environment 601
domains enabling and disabling the policy engine 35
records for 220 enabling policies 237
setting security for, in SPNs 466 encrypted messages
download analysis of 339
events 352 encryption and digital signatures, creating stripping
failures 352 policies 524
files and database tables 352 encryption and signature, policies to monitor message
manual downloads 353 state 528
Download service and CRLs 420 error handling 347
downloading CRLs 501 internal error and message disposition 340
Drawing Files 647 errors, decomposition 246
duplicate notifications, how to prevent 292 errors, decompression 246
Dynamic Anti-spam service Event IDs
manual updates 353 creating 194
performance counters 348 defined 295
Dynamic Anti-spam Update Service using placeholders in 197
maintenance 353
Dynamic Anti-spam Update service
download file format 351
overview 351
purpose 351
dynamic lookup of certificates 496

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 G
File names and file types, understanding in attachment
gateway-to-gateway security 369
lists 271
general rules about applying policies 245
file type lists provided 640
generating a certificate 433, 442
file types
global annotations 279
limitations 644
global policy settings
file types for attachment lists 269 archive 88
file types recognized 655 isolating BCC recipient messages 95
file types scanned 639 limitations in physical file scanning 93
files scanned marking text parts that use unsupported character
compressed files and embedded objects, issues sets 94
643 peak time 87
limitations 642 text scanning options 91
password protection and 649 Groups 651
files types recognized
default lists provided 640 H
file-stripping policies, how they work 304 harvesting
filters S/MIME certificates 394
corrupted filter removal 353 headers
filter version 353 added by the engine 340
troubleshooting update failures 354 message categorization 340
using 192 Headers Type Policies 218
Find user 532 health information, preventing inadvertent sending 252
Find User tool 532 hiding the product name and version number 40
finding policies 296 Hierarchy of Message Actions 233
Folders 221 HIPAA lexicon 252
hoaxes, blocking 247
folders
host name, where used 77
All folder 223, 246
How Severity of Action Affects Policy Enforcement
External folder 223, 248
235
Internal folder 223, 248
HTML Mobile Code, detecting with policies 310
objects in directory 220
html tags, scanning 296
forwarding SPN link requests 464
HTTP Proxy server, specifying for CRL downloads
Frequency Reports 624 502
Frequent Policy Violation 624
Frequent Receiving Domains 624 I
Frequent Recipient Policy Violation 624
Frequent Sender Policy Violation 625 Image Files 648
Imperfect SPN Message Received policy 372
Frequent Sending Domains 625
Import Directory, overview of LDAP Import 534
Frequent Virus Sender 625
Import, performing the LDAP import 552
Frequently Detected Virus 624
importing
full filegroups, increasing size 139 certificates 495
full SQL filegroups, and SMTP relay 76 PGP keys 579
full SQL Server file groups 327 private keys from a PKCS#12 file 574

709
importing LDAP users 532 K
importing lists 262
importing third-party certificates, concepts 397 key pair and certificate, generating 433, 442
importing third-party certificates, using key pairs
PrivateKeyWizard tool 438 determining size 409
importing third-party PGP key pair, concepts 400 private key 408
public key 408
importing user records, limitation 540
inbound mail
how to stop 34 L
stopping 36 large message processing 338
Inbound Mail Characteristics 624, 625
LDAP
Inbound Mail Characteristics report 627 source for certificate lookup 381
Inbound Policy Violations report 628 LDAP Import
Inbound queue Applying Directory Modifications 553
troubleshooting backups 139 Clean Up Directory 551
Inbound queue, stopping the relay from accepting cleaning up the directory 558
messages 119 cleanup directory 552
Inbound Size Deferral policy 250 Currently Requested Directory Modifications tab,
increasing the file size for full filegroups 139 information in 552
Infected Message (Recipient) policy 250 default attribute mapping 536
Infected Message (Sender) policy 250 Import Now 552
Infected Message policy 217 import steps, configuring a query 545, 548
informational actions, in policies 208 internal source identifier 538
inheritance, how policy inheritance works, example LDAP Import Log File tab, information in 553
237 limitation on importing 540
installation overview 534
recovery options set 348 Preview Changes 550
Intended Audience 2 preview changes 552
process 550
internal error, message disposition 340
Saving Log as File 553
Internal Folder 224
scheduling 553
Internal folder
sequence 539
described 223
using 532
function and policies 248
using LDIF files in 555
internal networks
View import log 553
message processing 340
what happens 550
Internal Source Identifier, in mappings 538
LDAP import
Introduction 1 performing the import 552
LDIF files
J attribute filtering 555
Japanese text on word lists, word lists steps in creating 555
Japanese text treatment 667 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

710
lists Message Volume for Specific Sender 628
address lists 265 message/partial MIME type 247
and character sets 262 messages
attachment lists 268 adding internal mail to processing 346
attachment lists file types 269 address as a catch or exclude condition 211
behavior in queue filtering 128 automating spam submittals 357
creating a new tag 275 avoiding loops in policy-based routing 99
double-checking configuration 327 encrypted or SPN 339
importing 262 enhanced content scanning 93
not configured correctly 327 from internal networks, processing 340
overview 256 from Secure Response, processing 338
types of 257 headers added 340
updating 327 how to submit false positives 359
Local MX Hosts configuration 41 how to submit false positives using Web Admin
local secure domain, defining 458 359
Local Secure Domains, overview 370 large message processing 338
locking policies 237 moving from quarantine queue 134
logging events moving from spam queue 345
filters for 192 notification to sender of message delay 124
settings 194 processing by the engine, overview 337
Logging In 10 processing large messages 346
logging level for reports 186 processing time for 348
refused by the Policy Engine 139
Long Filename Quarantine policy 251
stopping inbound messages 138
Lotus 123 652
stuck in the Outbound queue 141
submitting unmarked spam generally 357
M Microsoft DTC, enabling 102
mail Microsoft Excel 652
queues, described 116 Microsoft Network DTC Access, enabling 102
mail routing rules Microsoft PowerPoint 652
setting up exact matching 65 Microsoft PowerPoint with Macros 652
manual CRL downloads 502 Microsoft Word 652
Mappings, in LDAP import 535 mobile code, detecting 310
Mappings, internal source identifier 538 modifying the SMTP Relay Session Welcome and
Melissa virus, quarantining 305 Postmaster information 40
message actions, hierarchy 233 monitoring messages based on their state of security
message backlogs, increasing filegroup size 139 528
message content, how extracted 669 Most Frequent External Receiving Domains 619
message disposition Most Frequent External Receiving Domains report 619
and internal errors 340 Most Frequent External Sending Domains 619
Message Header Fields, list of 219 Most Frequent External Sending Domains report 619
message headers, removing 219 Most Frequent Internal Recipients 617
Message Protection Lab overview 355 Most Frequent Internal Recipients report 617
Message Queues Status 17, 114 Most Frequent Internal Senders 617
message size limit, setting in SMTP Relay 37 Most Frequent Internal Senders report 617
Message Volume and Size 617 Multimedia Attachments Deferral policy 251
Message Volume for Specific Recipient 627 Multimedia Files 648

711
multipart/partial messages, policy to block 247 outbound mail
multipart/signed messages not caught 326 how to stop 34
multiple browser sessions, how to use 11 Outbound Mail Characteristics 627
multiple word lists, cautions 260 Outbound Mail Characteristics report 627
MX record and TLS validation 55 Outbound Message Archival policy 251
MX records 46 Outbound Policy Violations 628
Outbound Policy Violations report 628
N Outbound queue
troubleshooting backups 141
Naming policies 206
Outbound Size Deferral policy 248
negative weights in word lists 261
Overview of anti-spam methods 330
non-English text, issues 667
non-spam, submitting samples generally 356
Non-SPN Message Received From a SPN Domain
P
(Inbound) policy 372 Paradox 653
Normalize Email Addresses in MIME Headers policy Partial Message Block policy 247
219 Partition relay, function 33
notifications
password protected files, and scanning 649
alternate host for critical notifications 289
Password-Protected Files 649
avoiding duplicates 292
Bcc message recipients, and Original Message pattern files 326
Recipients option 291 pattern files updating 326
creating 290 Peak Time, setting up 87
defined 287 performance counters
deleting bounced notifications 44 messages processed 348
double-checking address 327 setting up 349
from the SMTP relay 48 starting and stopping 350
Original Message Recipients, how determined performing the LDAP Import 552
291 Personal Quarantine Manager 142
placeholders 291
PGP
text length 290
trust model 408
using placeholders in 291
PGP key
importing 579
O removal or renewal 582
off-peak hours 248, 250 PGP keys
open relay, preventing 50 default expiration 407
OpenPGP harvesting 394
and Email Firewall 368 rollover 407
ASCII armored key file 400 placeholders
harvesting PGP keys 394 in annotation text 281
PGP Key Responders overview 395 in Event IDs 197
OpenPGP Overview 365 in global annotations 280
OpenPGP overview 368 in notifications 291
OpenPGP proxy security Plaintext Access policies 387
sample procedures 504 plaintext access policy, creating for recipient 521
Other Documentation 4 plaintext access policy, creating for sender 523

712
policies Detect cert-query, for proxy security, example
action, severity of 235 482
actions, types of 208 disabled 324
actions, using 208 disabling 237
adding custom X-headers to messages 315 dispositive actions 208
adding to directory objects 302 editing default policies to scan html tags 296
All folder 246 enforcement of 235
applying to directory objects 319
event log actions 194
applying to internal users, example 301
exclude conditions 207
attachments types, overview 215
backup actions 209 exclude conditions not configured properly 325
basic types, overview 211 External folder 248
building blocks 256, 330 file-stripping, using 303
catch conditions 206 general example 205
catching health information 252 general rules about applying 245
checking actions in 325 HIPAA Compliance 252
checking conditions in 324 how severity of action affects 235
checking exceptions in 325 how to test 320
clean stamp uninfected messages 217 imperfect SPN message received 372
conditions not configured properly 324 infected message 217
conditions, using 206 informational actions 208
configuration errors 324
inheritance 324
creating a custom header for SPN 469
inheritance example 237
creating a new policy example 296
creating with X-headers 315 inheritance, explained 237
default policies 296 Internal folder 248
default, described 245 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 PQM
remove hostnames and subdomains from MIME Quarantine Summary Notifications, see also,
headers 219 QSNs 144
remove MIME headers 219 server health check for administrators 146
security types list 217 PQM Server
should be recipient (or sender) 325 overview 143
similar actions in 325 protocols 143
SPN types 372 Presentation Files 649
summary of 209 preventing non-secure messages from being sent 525
to check for successful SPN 467 preventing policy overrides, example 238
transformational actions 208 Printing and Saving Reports 635
troubleshooting 324 Printing Reports 635
unable to encrypt and sign to SPN domain 372 private keys, size limit 438
using address as catch or exclude condition 211
PrivateKeyWizard tool 397, 400
using Find 296
PrivateKeyWizard tool, using 568
using X-headers in 316
PrivateKeyWizard, using the tool 438
virus-stripping, using 303
processing time for messages 348
Policies Applied to the All Folder 246
Product Updates 109
Policies Applied to the External Folder 248
program tools
Policies Applied to the Internal Folder 248
command line tools 560
Policy Action Events, setting logging for 194
EMF Update Service 602
policy applied to wrong folder 324 EMFSave 592
Policy Audit 629 EMFSave in a cluster environment 601
Policy Audit by Administrator 630 MMSLDIFImportConfig 560
policy building blocks 256, 330 PrivateKeyWizard 568
policy building tools 253 protocol, SMTP over TLS 374
policy definitions 204 proxy certificate usage and certificate responder,
policy disabled 324 enabling 479
policy enabled at wrong directory level 324 proxy certificates 495
Policy Engine use in proxy security 414
enabling and disabling 35 Proxy Decrypt and Verify policy 384
setting logging for 187 Proxy Decrypt and Verify policy, example 484, 510
policy engine proxy decryption, in security 380
and troubleshooting policy enforcement 326 Proxy Encrypt and/or Sign policy 384
Policy example 205 proxy encryption, in security 379
policy inheritance, example 237 proxy security
policy override, example 238 associating email addresses in 413
associating self-signed certificates 413
policy overview 204
checklist for setting up 474, 504
Policy Violation for Specific Recipient 628
Client Encryption and Signature policy example
Policy Violation for Specific Sender 628 480
Policy, defined 204 completing, example 496
policy-based routing creating a folder for user record 494, 516
and infinite message loops 99 creating a user record 494, 517
Postmaster Information, modifying 40 creating user records for 494, 516

714
Detect cert-query policy, example 482 queues
exchange and verify certificates, example 495, configuration 119
517 limitation on search results 126
exporting certificate root key 478 quarantine queue aging 122
invalid server certificates, effect 402 resetting queue actions 121
policy examples 480, 507 retry queue, setting retry intervals 123
proxy certificates in 414 retry queue, setting up retry intervals 124
Proxy Decrypt and Verify policy example 484, setting up quarantine queue aging actions 122
510 setting up queue actions 120
proxy decryption 380 troubleshooting backups 327
proxy encryption 379 Queues, status 17, 114
proxy signature 380
proxy verification 380
sample procedures 474
R
server certificates in 413 random selection 213
proxy signature, in security 380 randomize order of MX hosts 47
proxy verification, in security 380 recipient policies, applying 325
publishing the server certificate as a root key, steps 436 recovery options 348
Redirect queue 116
Q regular expressions 683
QSNs regular expressions, incorrect usage events 685
message content 144 regular expressions, operators and their function 686
message X-header added 145 relay
messages included in 144 stopping the relay from accepting incoming
new, contents of 145 messages 119
recipient access to quarantined messages 145 Relay Host name
reply address displayed 144 specifying a common name 39
Web responses to requests 146 relay messages 77
Quarantine queue relay service host name, where used 77
moving messages 134 relay, adding a DNS server 41
quarantine queue Remove Host Names and Subdomains from MIME
specifying aging parameters 122 Headers policy 219
Quarantine queue, about 116 Remove MIME Headers policy 219
quarantined messages removing or renewing a certificate or PGP key 582
when deleted 145
reports
quarantined messages, recipient access to 145 event logging level required 611
Quattro/Quattro Pro 653 Inbound Mail Characteristics 627
queries, in LDAP import 535 Inbound Policy Violations 628
queue filtering, using lists in 128 logging level required 186
queue, moving messages out of 345 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 certificate rollover overview 403
resetting queue actions 121 Client Encryption and Signature policy example
responding to SPN link requests, steps 463 480
client-to-client 385
restore components missing from backup file 601
client-to-client, setting up 521
Resume Block policy 251
completing the proxy security exchange, example
retry interval, in retry queue 120 496
Retry queue 116 creating a recipient plaintext access policy 521
retry queue creating a sender plaintext access policy 523
notification to sender of message delay 124 Detect cert-query policy, example, for proxy
retry queue, setting retry intervals 123 security 482
rolling back filter version 353 enabling certificate responder 479
exporting certificate and root key 435
rollover of expired certificates 497, 519
gateway-to-gateway 369
root key, exporting 435 generating a certificate 433, 442
root key, publishing 436 LDAP lookup and manual association of
root keys certificates 381
purpose 383 OpenPGP overview 365
root keys, exporting 436 PGP key removal or renewal 582
Rules, in policies, defined 204 policies to monitor messages based on security
state 528
policy types, listed 217
S prerequisites 431
S/MIME private key size limitation 438
and Email Firewall 366 Proxy Decrypt and Verify policy example, for
Certificate Responders overview 395 proxy security 484, 510
harvesting certificates 394 proxy decryption 380
proxy encryption 379
S/MIME Overview 365
proxy security, proxy certificates in 414
S/MIME security proxy security, server certificates in 413
Certificate Authorities 417 proxy signature 380
establishing trust relationships 416 proxy verification 380
saving configuration and directory data 595 rolling over certificates 497, 519
saving messages in the queues 595 S/MIME overview 365
Saving Reports 636 server-to-client, overview 375
scanning html tags 296 server-to-client, setting up 474, 504
setup questions 431
scanning limitations 642
setup, overview 430
scheduling CRL downloads 501
UI functions 432
scheduling CRL downloads, overview 420 unencrypted message filter policy issues 527
scheduling LDAP imports 553 updating local certificates 497, 519
search queues limitation 126 user records in proxy security 494, 516
Secure Messenger description 108 see also, PQM 142
Secure Response service message processing 338 self-extracting zip files, limitation in scanning 644
security self-monitoring of services 348
administrative 9 sender policies, applying 325
certificate removal or renewal 582 sender-based unencrypted message filter issues 527
certificate rollover checklist 404 Sensitive Info Review policy 252

716
server certificate, exporting 435 service not accepting messages, troubleshooting
server certificate, publishing 436 steps 76
server certificates, using third-party 398 Session Welcome and Postmaster Information,
server-to-client PGP security, configuring 504 modifying 40
server-to-client proxy security setting message size limit 37
understanding 375 setting up bounce action 62
setting up exact matching for a domain 65
server-to-client security, configuring 474
specifying the Relay Host Name 39
server-to-client security, understanding 375
SMTP relay
service
recovery options 348 partition function 33
self-monitoring 348 preventing open relays 50
settings to prevent DoS attacks 37
Session Welcome, modifying 40
stopping inbound messages 138
setting security for the domain 466
spam
Setting Up Administrator Accounts 21
anti-spam strategies, generally 329
Setting Up Administrator Preferences 31
automating spam submittals to the lab 357
Setting up Centralized Event Logging and Reporting
categorization and message headers 340
101
confidence 340
Setting Up Global Policy Settings 87
confidence X-headers 341
Setting up Product Updates 109
content 340
Setting Up Queues 105, 109, 116
content rating X-headers 341
Setting Up Relay Centers
non-spam samples 356
Relay Centers, setting up 32
policies, creating 316
Setting Up Virus Scanning Options 80 relay settings to prevent DoS attacks 37
signed messages not caught 326 samples, submitting 356
slack space, scanning of 93 Spam Analysis queue, moving messages 345
SMTP submitting unmarked messages generally 357
A records 46 Spam Analysis Engine
MX records 46
error handling 347
SMTP and SSL 373 event log events 351
SMTP Relay message processing 337
adding an alternate DNS server 41 messages not analyzed by 338
delay and non-delivery notifications 48 processing internal mail 346
delay and non-delivery notifications, explained 48
processing large messages 346
enabling Delivery Status Notifications (DSNs) 46
rolling back a filter version 353
full SQL Server file groups 76
scan performed 340
hiding the product name and version number 40
three-strikes rule 347
Host Name configuration parameter, effect 77
identification errors, troubleshooting 77 spam volume report 621
illegal characters, using to avoid open relay SPN
blacklisting 43 configuring 458
Local MX Hosts configuration 41 creating a policy to check for, steps 467
mail routing rules best match algorithm 66 link requests, responding to, steps 465
randomize MX hosts option 47 policies 372
recipient limit, setting 37 server-to-client, setting up 474, 504
search for ’A’ records option 47 setting security for domain 466

717
SPN link requests third-party certificates, import tool 438
accepting 465 third-party certificates, using for security 398
auto-responding to requests 463 three-strikes rule 347
checking for 465 TLS
forwarding requests 464 certificate domain name match 80
setting up EMF to respond 463 MX record with domain name required to validate
steps 461 certificate 55
SPN link requests and auto-respond 461 troubleshooting 80
SPN links TLS and SSL 373
enabling 461 TLS protocol 374
SPN or encrypted message analysis 339 tools, find user 532
Spreadsheet Files 650 tools, for policy creation 253
SQL Server
transformational actions, in policies 208
full file groups 327
troubleshooting
full filegroups stopping message processing 139
annotations not skipped 325
SMTP Relay and full file groups 76
checking policy actions 325
SSL and TLS 373
checking policy conditions 324
Stop the relay from accepting incoming messages 119 checking policy exceptions 325
stopping inbound mail 36 common lists 327
Stopping Inbound or Outbound Mail Inbound queue backups 139
how to 34 inbound queue backups 139
stopping the relay from accepting more messages 138 inheritance 324
SubjectAltName field, in certificates 424 notification address 327
Summary, of policy 209 notification address is incorrect 327
support, technical xxvii Outbound queue backups 141
System Status 14 policy applied to wrong folder 324
system status policy configuration errors 324
Email Firewall Services 20, 104 policy disabled 324
Info and Alerts 15 policy enabled at wrong level 324
Message Queues 17 policy enforcement problems 324
policy should be recipient (or sender) 325
T queue backups 327
recipient versus sender policies 325
tags SMTP Relay identification errors 77
Advanced Add 277 SMTP Relay policy enforcement not enabled 326
archive tag 274 SMTP Relay service 76
creating 275 SMTP Relay service is stopped 326
queue tag 274 virus pattern needs updating 326
technical support xxvii virus scan engine needs updating 326
testing policies, procedure 320 troubleshooting policy enforcement 324
text extraction 669 troubleshooting TLS 80
text extraction and non-ASCII text, how handled 671 troubleshooting update failures 354
text extraction and unmapped characters 670 trust
text extraction and unsupported or unidentified code according to certificate status 412
sets 669 direct 412
text extraction, from attachments 669 trusted root keys and CRLs 420
Text Scanning Options, setting up 91 trusting self-signed certificates 412

718
Tumbleweed contact information xxviii V
tutorials
verifying authenticity of a certificate 495
action, severity of 235
virus- and file-stripping policies 303
policy enforcement 235
Virus Detected for Specific Sender 628
Types of Reports 616
Virus Hoax Block policy 247
virus pattern file 80
U virus pattern files
Unable to Encrypt and Sign to SPN Domain policy 372 enabling updates 83
Virus Policy Types, overview 217
Understanding Policy Inheritance and Overrides 237
virus scan engine 80
unencrypted message filter policies, troubleshooting
Virus Type and Volume 619
527
viruses
Unencrypted Message Filter policy 385 and file attachment stripping 215
unencrypted message filter policy, creating 525 defining policies for new viruses 305
uninfected messages, clean stamp 217 Melissa 305
UNIX regular expressions 683 new, defining policies for 305
unmapped characters, how handled 670 text filtering policies to protect against 305
virus-stripping policies, using 303
updates
virus-stripping policies, using 303
and database tables 352
Volume Reports 616
database tables affected 351
download file format 351
failure due to MMSConfigData filegroup size 355
W
failure due to transaction log size 355 weighted word list, format required 260
frequency 351 weighted word lists
manually checking for 353 and Advanced Add 260
purpose 351 construction 260
troubleshooting 354 wildcards
updating local certificates 497, 519 caution using in address lists 266
caution using in attachment lists 270
user certificates
caution using in word lists 260
automatic lookup 381
in SMTP Relay best match algorithm 66
user records using in address lists 266
and automatic certificate association, policy using in attachment lists 270
explained 382 using in word lists 259
creating for proxy security 494, 516 Windows Bitmap (BMP) 653
in proxy security 494, 516 Word Lists
objects in directory 220 HIPAA lexicon 252
overview 222
User Reports 627
users
importing 532
records for 220
using 303
using folders 221
UUencode to MIME, policy conversion 216

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

Vous aimerez peut-être aussi