Proofpoint Reference Guide

Proofpoint
Protection Server™
Reference Guide
Proofpoint Protection Server®

Proofpoint Messaging Security Gateway™
Proofpoint Messaging Security Gateway™ Virtual Edition
Release 7.0
Proofpoint, Inc.
892 Ross Drive
Sunnyvale, CA 94086
www.proofpoint.com
Website: www.proofpoint.com
Toll-free telephone: 1-877-64POINT
Proofpoint Technical Support: https://support.proofpoint.com
Reference Guide
Proofpoint Messaging Security Gateway
Proofpoint Protection Server
February 2012
Revision A
Copyright and Trademark Notices
The Proofpoint Protection Server is proprietary software licensed to you for your internal use by Proofpoint Inc. This software is © Copyright 2002 -
2011 Proofpoint Inc. The copying, modification or distribution of the Proofpoint Protection Server is subject to the terms of the Proofpoint Software
License, and any attempt to use this software except under the terms of that license is expressly prohibited by U.S. copyright law, the equivalent laws
of other countries, and by international treaty.
Proofpoint and Proofpoint Protection Server are trademarks of Proofpoint Inc.
McAfee is a registered trademark of McAfee, Inc. and/or its affiliates in the US and/or other countries. Virus Scanning capabilities may be provided by
McAfee, Inc.
Copyright © 2012 McAfee, Inc. All Rights Reserved.
F-Secure Anti-Virus Copyright © 1993-2012, F-Secure Corp.
VMware, the VMware “boxes” logo, GSX Server, ESX Server, Virtual SMP, VMotion and VMware ACE are trademarks (the “Marks”) of VMware, Inc.
MariaDB licensing information is available in the directory ${PROOFPOINT_ROOT}/opt/mariadb.
Apache 2.2 licensing information is available at http://www.apache.org/licenses.
Perl (Practical Extraction and Report Language) is copyrighted by Larry Wall.

It is free software and it is redistributed by Proofpoint under the terms of the “Artistic License” that comes with the Perl Kit, Version 5.0. Source is
available at http://www.perl.com.
Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the
University of Cambridge, England.
Source is available at ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/.
Some database support in this solution is provided by MySQL.

Copyright © 1997, 2011, 2012Oracle and/or its affiliates. All rights reserved.
Copyright © 1986 - 1993, 1998, 2004 Thomas Williams, Colin Kelley

Permission to use, copy, and distribute this software and its documentation for any purpose with or without fee is hereby granted, provided that the
above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation.
Permission to modify the software is granted, but not the right to distribute the complete modified source code. Modifications are to be distributed as
patches to the released version. Permission to distribute binaries produced by compiling modified sources is granted, provided you
1. distribute the corresponding source modifications from the released version in the form of a patch file along with the binaries,
2. add special version identification to distinguish your version in addition to the base release version number,
3. provide your name and address as the primary contact for the support of your modified version, and
4. retain our contact information in regard to use of the base software.
Permission to distribute the released version of the source code along with corresponding source modifications in the form of a patch file is granted
with same provisions 2 through 4 for binary distributions.
This software is provided "as is" without express or implied warranty to the extent permitted by applicable law.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. Neither the name of the developer nor the names of contributors may be used to endorse or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE DEVELOPER ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE DEVELOPER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Portions of this software are Copyright © 1996-2002 The FreeType Project (www.freetype.org). All rights reserved.
Additional graphical © support is provided by libgd:
Portions copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41-RR02188
by the National Institutes of Health.
Portions copyright © 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc.
Portions relating to GD2 format copyright © 1999, 2000, 2001, 2002 Philip Warner.
Portions relating to PNG copyright © 1999, 2000, 2001, 2002 Greg Roelofs.
Portions relating to gdttf.c copyright © 1999, 2000, 2001, 2002 John Ellson (ellson@graphviz.org).
Portions relating to gdft.c copyright © 2001, 2002 John Ellson
Portions relating to JPEG and to color quantization copyright © 2000, 2001, 2002,
Doug Becker and copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
2002, Thomas G. Lane. This software is based in part on the work of the Independent JPEG Group. See the file README-JPEG.TXT for more
information.
Portions relating to WBMP copyright © 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande.
Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial application, provided that this
notice is present in user-accessible supporting documentation.
This does not affect your ownership of the derived work itself, and the intent is to assure proper credit for the authors of gd, not to interfere with your
productive use of gd. If you have questions, ask. “Derived works” includes all programs that utilize the library. Credit must be given in user-accessible
documentation.
This software is provided “AS IS.” The copyright holders disclaim all warranties, either express or implied, including but not limited to implied
warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying documentation.
Although their code does not appear in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software Corporation
for their prior contributions.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit
(http://www.openssl.org/)
zlib.h – interface of the “zlib” general purpose compression library version 1.2.2, October 3rd, 2004
Copyright © 1995-2004 Jean-loup Gailly and Mark Adler
This software is provided “as-is”, without any express or implied warranty. In no event will the authors be held liable for any damages arising from the
use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely,
subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a
product, an acknowledgment in the product documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly jloup@gzip.org Mark
Adler madler@alumni.caltech.edu
Unifont copyright Paul Hardy of Unifoundry.com (unifoundry@unifoundry.com) released under the terms of the GNU General Public License (GNU
GPL) version 2.0.
Tomcat, Log4j, Apache CXF – Apache Copyright © 1999-2012 Apache Software Foundation
Java JRE, JDK, JavaMail, Sun JavaServerFaces – Copyright © 1997, 2011, 2012, Oracle and/or its affiliates. All rights reserved.
JBoss RichFaces – Copyright Red Hat ®. Red Hat is a registered trademark of Red Hat, Inc.
Copyright © 2012 Sendmail, Inc. All Rights Reserved.
Proofpoint gratefully acknowledges contributions of the open source community to the Proofpoint Protection Server. References to open source
software used with the Proofpoint Protection Server is collected into a single repository which can be found in the installed Proofpoint Protection
Server package in src/opensource/OPENSOURCE. That repository, consisting of the contributions from open source projects – but not including
the proprietary Proofpoint Protection Server software referred to above – is a collective work that is © Copyright 2002 - 2012 Proofpoint Inc. You will
find in this repository copies of the source code, or references of where to find, every open source program not referenced in this copyright notice,
that was used in the Proofpoint Protection Server.
Copyright © 2005, Google Inc.

All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution. Neither the name of Google Inc. nor the names of its contributors may be used to endorse or
promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Copyright © 1996 - 2010, Daniel Stenberg, <daniel@haxx.se>.

All rights reserved.
Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright
notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other
dealings in this Software without prior written authorization of the copyright holder.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.You may obtain a
copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed
under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
the License for the specific language governing permissions and limitations under the License.
Copyright © 2012. Proofpoint, Inc. All rights reserved.

PROOFPOINT is a trademark of Proofpoint, Inc. All other product names and brands are the property of their respective owners.
Preface
This Reference Guide describes specific problems and solutions that can be solved with the Proofpoint
Protection Server or Proofpoint Messaging Security Gateway, and provides recommendations for daily
management tasks. This guide is intended for Proofpoint Protection Server administrators and personnel
responsible for managing, monitoring, and generating reports for enterprise-wide messaging applications.
How This Book Is Organized

Chapter 1, “Introduction,” provides a product overview.
Chapter 2, “Deployment and Installation,” describes various scaling and tuning factors when deploying
Proofpoint Protection Servers in a multi-server environment.
Chapter 3, “End User Digests,” provides suggestions on educating the user community and specific
instructions for localization of end user Digests.
Chapter 4, “Security,” provides recommendations for securing the Proofpoint Protection Server or
appliance.
Chapter 5, “Tuning and Configuration,” provides recommendations for miscellaneous system and cluster
performance issues.
Chapter 6, “Maintenance and Troubleshooting,” provides recommendations specific to Quarantine and disk
space management issues. The log database schema is covered in this chapter for administrators who
import the Proofpoint log database into other databases for analysis.
Chapter 7, “Message Filtering,” describes how the filtering engines determine the final disposition of a
message.
Chapter 8, “Command Line Interface,” describes the command line interface for several server and module
management tasks.
Appendix A, “Log File Format,” describes the format for the log files.
Appendix B, “Alerts,” lists alert messages.
Conventions
This book uses the following typographic conventions:
• New terms and book titles appear in italic type.
Release 7.0 Reference Guide 7

Preface
• Text that you type is shown in bold courier font.

• Names of buttons, links, and interface elements appear in this font.
• Text that appears on the screen is shown in courier font.
• Names of keys on the keyboard appear with initial capitalization, such as the Enter key.
• Simultaneous keystrokes are joined with a hyphen. For example, “Press Alt-a.”
• Consecutive keystrokes are joined with a plus sign (+). For example, Esc+m.
Documentation Feedback
Please send your comments and feedback about this manual via email to docfeedback@proofpoint.com.
Proofpoint strives to produce high-quality and technically accurate documentation. Please include the
name of the document and the revision date with your email. Your feedback is greatly appreciated and will
help us maintain our high standards for our product documentation.
8
Contents
Preface ................................................................................................................................................................ 7
How This Book Is Organized ......................................................................................................................... 7
Conventions ................................................................................................................................................... 7
Documentation Feedback ....................................................................................................................... 8
Chapter 1 – Introduction .................................................................................................................................. 15

Filtering Order for the Modules .............................................................................................................. 17
Message Processing Hub...................................................................................................................... 17
Interface Hub .................................................................................................................................. 18
Message Disposition Hub ............................................................................................................... 18
Modules, Rules, Conditions, and Dispositions ...................................................................................... 19
Terminology ................................................................................................................................................. 19
Message Connection State ...............................................................................................................................21
Quarantine and Incident Queue ............................................................................................................ 21
End User Digest .................................................................................................................................... 21
Web Application..................................................................................................................................... 21
Safe Senders/Blocked Senders List ...................................................................................................... 21
Spam Polices and Rules........................................................................................................................ 22
Centralized Management ............................................................................................................................. 22
Chapter 2 – Deployment and Installation ....................................................................................................... 23

High Availability............................................................................................................................................ 23
Deployment Options .................................................................................................................................... 24
Master-Agent Cluster Architecture ........................................................................................................ 24
Use Case – Multiple Clusters in a University......................................................................................... 25
Full Redundancy with Directory Protection............................................................................................ 25
No Redundancy..................................................................................................................................... 26
Redundancy without Directory Protection ............................................................................................. 27
Scaling ......................................................................................................................................................... 27
Failover Support .......................................................................................................................................... 27
Chapter 3 – End User Digests ......................................................................................................................... 29

Educate the User Community ...................................................................................................................... 29
Customize Digest Labels and Select a Language for Ease of Use .............................................................31
Customize the Digest Layout ....................................................................................................................... 32
Customize Digest Labels and Help .............................................................................................................. 32
Creating Unique Translations for the Digest ................................................................................................ 32
Editing a .cfg file with a UTF-8 Compliant Editor .................................................................................. 33
POP3 Links versus HTTP Links for Digest Actions ..................................................................................... 34
Chapter 4 – Security ......................................................................................................................................... 35

Administrator IDs and Passwords................................................................................................................ 35
Preface
The Default Administrator Password .................................................................................................... 35

Agents and Passwords .......................................................................................................................... 35
Administrators and Modules ................................................................................................................. 36
Password Control .................................................................................................................................. 36
Proofpoint Protection Server – Security Tips ............................................................................................. 36
Locking Down the Server ................................................................................................................ 36
SSL Over HTTPS ........................................................................................................................... 36
Security Resources ........................................................................................................................ 37
Stopping Denial of Service Attacks .............................................................................................................. 37
Creating Email Firewall Rules ............................................................................................................... 37
Proofpoint Protection Server – Limiting the Number of Connections .................................................... 38
Obscuring sendmail ..................................................................................................................................... 38
Chapter 5 – Tuning and Configuration ........................................................................................................... 39

Routing Email............................................................................................................................................... 39
Proofpoint Protection Server – Editing the Sendmail Mailertable .......................................................... 39
Appliance – Routing Email .................................................................................................................... 40
Operating System Tuning .................................................................................................................................. 40
Adding a Legitimate Postmaster Address .................................................................................................... 41
Proofpoint Protection Server ................................................................................................................. 41
Appliance............................................................................................................................................... 41
Detecting Mail Loops ............................................................................................................................. 41
Proofpoint Protection Server – Configuring the FQDN within Sendmail ...................................................... 41
Notes on Customizing the sendmail.mc File ......................................................................................... 42
Tuning the Spam Detection Module ............................................................................................................. 43
Synchronize the Cluster with Network Time Protocol .................................................................................. 44
Use Quarantine and DLP Incident Folders to Organize Messages ............................................................. 45
Keep the User Repository Current .............................................................................................................. 45
Use the Discard Disposition for Unwanted Email ........................................................................................ 46
Catching Spam Containing Cyrillic Characters ............................................................................................ 46
Chapter 6 – Maintenance and Troubleshooting ............................................................................................ 47

Creating a Query for Outbound Messages In the Quarantine ..................................................................... 47
Excluding Spammers from the Outbound Message Query .........................................................................47
Blocking Email with Specific Character Sets ............................................................................................... 48
Monitoring and Controlling Disk Space ............................................................................................................ 48
Monitoring the Disk Space ................................................................................................................................49
Freeing Up Disk Space Used by the Quarantine .................................................................................. 49
Reducing the Amount of Disk Space Used by the logdb ....................................................................... 50
Creating an Alert ................................................................................................................................... 50
Proofpoint Protection Server – Freeing Up Disk Space ............................................................................ 50
On the Master ................................................................................................................................. 50
On the Agent ................................................................................................................................... 51
Database and NFS ................................................................................................................................ 51
10
Log Database Schema ................................................................................................................................ 51
Notes ..................................................................................................................................................... 51
Database Schema ................................................................................................................................. 53
Filtered Messages .......................................................................................................................... 53
Email Firewall Module ..................................................................................................................... 55
Digital Assets Module ..................................................................................................................... 55
Message Attachment ...................................................................................................................... 55
Content Table ................................................................................................................................. 55
Dictionary ........................................................................................................................................ 56
Message Disposition ....................................................................................................................... 56
Envelope Sender ............................................................................................................................ 57
Envelope Recipient ......................................................................................................................... 57
Error ................................................................................................................................................ 58
Job Scheduler ................................................................................................................................. 58
Favorite Reports ............................................................................................................................. 58
From Host ....................................................................................................................................... 58
Judgement ...................................................................................................................................... 58
Session Connection Information ..................................................................................................... 58
Milter Session Connection Information ........................................................................................... 60
Spam Detection Module ................................................................................................................. 60
Virus Protection Module .................................................................................................................. 61
End User Digests ............................................................................................................................ 62
Quarantine ...................................................................................................................................... 62
LDAP Import ................................................................................................................................... 63
Zero-Hour Anti-Virus Module .......................................................................................................... 64
Messages Delayed in a Quarantine Folder .................................................................................... 64
Summary Control ............................................................................................................................ 65
Summary Page ............................................................................................................................... 65
Summary Status ............................................................................................................................. 65
SMTP Rate Control ......................................................................................................................... 65
Module Information ......................................................................................................................... 65
Regulatory Compliance................................................................................................................... 66
Proofpoint Encryption ...................................................................................................................... 66
Chapter 7 – Message Filtering ........................................................................................................................ 69

The Path of a Message through the Filtering Process ................................................................................. 70
Criteria for Analyzing and Determining the Outcome of a Message...................................................... 71
1 – SMTP Protocol .......................................................................................................................... 71
2 – Filtering Modules....................................................................................................................... 72
3 – Delivery Dispositions................................................................................................................. 72
4 – Quarantine Folders and Rule Ordering..................................................................................... 73
Message Processing and Composite Rules ..........................................................................................73
Sending Copies of Messages to the Quarantine ................................................................................... 74
Authoritative Rules ................................................................................................................................ 75
Delivery Dispositions and Delivery Options ........................................................................................... 75
Recipient Verification in the Email Firewall............................................................................................ 75
Recipient-based Rules .......................................................................................................................... 76
Putting It All Together................................................................................................................................................76
Rules Triggering in the Same Module ................................................................................................... 77
Contents
Example 1 ...................................................................................................................................... 77
Example 2 ...................................................................................................................................... 78
Example 3 ...................................................................................................................................... 79
Rules Triggering Across Modules ......................................................................................................... 80
Example 1 ...................................................................................................................................... 80
Example 2 ...................................................................................................................................... 81
Use Case Examples .................................................................................................................................... 83
Chapter 8 – Command Line Interface ............................................................................................................ 85

Commands for Tagging and Pushing Configuration Changes ..................................................................... 85
Tagging a File Set ................................................................................................................................. 85
Rolling Back a File Set.......................................................................................................................... 86
pps_ctrlpoint Usage .............................................................................................................................. 86
Examples .............................................................................................................................................. 87
Stopping, Starting, and Refreshing the Server ............................................................................... 87
Listing Configuration Tags .............................................................................................................. 87
Getting Parameters ........................................................................................................................ 88
Setting a Parameter........................................................................................................................ 88
Commands for Processes ........................................................................................................................... 88
pps_control Usage ................................................................................................................................ 88
Making Configuration Changes to filter.cfg ................................................................................................. 89
Commands for the User Repository ............................................................................................................ 90
useradm Usage..................................................................................................................................... 90
Import Attributes ................................................................................................................................... 94
CSV File Format ............................................................................................................................. 94
CSV Text File Example .................................................................................................................. 99
Examples for the useradm Utility .......................................................................................................... 99
Simple Imports................................................................................................................................ 99
Imports that Include Groups ......................................................................................................... 100
Advanced Imports ........................................................................................................................ 101
Commands for Group Management .......................................................................................................... 101
groupadm Usage................................................................................................................................. 101
Examples ............................................................................................................................................ 101
Examples for the groupadm Utility ...................................................................................................... 103
Commands for Quarantine Management .................................................................................................. 104
qdbutil Usage ...................................................................................................................................... 104
Database Operations .......................................................................................................................... 104
Folder Operations ............................................................................................................................... 105
Message Operations ........................................................................................................................... 106
Query Options ..................................................................................................................................... 106
Examples ............................................................................................................................................ 108
Commands for the Digital Assets Module ................................................................................................. 108
datutil Usage ....................................................................................................................................... 108
Options................................................................................................................................................ 108
Examples ............................................................................................................................................ 109
Commands for the Log Database.............................................................................................................. 110
logdbtutil Usage .................................................................................................................................. 110
Options................................................................................................................................................ 110
12
Contents
Commands for the Log Collection Service ................................................................................................ 110

log_upload Usage ............................................................................................................................... 110
Options.......................................................................................................................................... 110
Commands for Buffer Queue Management ............................................................................................... 112
queued Usage ..................................................................................................................................... 112
Options ................................................................................................................................................ 112
Cloning an Agent ....................................................................................................................................... 112
clone_config Usage ............................................................................................................................. 112
Options ................................................................................................................................................ 113
Publishing URLs to an External Web Page ............................................................................................... 113
Embedding Report Data in an HTML Page......................................................................................... 113
Enabling a Quarantine Node ..................................................................................................................... 115
Enable the Management Interface ...................................................................................................... 115
Add the Quarantine Node ................................................................................................................... 116
Performance Optimization................................................................................................................... 116
Recovering a Quarantine Node ........................................................................................................... 116
Recovering a Master Proofpoint Protection Server ............................................................................. 117
Appendix A – Log File Format ...................................................................................................................... 119

Log Entry Format ....................................................................................................................................... 119
Log File Naming ......................................................................................................................................... 120
Log Detail ..........................................................................................................................................................120
Service Level ....................................................................................................................................... 121
Session Level ...................................................................................................................................... 121
Message Level .................................................................................................................................... 121
Encryption ........................................................................................................................................... 122
Appendix B – Alerts ....................................................................................................................................... 123
Glossary .......................................................................................................................................................... 131
Index ................................................................................................................................................................ 135

14
Chapter 1 Introduction
The Proofpoint Protection Server is a powerful software application that integrates virus protection, spam
detection, message encryption, regulatory compliance, and digital asset protection technologies into an
extensible message management platform. The Proofpoint Protection Server is designed to fit seamlessly
into your corporate environment, taking advantage of the existing corporate messaging infrastructure. It
provides efficient performance, accurate message analysis, and a web-based interface (the management
interface) for configuration, management, and reporting tasks.
Note: This Guide contains topics that apply to the Proofpoint Protection Server and the
Proofpoint Messaging Security Gateway and some topics that are product-specific. Topics
that are product-specific are noted as such in the topic heading. Topics that do not
specifically refer to one product or the other apply to both products. For the sake of brevity,
appliance refers to the Proofpoint Messaging Security Gateway throughout this manual.
The Proofpoint Protection Server is comprised of these components:
Filtering modules – the Email Firewall, Virus Protection, Spam Detection, and Regulatory Compliance
Modules filter SMTP messages for envelope criteria, connection criteria, virus infections, spam, and
message content. The Digital Assets Module protects your organization from accidental or deliberate
disclosure of confidential information or trade secrets.
The Data Loss Prevention (DLP) dashboard provides a centralized and consolidated overview of DLP
activity across your organization with custom views of DLP reports and an incident manager console.
Administrators and security practitioners can view real-time DLP statistics and trends as well as manage
current incidents. Data can be viewed in high level reports or as detailed incidents so that administrators
can quickly focus on the critical areas of interest. The DLP dashboard consolidates data from the
Regulatory Compliance Module and the Digital Assets Module. You will not see the DLP Dashboard in the
management interface if you have not licensed the Regulatory Compliance and Digital Assets modules.
If you have an ICAP-enabled web proxy server (Internet Content Adaptation Protocol) on your network, you
can also filter HTTP content by enabling rules for HTTP content in the Regulatory Compliance and Digital
Assets modules.
Proofpoint Encryption – provides a fully integrated message encryption and decryption solution based on
symmetric-key algorithms.
Administrators have granular control over the filtering policies and dispositions of messages that are
infected, designated as spam, or contain inappropriate or confidential content. Messages designated as
suspicious can be stored in a Quarantine folder or an Incident Queue for further analysis and disposition.
Message Processing Hub – this multi-protocol hub accepts all incoming messages and commands, passes
messages to the Analysis Modules, exposes the functions of the Management Services, and handles final
message dispositions.

Chapter 1 - Introduction
Management Services – centralized management services include message tracing, administration,

reporting, and monitoring.
You can deploy several Proofpoint Protection Servers to provide different services. For example, you can
install the Server Protection software on three systems, deploy one system as the master Management
Services console (Config Master), and deploy the other two systems as the filtering agents – one running
the Secure Reader service and one running the ICAP service (agents). You must designate or configure
the agents from the master system using the management interface. The master Proofpoint Protection
Server pushes the configuration changes to the agents.
This section describes the path of a message through the Proofpoint Protection Server.
The Proofpoint Protection Server can either integrate into an existing gateway sendmail server, or can be
deployed with a sendmail server on the same host. In either case, the sendmail server acts as the MTA
(Mail Transfer Agent) – either as the MX host or an internal MTA.
As sendmail processes SMTP (Simple Mail Transfer Protocol) connections, it passes message content to
the Proofpoint Protection Server using the sendmail Milter (mail filter) interface, then waits for instructions
on what to do with the message. The message state is changed, tracked, and logged at every point in the
path.

Email Virus Spam Regulatory Digital
Firewall Compliance Assets
Current
Message and
Connection
State
sendmail
Message
Disposition
Interface Hub
Hub
Message Processing Hub
forward or reply with annotation
Figure 1. Path of a message through the Proofpoint Protection Server
16
Filtering Order for the Modules
Every message follows this path through the Proofpoint Protection Server:
• The message is routed to the Message Processing Hub. The Message Processing Hub contains the
intelligence of the system and is comprised of three components: the Interface Hub, the Message
Disposition Hub, and the current Message Connection State.
• Email Firewall Module. The Email Firewall Module filters messages for envelope criteria, content, and
message attributes. This module also compares the contents of a message to dictionaries and assigns
weights to the words in the message when it finds a match. You create rules to apply delivery
dispositions to the messages based upon the conditions found by the filtering module. Administrators
can restrict and manage IP connection traffic using the Email Firewall Module with the SMTP Rate
Control feature.
• The optional Virus Protection Module uses an embedded antivirus engine to scan the message and
attachments, if any, for virus infection. The optional Zero-Hour Anti-Virus Module scans messages
looking for “virus-like” patterns and protects your organization from a virus infection during the first
critical hours before new virus signatures have been released.
• The Spam Detection Module checks the connection information, sender, recipient(s), domain, sub-
domain, header, and body information of the message. The MLX Engine™ examines and scores a
message for spam. The Pornographic Spam detection module examines and scores a message for
pornographic spam.
• The optional Regulatory Compliance Module examines the message specifically for Protected Health
Information (PHI) as regulated by the Health Insurance Portability and Accountability Act (HIPAA) and
for Personal Financial Information (PFI) as regulated by the Gramm-Leach Bliley Act (GLBA).
• The optional Digital Assets Module scans messages and attachments for text or information that
should not leave your organization. Proofpoint’s MLX technology “trains” on confidential documents
that you provide to it. For example, these documents can be press releases, internal memos, or
specifications. After training on the documents, the Digital Assets Module scans all outgoing email and
attachments for content that includes the confidential information or even fragments of the information.
Administrators can create policies and rules to place copies of these messages in the Quarantine,
discard them, or re-route them to the appropriate personnel for review.
• Proofpoint Encryption is a fully integrated encryption and decryption solution. Once it is licensed, all
administration and key management is accomplished using the management interface. Authenticated
users can decrypt, forward, and reply to encrypted messages using a browser-based interface.
Each module applies its own set of rules (default or configured by the administrator) to assign a disposition
to a message. As the message is filtered by each module, every rule is executed based upon the
conditions found by the module. Disposition options are aggregated for the message. For example, if a
message scores high enough to be classified as “spam” and contains an attachment that sends it to the
Quarantine, the message in the Quarantine will include a spam score header as well as a subject header
“policy violation.” There are many levels of control for assigning dispositions to messages, which you can
configure through the management interface.
Message Processing Hub
All inbound messages pass through the Message Processing Hub before reaching their final destinations –
the recipient’s inbox, copied to the Quarantine, or deleted without further analysis.

The Message Processing Hub is comprised of an Interface Hub, a Message Disposition Hub, and the
current message connection state maintained in memory.
Interface Hub
The Interface Hub bridges the sendmail messaging APIs to the modules for further processing.
Message Disposition Hub
The Message Disposition Hub resolves the handling of messages based on a set of configured rules. As a
message passes through the filtering modules, it accumulates results such as a spam score, virus
detection, and a score based upon adherence to corporate policies regarding content.
The Message Disposition Hub interprets the results and classifies the message into the following
dispositions:
• Continue – continue to process the message through all other filtering modules.
• Deliver Now – deliver the message to the intended recipient without further processing. This
disposition applies only to the Email Firewall Module.
• Reject – permanently reject the message.
• Retry – temporarily reject the message due to resource constraints.
• Discard – accept the message, then delete the message without further processing.
• Re-route – route the message to an SMTP host.
• Secure – encrypt the message using Proofpoint Encryption.
Important: The Email Firewall and Spam Detection modules are the only modules that provide the
option to stop processing a message once the message receives a disposition of
Deliver Now (Email Firewall only) Reject, Retry, Discard, or Re-route. For all other
modules, the Proofpoint Protection Server will continue to process the message
through all filtering modules if these dispositions are applied to the message.
Each disposition offers several options to apply to messages. Delivery options will vary for SMTP
messages and HTTP content. The following list describes some of the delivery options:
• Place a copy of the message in a folder in the Quarantine or Incident Queue.
• Reply to the original sender with a new custom message.
• Replace the subject of the message with new text. You can optionally include the original subject line.
• Replace the body of the original message with new text, and attach the original message.
• Add X-headers to the message.
• Add new recipients to the original message.
• Send a new message to the original recipient or to a new list of recipients, and include the original
message as an attachment.
• Accept the original message, but silently reject it from the original sender. The original sender cannot
obtain any more information about your mail system.
• Reject the message with an SMTP error code.
18
Modules, Rules, Conditions, and Dispositions
At each step of the SMTP protocol, a message is processed by the Proofpoint Protection Server modules.
Each module adds disposition options to the message, based upon the information it gathers about the
message. The message header reflects all the rules that were executed during the processing of the
message.
Terminology
A module is an application that performs a specific filtering task.
A condition is a message attribute. For example, in the Email Firewall Module an example of a condition is
“the message is from sender HELO domain name example.com.” As another example, in the Spam
Detection Module, a condition is “the message has a spam score of 65.”
A disposition is what happens to the message after the Proofpoint Protection Server finishes filtering it.
Deliver the message to the mail infrastructure, reject it, continue filtering it, or re-route the message to
another server on the network are examples of dispositions. Each disposition provides several options. For
example, a disposition option is “place a copy of the message in a Quarantine folder, and send a copy of it
to another recipient.”
A rule is comprised of a condition and a disposition. When all of the conditions are met, the rule is
triggered, and the disposition is enforced.
A policy is a collection of rules. For example, a spam policy for your organization can include one or more
rules for managing spam.
After a message has been filtered by all the modules the Hub makes the final judgement for the message
disposition. Messages pass through the filters in this order: Email Firewall Module, Virus Protection
Module, Spam Detection Module, Digital Assets Module, and finally Regulatory Compliance Module.
Messages continue to process through all modules, in order, executing all the rules that apply. The
disposition with the highest priority is applied to the message after all processing is finished.
The following table describes the internal sequence of events:
Priority Sequence of Events

1 Execute the rule. Execute the internal function within the
Proofpoint Protection Server code.
2 Make a copy of the message and place it in the Quarantine.
3 Secure. Encrypt the message.
4 Reject the message with an SMTP return code.
5 Retry. Reject the message temporarily; try to re-send later.
6 Redirect. Send the message to another recipient.
7 Discard. Reject the message silently.

Priority Sequence of Events

8 Deliver Now. Accept the message for filtering but do not pass it
back to Milter.
9 Continue processing the message and continue processing
Milter calls.
For example, if the Virus Protection Module assigns a disposition of Quarantine and Continue to a
message, and the Spam Detection Module assigns a disposition of Quarantine and Reject to the same
message, the final disposition of the message is Quarantine and Reject, because Reject is a higher priority
than Continue in the disposition hierarchy.
Message state - the information each module

collects about the message is stored in memory Proofpoint Protection Server
Reject (no more processing)
Email Firewall R, C, Q, RR Virus Protection

HELO Module RT, D Module
From
R, C, Q, RR
RT, D
Rcpt
sendmail
Milter
Spam Detection
Header
Deliver Now Module
(no more processing)
End of Header
R, C, Q, RR
Message body RT, D
Q, C, RR
End of body Regulatory Compliance
Module
Hub
R, C, Q, RR
RT, D
C= Continue
R= Reject Digital Assets
RT= Retry Module
D= Discard
RR= Re-route
Q= Quarantine Judgement
R, C, Q, RR
RT, D
Order
Message
Disposition
Email Firewall Module Reject
Deliver
Virus Protection Module
Discard
Spam Detection Module Retry
Digital Assets Module Re-route
Regulatory Compliance
Module
Figure 2. Message Dispositions
20
Message Connection State
Per-connection and per-message state information is preserved in memory and passed to each module in
a shared and collaborative fashion. Message parsing is enacted on an as-needed basis and is then
available for subsequent use without re-parsing. Annotations and other message modifications are
aggregated during each processing phase, but reconstruction of the message is deferred until final
delivery.
Quarantine and Incident Queue
Copies of messages can be placed in a Quarantine folder or an Incident Queue folder for further analysis
and disposition. The Quarantine and the Incident Queue are accessible through the management
interface. Administrators have the option of adding unique folders to the Quarantine and Incident Queue
and organizing messages into these folders.
When several Proofpoint Protection Servers are deployed in a cluster, each agent system maintains a local
Quarantine Queue and a Quarantine Consolidator. The Quarantine Consolidator is a program that checks
for messages in the Quarantine Queue and transfers any messages it finds to the master Proofpoint
Protection Server Quarantine. The master Proofpoint Protection Server maintains a consolidated
Quarantine that contains the messages from all the systems in a cluster.
If for any reason the master Proofpoint Protection Server is off-line for a temporary period of time,
messages continue to be saved in the agent Quarantine Queue until the master Proofpoint Protection
Server is back on-line. When the master Proofpoint Protection Server is enabled, the Quarantine
Consolidator will then transfer all messages to the consolidated Quarantine maintained by the Proofpoint
Protection Server.
End User Digest
Administrators can configure the master Proofpoint Protection Server to send a list of quarantined
messages (a digest) to end users. Users can view the list of messages they have in the Quarantine or
Incident Queue, and request that the messages are released, or request that the messages are released
and the sender of the message be added to a personal Safe Senders list. The Command Processor on the
master Proofpoint Protection Server handles these requests and processes them according to policies set
up by the administrator.
Web Application
The Web Application allows users to view messages in the Quarantine or Incident Queue using a browser.
They can also manage Proofpoint tasks such as creating Safe Senders and Blocked Senders list, choosing
a language, and selecting a policy for filtering spam.
Safe Senders/Blocked Senders List
Administrators can allow users to add senders to a personal Safe Senders list or Blocked Senders list. If
enabled, users receive an email message that lists the Safe Senders, Blocked Senders, and email aliases
for the user, giving them an opportunity to add, delete, or modify the list. Users cannot modify email
aliases—they can only view them.

Spam Polices and Rules
Administrators can create and apply spam policies at a global, group, or end user level. If allowed, users
can view a list of available spam policies in their Digests and select a spam policy from this list. When a
user selects and applies a spam policy from the list to their email, this policy overrides any other policy that
has been configured for the user.
Centralized Management
Several Proofpoint Protection Servers can be deployed in a cluster, with or without a load balancer. You
can designate one Proofpoint Protection Server as the master system and all other Proofpoint Protection
Servers as agent systems.
You have the option of disabling the filtering modules on the master system. The master system can
perform filtering as well as administrative functions, or it can be a dedicated administration server. In either
scenario, the master or administrative server manages all administration tasks for the agents on the
network, and “pushes” configuration changes and software updates to the agent systems. The agents
accept configuration changes from the master system, allowing centralized management for all systems in
the cluster.
The master Proofpoint Protection Server transfers log data from each agent system to a central local
database for aggregating and reporting on statistical data.
22
Chapter 2 Deployment and Installation
There are many ways to fine-tune the Proofpoint Protection Server or appliance to improve the security,
reliability, and performance of the system. For details about the configuration parameters for both products,
refer to Proofpoint Help.
The Proofpoint Protection Server and appliance are both designed as gateway products to protect the
email environment inside your network. To protect your email environment, they must be deployed as the
first point of contact for any mail arriving from the Internet.
As the first point of contact for mail from the Internet, the Proofpoint Protection Server or appliance protects
your other gateway servers and your internal mail servers. Most deployments place the Proofpoint
Protection Server or appliance in the DMZ. From there the Proofpoint Protection Server or appliance
quarantines or rejects messages containing spam while also routing the filtered email to another
downstream mail gateway or an internal mail server. Administrators can optionally use a secondary mail
gateway to provide an additional routing path for email.
The Proofpoint Protection Server must be listed as the primary MX server in the DNS (Domain Name
System). Alternatively, you can configure your firewall to use Network Address Translation (NAT) to point
the MX records to the Proofpoint Protection Server.
High Availability
By deploying more than one Proofpoint Protection Server or appliance in a master and agent cluster, you
can implement high availability and avoid a single point of failure. (You cannot mix Proofpoint Protection
Servers and appliances in a cluster.)
In a cluster a single master controls one or more agents. The master pushes a consistent configuration to
the agents while simultaneously consolidating the logs and Quarantine repositories from the agents. In
addition to avoiding a single point of failure, the agent systems also provide more scalability for
environments with higher mail volume. The master can filter email along with the agent systems as well as
serve as the central command and control center.
Proofpoint recommends placing the agents in the DMZ and the master on the internal network to reduce
the chances of an outside hacker accessing the master Proofpoint Protection Server or appliance.
However, if the master is also filtering email coming from the Internet, it should be deployed in the DMZ
along with the agent systems.
Consider these options for routing mail to the agent systems:

• Configure the firewall to use NAT to pass the email messages in round-robin fashion to the agent
systems. This method presents a single point of entry for mail to the outside world while the firewall
seamlessly distributes the messages to multiple agents.

Chapter 2 - Deployment and Installation
• Modify your MX records so that you have one MX record for each agent. By weighting each of the MX
records equally, you will ensure a random but equal distribution among the agents. With this method
you do not have to configure NAT – the distribution is controlled by the DNS settings.
Deployment Options
This section provides examples for deployment options. Deployments will vary according to an
organization’s email volume, network infrastructure, and geographical constraints. The illustrations in this
section are meant to serve only as examples.
Master-Agent Cluster Architecture
In the Proofpoint solution, several appliances or Proofpoint Protection Servers can be deployed in a cluster.
One server is designated as the master (or Config Master), and the remaining servers are designated as
filtering agents. The agents provide fully redundant email relaying and filtering. The master server provides
centralized configuration and administration through the web-based management interface for these
functions:
• Centralized policy management. All software, spam, and virus definition file updates and policy
configuration changes are automatically pushed to the agent servers, keeping the configuration
synchronized across the entire cluster.
• Consolidated quarantine. Quarantined email is regularly consolidated on the master server.
• Consolidated logs and reports. Log files are regularly consolidated on the master server for
consolidated reports.
• End user Digest generation and self-service. The master server can send out quarantine Digests to
end users, listing all of the mail that has been quarantined for that user. In addition, the end user can
log into the Web Application (hosted on the master) for setting their spam policy preferences or log in to
their account using a web browser for browser-based access to their quarantined messages.
The master server can optionally be enabled for filtering. For large deployments Proofpoint recommends
turning off filtering on the master so that it can be dedicated to administrative tasks.
With master and agent (clustering) capabilities, there is no administrative burden added when the number
of servers is increased. Spam and virus policies and configuration settings on the agents is managed
centrally from the master. As the agents process incoming email, mail will be routed to the appropriate
servers. Any messages that need to be quarantined are held in a local quarantine queue on the agent and
this queue is consolidated to the master.
The appliances can be configured for N + 1 redundancy in a modular fashion for peak volume, ensuring
that there is no single point of failure. In the event that one of the appliances becomes unavailable, email
will continue be filtered and delivered to the email infrastructure.
Figure 3 on page 25 illustrates one of many possible deployment options, using the appliance as a
deployment model. One system is installed as the master server. The other systems are installed as agents
in the DMZ to handle incoming email, filter, and route to the email server. Load balancing among the agents
24
can be achieved by several methods – for example, by using multiple MX records, DNS round-robin, or
external load-balancing hardware.
Figure 3. Master-Agent Cluster
Use Case – Multiple Clusters in a University
In some environments, such as universities, there are multiple entry points for email – central gateways as
well as individual departments. For protection against spam and virus infections to be effective, an
appliance or Proofpoint Protection Server cluster should be deployed at each email entry point. In this case
a Proofpoint cluster can be deployed for each departmental email infrastructure, in addition to the central
gateways. Each cluster consists of a master server (for centralized administration, reporting, and Digest
generation) and several email filtering agents.
Deploying multiple clusters in such an environment affords the following advantages:

• Each department controls its own cluster and enforces its own policies.
• Some departments may wish to deploy Proofpoint appliances, while others may wish to deploy the
Proofpoint software on Linux hardware.
Full Redundancy with Directory Protection
Figure 4 illustrates the recommended deployment for a single Proofpoint cluster with firewalls and a DMZ.
This deployment offers complete redundancy as well as protection against leaking of internal directory
information to the DMZ within the firewall infrastructure. In the example, the master server has an optional
LDAP import feature that directly accesses an LDAP or Active Directory interface (through port 389). In this

design, one server is a dedicated master and does not filter email, allowing for all of its resources to be
dedicated to administration, the Quarantine, Digest processing, and end-user functionality.
Figure 4. Full Redundancy with Directory Protection
No Redundancy
Figure 5 illustrates a more simplistic and cost-effective alternative to the previous deployment example, but
it is not as robust and is subject to failover limitations. The organization’s internal directory information is
still protected by separating the service across the firewall infrastructure. If the agent fails, the master can
be reconfigured to behave as both master and agent – that is, filter email as well as serve as the central
management for administration, the Quarantine, Digest processing, and end user functionality.
Figure 5. No Redundancy
26
Redundancy without Directory Protection
Figure 6 illustrates a deployment where both master and agent filter email and both servers are located in
the DMZ. This deployment is cost-effective and redundant, but it does not offer the same degree of
protection against internal directory information leaking into the DMZ infrastructure.
Figure 6. Redundancy without Directory Protection
Scaling
The performance aspects of the Proofpoint Protection Server filtering system are designed to scale both
vertically and horizontally. For vertical scaling, the Message Processing Hub uses native system threads,
asynchronous network I/O, and multiple cloned in-process Perl interpreters for maximum performance out
of shared memory multi-processor systems.
Horizontal scaling is possible because minimal interactions are required between each Proofpoint
Protection Server instance. Each instance has its own local copy of the configuration, so it is not reliant on
any other servers for processing. As each sendmail connection is processed, a new connection is made by
way of the Milter interface. These connections can be redirected through a hardware load balancer to a
pool of filter servers in a round-robin fashion.
Failover Support
Each agent in a cluster shares a common configuration that is managed and pushed by the system running
the Management Services, and each server maintains a local copy of the configuration. If one agent is
down, the other agents in the cluster are not affected.

The configuration files are stored centrally on the administrative server. After a failed agent server is
recovered, the configuration is pushed to that server before it is re-started. You can also mirror the
configuration repository on another system or archive it for later recovery.
The Proofpoint Protection Server solution is designed to ensure that as long as at least one system of a
cluster is up and running, messages continue to process. If an entire cluster becomes unavailable, the
sendmail Milter configuration continues to deliver messages until one or more systems in the cluster is
back on-line.
28
Chapter 3 End User Digests
This chapter provides recommendations for setting up and delivering end user Digests to the users in your
organization. This chapter also provides instructions for creating your own unique translations for the end
user digest.
Educate the User Community

After implementing the Proofpoint Protection Server in your organization, educate the user community on
the benefits of using the Proofpoint solution to lower or eradicate the incidence of spam email. If you
distribute End User Digests and allow users to release messages and manage their own safe senders and
blocked senders lists, you need to teach them how to manage their accounts from their Digests.
To help you get started, your Proofpoint Sales Engineer can provide you with a template that you can
modify and distribute to the user community. You will want to customize the template for your particular
business needs or email policies.
Figure 7 on page 30 illustrates an example of an end user Digest sent by email to the user. You can
customize the appearance of the Digest – for example, change the names of links and add a logo for your
organization.
Administrators have the option of allowing users to manage their Proofpoint accounts using a web browser
– this is the Web Application feature. A user can launch a browser, log in to his or her Proofpoint account,
and manage the account by releasing messages from the Quarantine, creating Safe Senders and Blocked
Senders lists, and selecting a spam policy. All of these options are controlled by the administrator. Figure 8
on page 31 illustrates an example of a Web Application view to a user’s Proofpoint account, depicting the
Quarantine page.

Chapter 3 - End User Digests
Figure 7. Example of an end user Digest sent by email
30
Figure 8. Example of a Web Application view
Customize Digest Labels and Select a Language for Ease of Use

As the mail administrator, you will know the level of sophistication of your user community. You can change
the default introduction that displays in the Digest to customize it for the users in your organization.
You can customize all of the text that appears in the email Digest and the Web Application, and you can
change the default language for the text as well. The text elements that display in the email Digest and
Web Application are called resources, and can be viewed and changed on the End User Services >
Resources > Global page. The Groups and Users > Global > Services page provides a central location for

changing the default language for the Digest and Web Application. The End User Services > Resources >
Global page provides a central location for changing the content of the Web Application and Digest.
Customize the Digest Layout

Organizations typically have logos and custom colors to uniquely identify them. You can add the logo to the
Digest and change the color scheme so that it matches the identity of your organization on the End User
Services > Branding Templates page.
Customize Digest Labels and Help

If you want to change the default labels that users see in their Digests, you can accomplish this on the End
User Services > Resources > Global page. If you do change the default labels, Proofpoint recommends that
you disable the default Help link that describes the default labels, and point users to a URL in the Digest
that provides users with the customized labels for your organization.
To disable the default Help link:

1. Click Commands under End User Services in the navigation pane.
2. Select Off for the parameter Display Digest Help Link.
3. Click Save Changes.
Proofpoint provides default files (text and HTML) that describe the default labels in the Digest and Safe
Senders/Blocked Senders lists. If you want to copy and edit the HTML files so that they describe the
custom labels for your organization, the HTML files are located in the directory
${PROOFPOINT_ROOT}/htdocs/enduser/template/help/digest.htm and usbl.htm, respectively. After
you copy and edit the files, you can provide them to your users by pointing them to a URL in your
organization (after you disable the default Help link).
To point users to your custom URL for help:

1. Click Digest Settings under End User Services in the navigation pane.
2. Click On for Add URL Link in the Custom Link section.
3. Enter Help into the Text field.
4. Enter the URL for your custom help into the URL field.
Creating Unique Translations for the Digest

If the Groups and Users > Resources > Global page does not include the language that you require, you can
create your own translations for the key-value pairs that are displayed on the Resources page.
The Proofpoint Protection Server provides a .res and a .cfg file for each language. The .res file contains
the default translations for the Digest parameters, which you should not modify because they are replaced
each time you download and deploy the latest versions of the software.
32
The .cfg files do not include translations; if necessary, create your own. The translations in the .cfg files
supersede the values or translations in the .res files. Any unique value you provide for a Digest parameter
in a .cfg file will automatically take precedence over the default value in the .res file. The Proofpoint
Protection Server first reads the .cfg file and then the .res file for the correct translation set.
To create an additional language .cfg file, copy the en_us.cfg file to <new.locale>.cfg, which will be
automatically detected by the Proofpoint Protection Server. Simply rename the file and provide your own
translations.
Note: If you have an appliance, open a ticket in CTS to create an additional language .cfg file.
Locating and downloading a .cfg file for editing:

1. From a secure shell, log in to the master Proofpoint Protection Server. Use your pps login and
password.
2. From the command prompt, change directories to
${PROOFPOINT_ROOT}/etc/resources/digest/custom.
3. To list the files in the /digest directory, enter ls -al.
4. Locate the language .cfg file you want to edit.
5. To view the contents of the .cfg file, enter less filename.cfg. (Note, the .res and .cfg files are
encoded in UTF-8 and might not display properly on your monitor.)
6. Download the .cfg file to your local system for editing.
7. Exit the secure shell.
Editing a .cfg file with a UTF-8 Compliant Editor
Because all .cfg files are encoded in UTF-8, be sure to use an editor that supports UTF-8 encoding,
otherwise the contents of the file may not display properly on your monitor.
The .cfg file is comprised of several sections:

• Digest – includes the translations for the End User Digest sent to the users.
• End User Web application – contains the translations for the Manage My Account web application.
• Secure Reader – contains the translations for Proofpoint Encryption Secure Reader.
• HTTP commands – includes the HTTP responses to requests made from the End User Web
application.
Search for the parameter for the value you want to change in the appropriate section. After you create and
save your translations, upload the .cfg file back to the
${PROOFPOINT_ROOT}/etc/resources/digest/custom directory.
After making changes to the .cfg file, you must restart the Email Services on the master Proofpoint
Protection Server for your unique translations to take effect. Navigate to System > Servers, expand the
process table for the master, select the procmsgs process, and click Start from the action menu.

POP3 Links versus HTTP Links for Digest Actions
You can set up the Proofpoint Protection Server to use a POP3 mail server or HTTP links to process end
user Digest actions such as releasing messages and requesting a safelist.
If the users typically sit in front of their computers all day and have constant access to the intranet, it makes
sense to use HTTP links for the Digest actions.
If the users are working remotely, or travelling frequently, it makes sense to use a POP3 mail server. When
the remote users connect to your organization’s network they can request the Digest actions by email.
The Email Client attribute determines how users process Digest actions.
For example, if your email community consists of most users online during working hours and a small set of
remote users, you could set up the Digest actions as follows:
• Apply the global attribute HTML/Text + HTTP Commands or HTML Only + HTTP Commands.
• Create a group of users named remote and apply the group attribute Simple HTML/Text to this group.
34
Chapter 4 Security
This chapter includes tips for protecting the administrator accounts and enhancing security.
Administrator IDs and Passwords

An administrator account consists of an administrator ID and associated privileges. The Proofpoint
Protection Server makes it possible to ensure that each administrator only has access to the modules he or
she needs to manage. It allows for eliminating administrator privileges for one person without affecting the
others. To do this, configure a separate administrator ID for each person who has access to the Proofpoint
Protection Server or appliance, and select the specific modules each administrator can modify.
Set up the password policies so that administrators must use complex passwords and force password
expirations so that they must change their passwords at specified intervals.
The Default Administrator Password
The default administrator login ID is admin. This account is considered the “super-user” and it should be
carefully controlled.
During the software installation, you are prompted to create a password for admin that meets the following
default requirements:
• A minimum length of seven characters.
• It must contain a mixture of letters and numbers and at least one special character.
You cannot delete the admin login ID but you can (and should) change the password for the login ID on a
regular basis. The admin user has unrestricted administrative privileges for the Proofpoint Protection
Server or appliance, including all modules and configuration. Anyone with admin privileges controls the
administrative privileges for all other administrator accounts.
Agents and Passwords
When you add agents to a cluster, the Proofpoint Protection Server software auto-generates a username
and password to be used for all master-agent communications from that point forward. This username and
password is encrypted and stored in ${PROOFPOINT_ROOT}/admin/etc/admind/servers in the
<FQDN>.serv file.
Using the management interface, you can add or change the admin password for the agent, and it has no
effect on the auto-generated username and password stored in the <FQDN>.serv file. The admin password
for the master and the admin password for the agent are not linked in any way. If you change the admin
password on the master, it will not automatically change on the agent.

Chapter 4 - Security
Administrators and Modules
One way to maintain more control over who can make changes to the product configurations is to limit
administration privileges by using the Managed Modules feature. For example, when you add an
administrator you can limit his or her privileges to the Logs and Reports module and the Email Firewall
module.
When adding an administrator, reserve the Administrators Management module to personnel who are highly
trusted users with “super-user” privileges.
Password Control
It is good practice to enforce password policies that require a minimum length of letters, special characters,
and numbers. You can also force administrators to change passwords at specified time intervals, and “lock
out” users that consistently attempt to log in to the Proofpoint Protection Server or appliance using the
wrong password.
The Proofpoint Protection Server provides extremely robust password policies to protect the system from
hackers and users who should not be making changes to configuration settings. Configure password
policies on the Groups and Users > Password Policies page, then select a password policy for
administrators. A default policy for administrators is included for your convenience.
Proofpoint Protection Server – Security Tips
Consider the following recommendations for securing the Proofpoint Protection Server:
• Lock down the server by closing ports not used by the Proofpoint Protection Server.
• Use SSL over HTTPS.
• Use administrator IDs and complex passwords.
Locking Down the Server
The best method of securing the Proofpoint Protection Server is to lock down access to the server. To lock
it down, disable all the ports on the server that are not being used by the Proofpoint Protection Server
software.
Use the UNIX command netstat -nl to list the ports in use on the Proofpoint Protection Server. Any ports
that are not used specifically for the Proofpoint Protection Server should be closed to protect the system.
For example, you should disable NFS/NIS, Telnet, and FTP with the UNIX checkconfig command.
Refer to the Proofpoint Product Family Pre-Installation Requirements document for a list of the ports that
need to be open.
SSL Over HTTPS
When installing the Proofpoint Protection Server software on a system, select SSL over HTTPS as the
method to connect to the management interface. Using SSL and a non-standard SSL port makes it more
difficult for a hacker to gain access to the server.
36
Security Resources
Consult the following sites for more information on how to secure your Proofpoint Protection Server:
• http://www.sans.org/top20/
• http://www.linuxsecurity.com/docs
• http://www.linux-sec.net/harden
• http://www.nessus.org (provides a free remote security scanner)
Stopping Denial of Service Attacks

A Denial of Service (DoS) attack is designed to overload and disable a network by flooding it with useless
traffic. Most DoS attacks exploit the limitations with the TCP/IP protocols.
The first layer of protection occurs at the sendmail connection point – sendmail can limit the number of
allowed connections. Keep in mind that if the Proofpoint Protection Server or appliance is deployed as the
first point of contact for any mail arriving from the Internet the Email Firewall Module rules become more
important for preventing a DoS attack. If the Proofpoint Protection Server or appliance is deployed
internally, that is, it receives inbound traffic from a “trusted” relay server, the DoS attacks are prevented by
another system in the DMZ.
The Proofpoint Protection Server and the appliance can stop DoS attacks at these levels:
• With Email Firewall Module rules that limit the number of connections, message size, and number of
messages per connection.
• At the sendmail connection point by limiting the number of connections.
On the Proofpoint Protection Server, you must edit the sendmail.mc file to configure this parameter.
On the appliance, the number of connections is already limited to 650. You do not need to do anything.
Creating Email Firewall Rules
To prevent DoS attacks using the Email Firewall Module, create a separate rule to reject messages for
each of these conditions:
• Total Connections – The total number of inbound connections aggregated from all IP addresses
exceeds a specific value. The value for the rule should be less than or equal to the sendmail value
defined by MAX_DAEMON_CHILDREN. The recommended value is 500.
• Total Concurrent Connections – The total number of inbound connections from a single IP address
exceeds a specific value. If the Proofpoint Protection Server or appliance is the first point of contact,
the value should be 10.
• Total Messages – The total number of messages per one inbound connection exceeds a specific value.
This value depends upon the policies of your organization. Spam typically arrives on more than one
connection. A recommended value is 100.
• Message Size – The message size exceeds a specific value. The recommended value is 20 MB per
message.

Proofpoint Protection Server – Limiting the Number of Connections
Follow these steps to limit the number of sendmail connections to 500:

1. Using a secure shell, log in to the Proofpoint Protection Server as the user with administration
privileges for sendmail.
2. Change directories to /etc/mail and open the sendmail.mc file for editing.
3. Add the following line to the sendmail.mc file:
define(‘confMAX_DAEMON_CHILDREN',‘500')dnl
4. Save the changes and close the sendmail.mc file.
5. Stop and start sendmail with the following commands:
/etc/init.d/sendmail stop
/etc/inti.d/sendmail start
Obscuring sendmail
One of the methods to provide better security for your Proofpoint Protection Server deployment is to hide
the MTA that is accepting the messages. You can do this by changing the initial SMTP protocol handshake
that occurs when two mail servers are talking. The Proofpoint Protection Server uses sendmail as one of its
MTAs, and it defaults with a greeting that displays “Sendmail.”
Follow these steps to change the greeting:

1. Log in as the user root since this is the user that can configure sendmail.
2. Change directories to /etc/mail and open the sendmail.mc file for editing.
3. Find the line with the definition for SMTP_LOGIN_MSG and change it to look similar to the following
example:
define(`confSMTP_LOGIN_MSG', `$j Authorized users only. All access may be
monitored for administrative and security reasons. $b')dnl
5. Stop and start sendmail with the following commands:
/etc/init.d/sendmail start
38
Chapter 5 Tuning and Configuration
This chapter includes recommendations for Proofpoint Protection Server tuning and configuration. As each
deployment is unique, the recommendations here are not specific and designed solely to expose the
administrator to various areas to consider while planning or maintaining a deployment.
For detailed sendmail configuration information, refer to the sendmail reference book by O’Reilly press.
Routing Email
After filtering email, the Proofpoint Protection Server or appliance passes the “clean” messages back to
sendmail to be routed to their final destinations. For both products, you must configure sendmail with the
routing information for these messages. The email can be routed to either a single mail server or multiple
downstream mail servers or gateways based on domain names.
On the appliance, you can use the management interface for this task. See “Appliance – Routing Email” on
page 40.
On a Proofpoint Protection Server you must configure sendmail by adding the domains to the sendmail
mailertable that accept mail and the hosts that will route mail for these domains. You also need to edit
the sendmail relay-domains table to list the domains that will accept mail.
Proofpoint Protection Server – Editing the Sendmail Mailertable
This section provides instructions for editing the sendmail mailertable and relay-domains table for the
Proofpoint Protection Server.
The Proofpoint Protection Server will filter any mail passed to it through the Milter interface configured
within sendmail. Therefore, if you want to filter mail from an additional domain, you will need to add it to
your sendmail configuration.
1. Using a secure shell, log in to the Proofpoint Protection Server system as the user with administrator
privileges for the sendmail configuration files.
2. Change directories to /etc/mail.
3. Open the mailertable file for editing and add each domain for which you want to route the filtered
mail. The file should contain one entry per line for each mail domain that accepts mail and the host to
which the mail is relayed. For example:
<domain> <mail host to relay messages>
example1.com smtp:[exchange.example.com]
example2.com smtp:[notes.example2.com]

Chapter 5 - Tuning and Configuration
4. Edit the file relay-domains so that it contains the domains that will accept mail. It should contain one
entry per line for each domain listed in the mailertable. For example:
example1.com
example2.com
5. Use these commands to stop and start sendmail so that the new configurations can be applied:
The added domains should be accepted by sendmail and should be passed to the Proofpoint Protection
Server for filtering, provided that you configured the Milter correctly.
Appliance – Routing Email
Email that has been filtered and is “clean,” that is, no rules were triggered, needs to be sent to its final
destination. The appliance uses the Routing Table, Smart Host, and DNS for the decision-making process
for routing clean email in this order:
1. The appliance uses the information defined in the Routing Table to route the mail to its final destination.
(Appliance > Inbound Mail page.)
2. If Smart Host is enabled, any mail that cannot be routed by the hosts or IP addresses listed in the
Routing Table is sent to the smart host for routing and delivery.
3. If the Routing Table uses DNS for routing purposes, the appliance will look up the preference of the
mail server in the DNS entries.
Please refer to Proofpoint Help for specific instructions on how to set up email routing for an appliance.
Operating System Tuning

The following section is intended for experienced UNIX system administrators.
The Proofpoint Protection Server is supported on Red Hat Enterprise Linux ES. It is best to have a release
of the OS and current patch levels related to security. For Red Hat Linux, be sure to select the server
installation option. Use a journaled filesystem such as JFS or ext3 on Linux (note that on Linux disk
behavior can be adjusted with hdparm).
Many performance problems result from a single bottleneck. To analyze performance you may wish to use
tools such as iostat (disk I/O), vmstat (memory), mpstat (CPU), and netstat (network I/O). Parameters
affecting the maximum number of open files and network sessions may have a positive effect on
performance for servers handling many simultaneous TCP (SMTP or Milter) connections or processing
large numbers of messages concurrently. However, if performance is adequate for your configuration there
is no need to alter kernel parameters.
Improving scalability and performance involves balancing the OS configuration with the needs of the
applications on a specific hardware configuration. Some of the values you might wish to use are dependent
on your hardware configuration, for example, the amount of memory and the number of CPUs in your
servers. Be sure to read and understand your operating system documentation for each parameter before
making changes.
40
Contact Proofpoint Professional Services for help tuning the operating system for the Proofpoint Protection
Servers.
Adding a Legitimate Postmaster Address

It is important to ensure that the correct postmaster address is provided to the Proofpoint Protection Server
or appliance. If the postmaster address is not provided or is incorrect, all undeliverable email and email to
root will remain in the /var/spool/mqueue, potentially causing the system to consume system resources
or run out of disk space and cause a “temp fail.”
Follow these steps on a Proofpoint Protection Server to edit the /etc/aliases file to add a legitimate
postmaster address:
1. Using a secure shell, log in to the Proofpoint Protection Server system as the user with root
administration privileges.
2. Open the /etc/aliases file for editing.
3. Find the entry for postmaster and add a legitimate email address for the postmaster. For example:
postmaster:legitimate_user@proofpoint.com
4. Enter the newaliases command at the prompt to commit the change.
Appliance
Follow these steps to add a legitimate postmaster address to an appliance:

1. Log in to the management interface.
2. Go to the Appliance > SMTP Settings > General page.
3. Enter the postmaster email address into the Postmaster Email Address field.
4. In addition, if you want to receive email messages about system level activity in your root email
account, enter your address in the System Administrator Email Address field.
Detecting Mail Loops
Check the MTA log to ensure that email messages are not bouncing between the Proofpoint Protection
Server and the mail servers on your network.
Proofpoint Protection Server – Configuring the FQDN within Sendmail

Administrators can make additional configurations to sendmail to ensure that the Proofpoint Protection
Server operates more reliably.
In a correct configuration, sendmail on the Proofpoint Protection Server is represented by a fully qualified
domain name (FQDN) – for example, hostname.domainname.com. If your server cannot automatically
determine its hostname and domain name (using DNS), it will usually appear as localhost.localdomain,
resulting in conflicts within your mail routing and delivery system.

Follow this example to configure the FQDN within sendmail:

1. Using a secure shell, log in to the Proofpoint Protection Server system as the user with sendmail
administration privileges.
2. Open the file /etc/mail/sendmail.mc for editing.
3. To define the hostname and domain name for the Proofpoint Protection Server, add the following two
lines to the file:
Cwhostname.domainname.com
define(‘confDOMAIN_NAME',‘hostname.domainname.com')dnl
For example:
Cwpps_host.hq.proofpoint.com
define(‘confDOMAIN_NAME',‘pps_host.hq.proofpoint.com')dnl
5. Stop and start sendmail:
Notes on Customizing the sendmail.mc File
Proofpoint discourages users from customizing the sendmail.mc file from the command line. If you change
the sendmail.mc file by editing the file be aware that the location for this file for an appliance is not
/etc/mail/sendmail.mc, but instead,
${PROOFPOINT_ROOT}/admin/admind/deploy/appliance/sendmail/sendmail.mc.<instance_name>
where instance_name is the fully-qualified instance name for the system.
If you customize the /etc/mail/sendmail.mc file, and then make changes using the Appliance > SMTP
Settings pages, the custom changes you made by editing the file will be overwritten by the changes you
make using the management interface.
This section provides a workaround.

1. Open the file
${PROOFPOINT_ROOT}/admin/admind/deploy/appliance/sendmail/sendmail.mc.<instance_nam
e> for editing.
2. Add your changes to the file. Custom changes must be in between the following lines:
dnl# custom additions below, do not modify this comment
dnl# end custom additions, do not modify this comment

3. Use CVS to check in the sendmail.mc file.
4. Log in as root and issue the following command to apply the changes replacing x.y.z with the
software release number (the following command is one line):
/opt/proofpoint/pps-x.y.z/appliance/systemscripts/pp-sendmail.sh -deploy
<instance_name>
Once you follow this procedure, any changes you make using the management interface will also be
applied to the sendmail.mc file. The /etc/mail/sendmail.mc file and the
${PROOFPOINT_ROOT}/admin/admind/deploy/appliance/sendmail/sendmail.mc.<instance_name>
will be synchronized.
42
Note that if you made changes to the Appliance > SMTP Settings pages you must click Refresh Config
in the management interface to apply the changes to the sendmail.mc files.
Tuning the Spam Detection Module

As part of the Dynamic Update Service, Proofpoint provides you with continuous updates of rules and
weights to ensure that your MLX Engine is up to date.
Since every organization is unique, the Proofpoint Protection Server allows you to optimize spam detection
capabilities through a number of mechanisms. During the first weeks of implementing the Proofpoint
Protection Server, it is important to closely monitor the spam score of messages that your organization
receives and tune the product to meet your specific needs.
To reach the optimal level of effectiveness, follow these recommended steps:

1. Create Global Safe Lists and Global Blocked Lists.
Global Safe Lists and Global Blocked Lists provide an additional level of protection against false
positives and false negatives. You have complete control over these lists through the management
interface.
The most important use of the Global Safe List is to protect messages that tend to score above your
spam threshold and as a result are not delivered to the intended recipient. Messages that typically fall
into this category include newsletters, opt-in publicity (for example, weekly announcements from
airlines, e-tailer catalogs), advertising-based e-groups, and so forth.
Global Safe/Blocked lists take precedence over end user Safe/Blocked lists.
2. Set the spam classification thresholds.
To ensure your email policy is enforced, you can set spam score thresholds that determine spam
classifications and the associated dispositions. While we have designed a spam score of 50 to
represent the breaking point between spam and not spam, depending on the spam and valid email
profile for your organization, you may achieve better results by increasing or decreasing this threshold.
Monitoring of spam scores during the implementation phase will help you gauge the optimal thresholds
for the different spam classifications.
3. Create the Email Firewall Module dictionaries.
Create a number of dictionaries that define undesirable terms. These dictionaries can be used to
provide an additional layer of protection against offensive spam messages. For example, you may
choose to implement the offensive language dictionary which is included with the Proofpoint Protection
Server.
4. Allow the Adult Spam Module to filter pornographic content.
The Spam Detection Module is tuned to detect pornographic content in email messages.
Administrators can add another level of granularity to filtering messages that contain spam and
pornographic content. A message that scores high enough to be classified as spam can be further
classified as “adult spam,” and the rules for such messages can be different from the rules for “all
other” spam.
In summary, the objective of the Spam Detection Module filtering engine is to ensure an optimal spam
detection system with a minimal administrative burden. We believe the spam detection mechanisms
provide the necessary tools for you to fine-tune the Proofpoint Protection Server to meet your specific
needs. Figure 9 illustrates how a message is filtered for spam.

Message
Global Safe List/ Global Blocked List High-level filtering
User Safe/Blocked Senders List

.
.
.
Policies and Rules
Custom-defined Rules
MLX Classification Extensive filtering
Spam Score/Adult Spam Score

Spam classification
80-100 50-80 0-50

Spam Probable Spam Not Spam
Disposition A Continue
Disposition C
And adult content
And adult content
Note: Filtering for adult
Disposition B Disposition D content applies only to
the spam rules Spam
and Probable Spam. Filtering for
adult content does not apply
to the Not Spam rule.
Figure 9. Message disposition for the Spam Detection Module
Synchronize the Cluster with Network Time Protocol

It is very important that the Proofpoint Protection Server or appliance and any systems in a cluster are
synchronized with system time. The following processes and components require accurate timestamps to
be meaningful:
• Messages in the Quarantine. When messages enter the Quarantine, they receive a timestamp. If the
timestamp is not accurate, users could potentially receive messages in their Digests that reflect a time
in the future.
• Logs and Reports. For accurate logging and reporting purposes, the timestamps for log entries must be
accurate.
• Crontab entries. The crontab entries start and maintain processes that are critical to the health of a
cluster. For example, the crontab controls qconsolidate which is the process that collects and
consolidates the messages from the quarantines on the agents to the master quarantine.
• Configuration history. The Proofpoint Protection Server software saves and maintains the configuration
settings at specific points in time so that administrators can “roll back” to a configuration that was
44
working as expected. This convenient safeguard allows administrators to make changes to a cluster
knowing that they have a copy of the configuration settings that they can re-apply if the new settings do
not work as expected or produce undesirable results.
Use Quarantine and DLP Incident Folders to Organize Messages

The Quarantine and DLP Incident Queue include several system folders that you cannot delete. For
example, the pre-existing folders provide a convenient way to organize messages that triggered rules in
the optional Data Loss Prevention modules (Digital Assets Module and Regulatory Compliance Module).
The Deleted folder maintains messages that are manually deleted from the Quarantine, the Audit folder
can store messages for false negative reporting, and the Blocked folder can store messages from spam
senders on the global Blocked Senders list.
When you create a rule and you want a copy of the message that triggered the rule to be placed in the
Quarantine, you designate which folder to use for storing the message. If you do not designate a specific
folder, a copy of the message will automatically be placed in the folder named Quarantine.
Organizing messages into folders in the Quarantine is highly recommended for the following reasons:
• Tracking messages that trigger specific rules. Administrators can create a folder for a specific rule and
store the messages that trigger the rule in the folder for analysis. If the rule is not working as expected
you can make adjustments or changes to the rule.
• Unique folder disposition settings. Each folder has unique characteristics, including an expiration
period for the messages in the folder, or delay messages for a period of time, then resubmit them for
filtering. If you have the optional Zero-Hour Module, you can wait for anti-virus signature updates and
then resubmit messages for filtering. You can apply different expiration periods to different folders,
keeping some messages in a Quarantine folder longer than others.
• Granularity and control to the smallest level. Creating folders for specific rules gives administrators
granular control for storage and analysis of messages in the Quarantine. For example, messages
containing a particular word from a specific sender to a specific recipient with a can be placed in a
unique folder in the Quarantine.
Keep the User Repository Current

You can populate the User Repository by using any of these methods:
• Automatically or manually importing entries from a Microsoft Exchange Server, Microsoft Active
Directory, an LDAP server, Lotus Notes, or a comma-separated value text file.
• Manually adding users or mailing lists to the User Repository.
• Using the auto-populate feature so that any user that receives a Digest because he or she has
messages in the Quarantine will automatically be added to the User Repository when he or she
releases a message or takes an action from the Digest.
When employees leave your organization you can manually remove the entries for the employees from the
User Repository or you can automatically remove them with the LDAP import -removeold option. If you
use the -removeold option, any entries that are not included in the source data are automatically removed
from the User Repository during an import.

Use the Discard Disposition for Unwanted Email

The Discard delivery disposition does not provide the sender of the message any information about your
organization and does not waste network bandwidth. When you create rules to block unwanted messages
from entering your email infrastructure, use the Discard disposition instead of Retry or Reject. Since
spammers typically use spoofing for sending email, you do not want to use Retry or Reject because you will
not get a response from the sender and you do not want the sender to learn a legitimate email address for
your organization.
One example for using the Reject delivery disposition is for messages (or messages containing
attachments) that are over a specific size limit. Create a rule that rejects messages (or attachments) over
the size limit and use the Reply to sender delivery option to let the sender know what your organization’s
policy is for limiting message size.
When you create rules to discard messages containing viruses, create policies for specific email viruses
(such as bagel, mydoom, or netsky, for example). Do not use the Reply to sender delivery option because
these are email viruses that use address books and senders typically do not even know they have been
victimized.
Catching Spam Containing Cyrillic Characters

Many organizations are flooded with spam containing Cyrillic characters. This section provides a sample
Email Firewall Module rule to filter and discard messages containing Cyrillic characters.
To create a rule to discard messages containing Cyrillic characters:

1. Click the Email Firewall Module link in the navigation pane.
2. Click Rules.
3. On the Rules page, click Add Rule.
4. Enter cyrillic into the ID field.
5. Enter Discard Messages Containing Cyrillic Characters into the Description field.
6. Click the link Click here to add a new condition.
7. Make the following selections in the Add Condition pop-up window:
 Condition: Any Part of the Message.
 Operator: Contains.
 Value: charset=windows-1251.
8. Select the Discard radio button for the Delivery Method.
9. Click Save Changes to save the rule.
46
Chapter 6 Maintenance and Troubleshooting
This chapter provides maintenance and troubleshooting information, such as Quarantine clean-up hints
and monitoring and controlling disk space.
If you export log data tables from the Proofpoint Protection Server to import the information into another
reporting tool, see “Log Database Schema” on page 51.
Creating a Query for Outbound Messages In the Quarantine

If the Proofpoint Protection Server or appliance is configured to filter outbound email, outbound messages
that score high enough to be classified as spam will be sent to the Quarantine.
However, since the recipients for the outbound messages are not included in your organization’s User
Repository, they will never receive a Digest that contains these messages. For example, if a user sends an
email to a friend outside of your organization that scores high enough to be quarantined for spam, the
user’s friend is not included in your User Repository and hence will never receive a Digest.
As the administrator, you may want to create a query to search the Quarantine for these messages so that
you can delete them or move them to another folder. This section provides instructions on how to do this.
Follow these steps to create a query to search for outbound messages in the Quarantine:
1. Click the Messages link under Quarantine in the navigation pane.
2. Click the New link to create a query.
3. Enter a name for your query into the Quarantine Search field. For example, from_example_com,
replacing example_com with the domain name for your organization.
4. Enter your organization’s domain into the Sender field. For example, @proofpoint.com.
5. Select Ends With from the drop-down list.
6. Click the Save link.
7. Click the Search button to find the messages in the Quarantine.
Excluding Spammers from the Outbound Message Query

Spammers will try to send email to your organization using your domain name as the sender address. As
spam, these messages will be caught by the Proofpoint Protection Server or appliance and sent to the
Quarantine. When you are searching for outbound messages in the Quarantine, you may want to exclude
the messages that originate from spammers emulating your organization as the original sender. To do this,
your query must search for email originating from an internal IP address in your organization.

Chapter 6 - Maintenance and Troubleshooting
Follow these steps to create a query that excludes messages from spammers using your organization’s
domain name:
1. Click the Messages link under Quarantine in the navigation pane.
2. Click the Advanced Search link.
3. Click the New link to create a query.
4. Enter a name for your query into the Quarantine Search field. For example, from_IPexample_com,
replacing example_com with the domain name for your organization.
5. Enter your organization’s domain into the Sender field. For example, @proofpoint.com.
6. Select Ends With from the drop-down list.
7. Enter your organization’s IP address including a “wild card” into the Sender/Host IP field. For example,
10.10.%.
8. Click the Save link.
9. Click the Search button to find the messages in the Quarantine.
Note: The 10.10.% entry in this example is intended to represent the internal private network. It
can result in a very slow query and you may need to create several queries to include all of
your organization’s internal networks.
Blocking Email with Specific Character Sets

To create an Email Firewall rule to block email messages with a specific character set, you need to
reference the appropriate character encoding. For example you want to block emails that are in Russian,
which use the Cyrillic alphabet. The common character encodings for Cyrillic are Windows-1251 and
KOI8-R.
If you were to look in the original message header, you might see the following text:
Content-Type: text/plain;
charset="koi8-r"
By creating a rule in the Email Firewall that filters for this header, you can block email messages containing
Cyrillic characters. Create a rule where the Condition is Email Headers, the Attribute is Content-Type, the
Operator is Contains, and the Value is koi8-r. Make the Delivery Method for the rule Discard.
Similar rules can be created for other character sets as well. For example, if you want to discard all email in
simplified Chinese, replace koi8-r in the example above with gb2312.
The rules described above will block only those messages that actually specify the character set in the
Content-Type message headers. Some foreign character set email messages specify the character set in
the MIME boundaries rather than in the message headers. To catch these, you must create a rule to look
for the character set anywhere in the message. The rule would also catch any emails that refer to the
character set in the body of the email.
Monitoring and Controlling Disk Space

The Quarantine is comprised of default system folders and folders created by administrators. When
creating rules, administrators have the option of sending messages to specific folders in the Quarantine. If
no new folders are created, all messages are sent to the system folder named Quarantine.
48
Because of the specific data type in the Quarantine data table, you cannot reduce the size of the
Quarantine to free up disk space. Once the Quarantine occupies all of the allocated space, it will always
use that amount of space. When entries are deleted from the Quarantine the size of the Quarantine does
not change; new entries simply populate the available space.
Monitoring the Disk Space
Monitor the disk space usage by checking the Server Status table daily. If your message volume is
thousands per minute, you will need to check it more frequently. Click the Summary link under System in
the navigation pane. Click the Storage icon or expand the information for a server by clicking the plus icon
(+) next to its name.
The PPS Disk Space value reflects the amount of disk space available on the partition where the Proofpoint
Protection Server software is installed. This number includes the software binaries and the database.
The database is comprised of log data tables (logdb), the User Repository, and the Quarantine. Although
all three are stored in a database, the log, User, and Quarantine data tables are different table types. The
most significant difference between the table types is that you can reduce the space occupied by the log
tables but cannot reduce the space occupied by the Quarantine or User Repository data.
Proofpoint Protection Server database
Quarantine data tables
logdb
data User Repository data tables
tables
can reduce cannot reduce the size by

size by deleting tables deleting tables
Freeing Up Disk Space Used by the Quarantine
You can configure Quarantine parameters to delete messages from the Quarantine folders more often,
thus freeing up space in the data table for new messages. Use the Mail Expiration parameter to decrease
the amount of time messages are stored in a folder.
To set expiration parameters:

1. Click the Folders link under Quarantine in the navigation pane.
2. Click the name of the folder for which you want to change the Mail Expiration.
3. Click the Disposition tab on the Edit Folder pop-up window.
4. Change the Messages expired after parameter to a smaller value. For example, if you select 3 Days,
messages that have been stored in the folder for three days will be deleted from the Quarantine,
freeing up space for new messages.

Reducing the Amount of Disk Space Used by the logdb
You can make some configuration changes that will diminish the amount of disk space consumed by the
logdb in the future.
1. Log in to the Proofpoint Protection Server or appliance management interface.
2. Click the Log Settings link under Logs and Reports in the navigation pane.
3. For the Log File Level parameter, select a choice that is higher on the list. The higher the choice, the
less data is collected in the log database. For example, the Reporting choice collects less data than the
Information choice.
4. If you have Syslog Enabled set to On, select a choice that is higher on the list for the Syslog Level
parameter. For example, select Alert instead of Warning.
6. Click the Report Settings link under Logs and Reports in the navigation pane.
7. Enter a smaller number into the Maximum Rows field.
Creating an Alert
Create an alert to send email to the appropriate administrators when the disk space on the Proofpoint
Protection Server or appliance reaches a specified threshold.
To create an alert:
1. Go to the System > Alerts > General page.
2. Under Alert Email Trigger Settings, enter a value into the Available System Disk Space Less Than field.
When the disk space reaches this size an alert email is sent to the recipient listed in the default profile
on the Alert Profiles page.
Proofpoint Protection Server – Freeing Up Disk Space
To free up disk space, you can remove log files stored for the master and agent systems.
On the Master
Log in to the master Proofpoint Protection Server as the user with UNIX administration privileges. For
example, pps.
Change directories to
${PROOFPOINT_ROOT}/var/spool/logxfer
where ${PROOFPOINT_ROOT} is the directory where you installed the Proofpoint Protection Server
software.
In this directory you will find a sub-directory for each agent in the cluster, represented by the fully-qualified
instance name for each agent. For example:
% ls logxfer
queue hostname2-port_pps2 hostname3-port_pps3
50
Change directories to an agent sub-directory. For example:

% cd hostname2-port_pps2
If you list the contents of the directory, you will see entries for sub-directories. For example:
% ls
20081201 20081202 20081203 20081204-150200
Each sub-directory represents a timestamp (YYYYMMDD) for log files collected and processed by the
Proofpoint Protection Server during a log transfer procedure or log rollover. The entry with the dash-hour
stamp (-HHMMSS) has not been processed yet. Do not remove it. To free up disk space, you can remove
the other directories for the days that you do not want to keep the log files. Depending on your
organization’s policies, you may want to archive the log files before deleting them.
Each timestamp directory contains archives for the log data collected. For example,
instance.log.[number].gz.
On the Agent
The procedure for freeing up disk space on an agent system is the same as that of the master with the
exception that the directory location is ${PROOFPOINT_ROOT}/var/log/backup/filter.
Database and NFS
Proofpoint has not certified and strongly recommends against running the Proofpoint Protection Server
software on an NFS file system. If your system should crash running on NFS, the lock on the database will
not be reset, rendering the Proofpoint Protection Server inoperable.
Log Database Schema

This topic presents the log database schema for administrators that export the Proofpoint Protection Server
database tables for import into another reporting tool or storage area for processing.
Notes
The database is comprised of one main message data table and several message-specific tables. The
Message table is the main meta data table. There is a 1-N relationship between the message-specific
tables and the main Message table. The message-specific tables are listed here:
Access
Adult_score
Asset
Attachment
Capture
Content
Dictionary
Digest_info
Disposition
Env_from

Env_rcpt
Favorite_reports
From_host
Job_scheduler
Judge
Loader_status
Message
Module_info
Quarantine_action
Regulation
Secure_message
Service
Session_connect_info
Session_property
Spam
Spam_score
Store
Summary_control
Summary_page
Summary_status
Throttle_ip
User_sync
Virus
Zerohourav
• A message is determined to be inbound or outbound by utilizing message route designations within the
Proofpoint Protection Server. The route designation is defined using a message attribute and an
operator. The message attributes are: Sender IP Address, Sender Hostname, Envelope Recipient, and
Envelope Sender. The operators are: Equals, Does Not Equal, Contains, Does Not Contain, Ends With,
Matches Regular Expression, Does Not Match Regular Expression. The message route is determined by
utilizing policy route framework within the Proofpoint Protection Server.
• Message encryption is determined by messages sent to the recipient domain that is listed in the TLS
domain list (appliance only). This is captured by leveraging the same policy route concept. Internally
the Proofpoint Protection Server auto-creates a “tls” route which is defined as “envelope recipient is in
one of the TLS domains.”
• In the Quarantine_action table, the msg_guid column is a foreign key for msg_guid in the Message
table. Use msg_guid to look up meta data (for example – subject, recipients).
• In the Env_from table, the receiving host or IP is extracted from the sendmail logs via correlation of the
sendmail qui (or envelope ID).
• The default character set is UTF-8 for all tables.
• For importing purposes, all of the destination tables must be UTF-8 compatible.
For the sake of brevity, the following columns are not duplicated (except where noted) for each
message-specific table in the Database Schema description:
row_id Bigint(20) Auto-incrementing integers that hold a
unique number for each row.
timestamp Datetime Date/time message received.
entry_id Varchar(8) The unique log entry ID for a message.
52
host Varchar(64) The hostname for the sytem in the cluster.

instance Varchar(32) The instance name of a system in the
cluster.
message_id Varchar(64) The message ID in a session.
protocol Varchar(32) The network protocol.
route Varchar(64) The Policy Route names, delimeted by
commas.
servicename Varchar(32) The name of the service in an instance - for
example, filter.
session_id Varchar(64) The connection ID for an SMTP session.
Database Schema
The following tables describe the database schema.
Filtered Messages
Table -
Message Column Type Description
Message General message table, contains message meta data, one row per
message.
Row_id Biginit(20) Auto-incrementing integers

that hold a unique number
for each row.
Timestamp Datetime Date/time message

received.
Host Varchar(64) The hostname of the system

in the cluster.
Instance Varchar(32) The instance name of a

system in the cluster.
Servicename Varchar(32) The name of the service in

an instance – for example,
filter.
Session_id Varchar(64) The connection ID for an

SMTP session.
Message_id Varchar(64) The message ID in a

session.
Entry_id Varchar(8) The unique log entry ID for a

message.
Start Biginit(20) The message start time.

Table -
Message Column Type Description
Duration Unsigned float The processing time for a

message.
Elapsed Unsigned float The elapsed time for a

message.
Env_from Varchar(255) The envelope sender

address.
Hdr_from Varchar(64) The sender address for the

message header.
Hdr_message_id Varchar(64) The header message ID.
Msg_size Bigint(20) unsigned The size of the message.
Attachments Tinyint(4) The number of attachments

for the message.
Subject Varchar(255) The message subject.
Msg_guid Varchar(32) The global unique identifier

for the message.
Route Varchar(64) The Policy Route names,

delimited by commas (,).
Protocol Varchar(32) The network protocol.
Module Varchar(32) The module name for the

final disposition.
Rule Varchar(128) The triggered rule name of a

module for the final
disposition.
Action Varchar(32) The final disposition for a

message
Qid Varchar(32) The message envelope ID

(sendmail QID).
Email Firewall Module
Table -
Access Column Type Description
Access Email Firewall module operations table, one operation per message.
54
Table -
Access Column Type Description
Duration Unsigned float The duration of time the message is

processed by the Email Firewall module.
Rule Varchar(32) The triggered rule.
Msg_count Int(10) How many messages were processed.
Attribute Varchar(32) Not used.
Digital Assets Module
Table -
Asset Column Type Description
Asset The Digital Assets module operations table, 1-N per message.

processed by the Digital Assets module.
Env_from Varchar(255) The envelope sender address.
Message Attachment
Table -
Attachment Column Type Description
Attachment Attachment table, one row per attachment (1-N per message).
Type Varchar(32) Attachment type.
File Varchar(255) Attachment file.
Size Bigint(20) Attachment size.
Content Table
Table -
Content Column Type Description
Content Content filtering module operations table (1-N per message).
Name Varchar(16) The name of the Content module.

processed by the Content module.

Table -
Content Column Type Description
Route Varchar(255) The Policy Route names, delimited by

commas (,).
Dictionary
Table -
Dictionary Column Type Description
Dictionary Dictionary module operations table (1-N per message).
Name Varchar(32) The name of the Dictionary module.

processed by the Dictionary module.
Score Decimal(5.2) Not used.
Message Disposition
Table -
Disposition Column Type Description
Disposition The message disposition table (1-N per message).
Type Varchar(32) The action on the message.
Module Varchar(32) The name of the module where the rule was
triggered to cause the delivery disposition.
Envelope Sender
Table -
Env_from Column Type Description
Env_from The message envelope sender table, one per message.
Env_from Varchar(255) The envelope sender.
56
Table -
Env_from Column Type Description
reverse_env_from Varchar(255) The reverse address of the

envelope sender.
Spam Tinyint(4) A flag to indicate whether or not

the envelope sender is a spam
sender.
Adultspam Tinyint(4) A flag to indicate whether or not

the envelope sender is an
adultspam sender.
Virus Tinyint A flag to indicate whether or not

the envelope sender sends
messages containing a virus.
TLS Varchar(32) The TLS Cipher name (the value

is empty if not encrypted).
Envelope Recipient
Table -
Env-rcpt Column Type Description
Env_rcpt The envelope message recipients table, one per message recipient (1-N
per message).
Env_rcpt Varchar(255) The envelope recipient.
reverse_env_rcpt Varchar(255) The reverse address of the

envelope recipient.
Spam TinyInt A flag to indicate whether or not

the envelope recipient received a
spam message.
Adultspam Tinyint A flag to indicate whether or not

adult spam message.
Virus Tinyint A flag to indicate whether or not

message containing a virus.

Error
Table -
Error Column Type Description
Error Stores the errors or critical entries stored in the filter.log files.
Level Varchar(8) Filter log level for this entry.
Err_msg Varchar(255) The remainder of the log line.
Job Scheduler
The job_scheduler table is the control table for scheduled reports.
Favorite Reports
The favorite_reports table stores configuration information for the Favorite Reports feature.
From Host
The from_host_daily table stores hourly data for certain high-volume tables.
Judgement
Table -
Judge Column Type Description
Judge The final message judgement table (1-N per message).
Module Varchar(32) The name of the module that produced

the final judgement for the message.
Rule Varchar(128) The rule triggered to cause the final

judgement for the message.
Session Connection Information
Table -
Session_connect_info Column Type Description
Session_connect_info The milter session connection table, one per milter connection.
These values are recorded at the beginning of a session.
Start Bigint(20) The start time for a

connection.
From_ip Varchar(16) The IP address where

the connection
originated.
58
Table -
Session_connect_info Column Type Description
From_host Varchar(255) The hostname where

the connection
originated.
Msg_count Int The total message

count of a connection.
Msg_size Bigint The total size of all

messages in a
connection.
Spam_count Tinyint The total number of

messages containing
spam in a connection.
Adultspam_count Tinyint The total number of

messages containing
adultspam in a
connection.
Virus_count Tinyint The total number of

messages containing a
virus originating from a
connection.
Attachment_count Int The total number of

attachments for
messages originating
from a connection.
Reverse Varchar(64) The hostname of the

connection obtained
from a reverse lookup.
Helo_domain Varchar(64) The helo domain for the

originating connection.
Route Varchar(255) The Policy Route

names, delimited by
commas (,).

Milter Session Connection Information
Table -
Session_property Column Type Description
Session_property The milter session connection information table (continued), one

per milter connection. These values are recorded at the end of a
session.
Duration Float unsigned The total duration time for

a connection.
Message_count Int(10) The total number of

messages for a
connection.
Rcpts Int(10) The total number of

recipients for a
connection.
Module Varchar(32) The module name for the

final disposition.
Rule Varchar(128) The triggered rule name

of a module for the final
disposition.
Action Varchar(32) The final disposition for a

message.
Spam Detection Module
Table -
Spam Column Type Description
Spam The Spam Detection operations table (1-N per message).
Duration Float unsigned The duration of time the

message is processed by
the Spam Detection
module.
Ruleset Varchar(64) The name of the Policy

that contains the rules for
that policy.
Rule Varchar(128) The triggered rule (for a

Policy).
Spam_score_normalized Decimal(5.2) The normalized spam

score for the message.
60
Table -
Spam Column Type Description
Adultscore Decimal(5.2) The adultspam score for

the message.
Table -
Adult_score Column Type Description
Adult_score Keeps counts per hour of how many messages were seen of each adult
score number.
Adultscore Int(10) For the given period

(hour, day, month), this
row contains one of the
adultscores that were
seen (0-100).
Msg_count Int(10) The count of how many

messages were seen in
that time period with the
adultscore. The table
maintains distinct rows for
each time, route, protocol.
host, instance,
servicename, and
adultscore combination.
Virus Protection Module
Table -
Virus Column Type Description
Virus The Virus Protection operations table (1-N per message).
Duration Float unsigned The duration of time the message is

processed by the Virus Protection
module.
Rule Varchar(32) The triggered rule (not used).
Cleaned Tinyint(4) Whether or not the virus was cleaned

from the message.
Name Varchar(32) The name of the virus.
Vendor Varchar(32) The name of the vendor for the Virus

Protection module.

End User Digests
Table -
Digest_info Column Type Description
Digest_info Digest generation history table.
Row_id Bigint(20)
Timestamp datetime The date and time for

completion of the
Digest generation.
Generation_time int unsigned The time duration (in

seconds) for Digest
generation.
Quarantine_message_count int unsigned The number of

messages in the
Quarantine.
Digest_count int(10) unsigned The number of Digest

email messages
generated.
Invalid_recipients_count int(10) unsigned The number of invalid

recipients
encountered during
Digest generation.
Message_count int(10) unsigned The number of

processed messages
in the Quarantine.
Type varchar(32) The type of Digest,

update or summary.
Quarantine
Table -
Quarantine_action Column Type Description
Quarantine_action The table for actions performed on the Quarantine (from users and
administrators). One row per operation.
Timestamp datetime The date and time of the

action performed on the
Quarantine.
62
Table -
Quarantine_action Column Type Description
Cmd_type varchar(32) The type of action

performed (release,
redirect, report_FN,
report_FP, report_other).
Msg_count int(10) unsigned Not used (always 1).
User varchar(32) Who performed the action

(administrator, system,
enduser, emailaddr).
Msg_guid varchar(32) The global unique identifier

for the message.
Cmd_data varchar(80) Action-specific data. For

report_*, it is msgref of mail
sent to the Proofpoint
update server.
Note: The Quarantine_action table does not include Protocol and Route columns.
LDAP Import
Table -
User_sync Column Type Description
User_sync The LDAP synchronization table. One row per sync operation.
Timestamp datetime The date and time the

synchronization completed.
Duration int(10) unsigned The duration in seconds for the

synchronization.
Inserted int(10) unsigned The number of inserted user

entries.
Updated int(10) unsigned The number of updated user

entries.
Deleted int(10) unsigned The number of deleted user

entries.
Profile Varchar(128) The Groups and Users import or

authentication profile.
Note: The User_sync table does not include Protocol and Route columns.

Zero-Hour Anti-Virus Module
Table -
Zerohourav Column Type Description
Zerohourav The Zero-Hour Anti-Virus operations table.
Duration Float(12,6) The duration of time the message is

processed by the Zero-Hour
Anti-Virus Module.
Virusthreat varchar(64) The virus threat level -high or

medium.
Virusthreatid varchar(128) The virus threat ID. (Not used in this

release.)
Name varchar(64) The virus name.
Rule varchar(64) The name of the triggered rule.
Scan_number tinyint(4) The sequence number for a

message scanned by the Zerohour
module.
Init_scan_time bigint(20) The timestamp for the first message

scan.
Route Varchar(255) The Policy Route names, delimited

by commas (,).
Messages Delayed in a Quarantine Folder
Table - Store Column Type Description
Store The table that contains the messages stored in Quarantine folders.
Module varchar(32) The name of the module that caused a

message to be stored.
Rule varchar(128) The rule that triggered causing a

message to be stored.
Folder varchar(32) The name of the folder where the

message is stored.
Duration float(12,6) The duration of time for storing a

message.
64
Summary Control
The Summary_control table maintains internal data summarization status information.
Summary Page
The Summary_page table maintains internal data collected for the management interface Summary Page.
Summary Status
The Summary_status table maintains internal summarization performance statistics.
SMTP Rate Control
Table -
Throttle_ip Column Type Description
Throttle_ip The SMTP Rate Control throttle activity table.
ip varchar(16) The IP being throttled.
Module Information
Table -
Module_info Column Type Description
Module_info The table contains module information for the addition of future modules.
Module Varchar(32) The name of the module.

processed by the module.
Attribute Varchar(32) Not used.

Regulatory Compliance
Table -
Asset Column Type Description
Regulation The Regulatory Compliance module operations table, 1-N per message.

processed by the Regulatory Compliance
module.
Env_from Varchar(255) The envelope sender address.
Proofpoint Encryption
Table -
Secure_message Column Type Description
Secure_message The Proofpoint Encryption operations table.
Module Varchar(32) The name of the module.
Profile Varchar(64) The Secure Message Profile.
Action Varchar(32) The disposition for the message.
Rcpts_count int(10) Number of recipients to which the

encrypted message is sent.
66
67
Chapter 7 Message Filtering
This chapter describes the path of a message through the Proofpoint Protection Server filtering modules.
When a message triggers several rules in several filtering modules, the Proofpoint Protection Server must
determine which disposition to apply to the message and to which Quarantine folder to send a copy of the
message.
While most email filtering products accept an email message and process it in its entirety, the Proofpoint
Protection Server extends granular analysis to the components that make up an email message. Some
rules are triggered immediately, as soon as a single message processing callback or MIME type is
analyzed. Other rules are triggered only after all of the components of the entire message are analyzed –
for example, at the end-of-body component of the message. It is this granularity that enables Proofpoint to
control the flow of messages at the connection point or at any time during the filtering process.
To predict the final outcome for a message, it is important to understand the concept of execution priority
and action importance across all of these areas: the SMTP protocol message processing callbacks,
filtering modules, delivery dispositions, rule ordering, and Quarantine folders. A strict descending priority
exists across all of these areas. For example, the last action applied to a message does not necessarily
determine its outcome – instead, the most important (influential, decisive) action that happens to a
message during its course through the filtering process determines its outcome.
The concept of priority and importance of events includes exceptions for composite rules that are
comprised of many conditions joined with the logical operators AND or OR. The outcome from a composite
rule depends upon which message processing callbacks trigger the rule, and whether or not the rule is
triggered immediately – for example, at the connection component, or only at the end-of-body component.

Chapter 7 - Message Filtering
The Path of a Message through the Filtering Process

The following figure illustrates the path of a message through the filtering process. For each SMTP protocol
message processing callback and MIME part of a message, the order of events is applied from left to right,
and the precedence within each event is applied from highest to lowest.
Highest Filtering Events
1. SMTP Protocol 2. Filtering modules 3. Delivery dispositions 4. Quarantine folder

(and rule ordering)3
Throttle Virus Protection

Connection
Email Firewall (and
(IP, Helo)
Custom Spam rules) Execute
Spam Detection
Envelope
(mail from, rcpt to...) Quarantine
Precedence
Data Virus Protection Digital Assets

Secure
Headers
Size Spam Detection Reject Regulatory Compliance
MIME parts1 Regulatory Compliance Retry Email Firewall (and recipient

(Attachment, body verification)
- HTML/text)
Digital Assets Redirect
End-of-body2
and Discard
composite conditions Audit
using AND logical
operator Deliver Now
Lowest Continue
Notes:
1 – Detect virus, compute the Digital Assets and Regulatory Compliance module scores.
2 – Compute the spam score, trigger the Spam Detection module rules. Trigger the Digital Assets and
Regulatory Compliance scores based upon MIME parts analysis.
3 – When more than one rule is triggered in the same module, and different Quarantine folders are specified
for each rule, a copy of the message is stored in the folder for the first rule that is triggered in the module. (See
page 73 for more information on rule ordering.)
Figure 1. Filtering Events in Order
The Proofpoint Protection Server analyzes the message processing callbacks and MIME parts of a
message. Some of the message processing callbacks are unique, in that they can have only one value –
for example, the connection IP. Other callbacks, such as recipient, for example, can include more than one
value per message.
connect – 1 only
helo – 1 only
mail from – 1 only
rcpt to – 1 or more
data – 1 only
header – 1 or more
bodypart (MIME parts) – 1 or more (example: HTML + text + attachments)
end-of-body
70
Important: Each of the message processing callbacks and MIME parts is processed by each of
the filtering modules, one message processing callback or MIME part at a time. If a
message processing callback is comprised of more than one value, each value is
analyzed by the Proofpoint Protection Server.
Since a single message can potentially trigger many different rules across all of the filtering modules, and
each rule can apply unique dispositions to the message, how does an administrator determine the “final
disposition” of messages that trigger a rule?
The answer is that it depends upon the order in which the message processing callbacks are processed,
and the priority assigned to each component of the filtering process, and how the Proofpoint Protection
Server processes messages that trigger composite rules. To predict the outcome of a message after it has
been filtered by the Proofpoint Protection Server, you must consider the priority and importance of filtering
events used for processing and realize that precedence within each event is important – that is, the criteria
highest on the list will weigh more, or take priority over criteria lower on the list.
You also have to consider that messages that trigger composite rules may behave differently than
expected. The processing for AND conditions is different than the processing for OR conditions, and some
rules will trigger early, at the connection point (unless you add the condition Defer Processing Until End of
Message), and other rules will only trigger at the end-of-body point of message analysis.
Criteria for Analyzing and Determining the Outcome of a Message
The outcome of a message is determined by these factors: the specific order of filtering events, and the
precedence, or importance, of the action applied within each filtering event. The combination of the filtering
event order and the importance of actions applied in an event ultimately determine the final outcome for the
message. As illustrated in Figure 1, filtering events take place in the following order:
1. SMTP protocol message processing callbacks and MIME parts
2. Filtering modules
3. Delivery dispositions
4. Rule ordering within a filtering module and Quarantine folder destination
1 – SMTP Protocol
The SMTP protocol message processing callbacks are processed in a specific order. For example, if a
message is comprised of message processing callbacks that trigger a rule for both envelope criteria and
body criteria, the rule for the envelope criteria will trigger before the rule for the body criteria, and it will take
precedence, or take priority over the rule for the body criteria. Message processing callbacks are filtered in
this order:
1. Connection (IP and HELO)
2. Envelope (mail from and rcpt to...)
3. Data
4. Headers, end-of-header
5. Body (MIME parts, attachments)
6. End-of-body
7. Conditions that are combined with the AND logical operator are applied at end-of-body, and have the
lowest precedence, if the composite rule requires analysis of the entire message before the rule can
trigger. For example, a rule with a condition for headers will trigger first, before a rule with a condition

for connection AND envelope recipient, even though connection is higher on the list than headers and
envelope recipient is higher on the list than headers.
If the conditions for the rule are met for the same message processing callback, the rule can trigger
without having to analyze the entire message. For example, a rule with the conditions file extension
equals zip AND file size is greater than or equal to 5000 bytes will trigger when both of these conditions
are met during the message processing callback.
2 – Filtering Modules
Messages are processed by the filtering modules in a specific order. For example, if a message triggers a
rule in the Email Firewall module and in the Regulatory Compliance module, the Email Firewall rule will
trigger first. The filtering modules take precedence in the following order:
1. Email Firewall
2. Spam Detection Custom Rules, Global Safe List and Global Blocked List
3. Virus Protection
4. Spam Detection
5. Regulatory Compliance
6. Digital Assets
3 – Delivery Dispositions
The delivery dispositions are applied to a message in a specific order. For example, if a message triggers a
rule that strips an attachment from it and triggers another rule that re-routes it to a different SMTP server,
the attachment will be stripped before the message is re-routed. Message dispositions are applied in the
following order:
1. Throttle – for SMTP rate control. For example, if 100% of the messages from any sending IP or domain
contain a virus, restrict all messages from the sending IP or domain to x number of messages.
2. Execute – apply an action. For example, remove an attachment from a message because the
attachment is an executable file.
3. Quarantine – send a copy of the message to the Quarantine, after filtering it through all the modules
and saving metadata with the message. For more information, see , “Sending Copies of Messages to
the Quarantine” on page 74.
4. Secure – encrypt the message.
5. Reject – permanently reject the message from the sender with an SMTP return code.
6. Retry – temporarily reject the message from the sender with an SMTP return code.
7. Re-route – re-route the message to a different SMTP server.
8. Discard – accept the message from the sending host or IP connection and quietly discard it without
providing any information to the sending host.
9. Deliver Now – deliver the message to the recipient without further filtering.
10. Continue – continue processing the message through all other filtering modules, and if this is the last
disposition, deliver the original message to the original recipient.
72
4 – Quarantine Folders and Rule Ordering
If a message triggers more than one rule within the same module, and each rule sends a copy of the
message to a different Quarantine folder, the message will be sent to the folder for the rule that triggers
first. When two rules are computed in the same callback, the rule that triggers first is the highest rule on the
list of rules in the SMTP protocol message processing callback order (connection, envelope, data,
headers, body, end-of-body). You can move rules up and down the list of rules within a module to control
the rule priority.
If a message triggers more than one rule across different modules, and for each module the message is
copied to a different Quarantine folder, the message will be copied to the folder for the filtering module that
is highest on the precedence list. Note that the Quarantine folders precedence list is not the same as the
filtering modules precedence list on page 72. Messages are copied to Quarantine folders across modules
with the following precedence:
1. Virus Protection
2. Spam Detection
3. Digital Assets
4. Regulatory Compliance
5. Email Firewall and recipient verification
The Audit folder stores messages for auditing purposes. Any rule that is triggered by a message can send
a copy of the message to the Quarantine Audit folder. The most common use for storing messages in the
Audit folder is for reporting false-negatives to Proofpoint. These messages are classified as notspam,
because they do not trigger any spam detection rules, and are addressed to at least one recipient that is
included in a group that is auditing messages.
Note that messages with a final disposition of Discard or Reject cannot be included in the Audit folder, since
the Include in Audit folder option is not available for the Discard or Reject dispositions.
Message Processing and Composite Rules
Composite rules that are comprised of many conditions combined with the AND or OR logical operators
can affect the outcome and predictability of the filtering event order, and affect the precedence of the action
applied within each filtering event.
Messages are comprised of some unique components (for example, connection IP), and potentially
multiple components (for example, recipient, or MIME parts).
The Proofpoint Protection Server represents the value of a single component as a Perl scalar. For
example, $rcpt = value.
Values for multiple components of the same type are represented as Perl functions. For example,
rcpt('string_to_check_for') = true/false.
Examples:
If a condition for a rule is filtering for a single value, it is represented as

$rcpt = user1@example.com.

If a composite rule is filtering for several conditions (of the same type) strung together with the logical
operator OR (recipient equals user1@example.com OR user2@example.com OR
user3@example.com), it is represented as:
rulename.condition.1 = $rcpt = user1@example.com
If a composite rule is filtering for several conditions (of the same type) strung together with the logical
operator AND (recipient equals user1@example.com AND user2@example.com AND
user3@example.com), it would be represented as:
rulename.condition.1 =
((rcpt('user1@example.com'))&&(rcpt('user2@example.com')&&(rcpt('user3@example.com'
)))
In summary, OR conditions are represented as individual conditions with scalars, and AND conditions are
represented as one condition with functions.
This distinction is important because a composite rule with OR conditions can trigger as soon as a single
condition is met for a message component, and a composite rule with AND conditions may only trigger after
processing all of the components of the message. For example, if you create a rule to trigger if:
body of the message contains xxx AND message has attachment with file extension zip, delete the
attachment and place a copy of the message in the Quarantine
the execute disposition (delete the attachment) will not happen until the entire message is filtered because
the filtering engine is looking for xxx in the body of the message, so the Proofpoint Protection Server has to
process the entire message until end-of-body. You expect a message containing xxx in the body AND a zip
attachment to have the attachment stripped from the message for the final disposition. But that will not
happen because by the time the filtering engine has found xxx in the body it cannot “go back” and delete
the attachment.
In summary, a message that triggers composite rules with OR conditions will trigger as the conditions are
found in the message processing callbacks and MIME parts. A message that triggers composite rules with
AND conditions will trigger the rules at the end of message processing.
Sending Copies of Messages to the Quarantine
Any time you configure a rule to send a copy of a message to the Quarantine, all of the message
processing callbacks and MIME parts of the message will be filtered, no matter which final disposition you
choose for the original message. This is because the entire message is processed through all of the
filtering modules when a copy of it is sent to the Quarantine. For example, if a message triggers ruleA that
immediately discards it, you would expect no more filtering to take place on the message. This is true as
long as ruleA does not also send a copy of the message to the Quarantine. If the same ruleA sends a copy
of the message to the Quarantine, the message will continue to be filtered by all of the other filtering
modules, and if any other rules are triggered, all of the information from the triggered rules is stored as
metadata with the message in the Quarantine. The final delivery disposition of the original message is
determined by the processing precedence and action precedence on the message.
74
Authoritative Rules
To protect your network from email hazards, rules that you create for the Email Firewall module and Virus
Protection module provide the option of enforcing dispositions that are authoritative. A rule that is
authoritative has a disposition of Deliver Now (Email Firewall only), Reject, Retry, Discard, or Re-route, and
once triggered, stops all further processing on the message.
Note: No further processing for authoritative rules is only applied if the rule does not also place a
copy of the message in the Quarantine.
For example, if you create a rule in the Virus Protection module that discards any message containing virus
X, all messages containing virus X are discarded with no further processing or filtering, unless the rule also
sends a copy of messages containing virus X to the Quarantine. In the case where a copy of the message
is sent to the Quarantine, the filtering and processing continues on the messages that contain virus X.
The Spam Detection, Regulatory Compliance, and Digital Assets modules do not support authoritative
rules. No matter what disposition you choose for messages that trigger a rule in these modules, each
message will be processed through all filtering modules. For example, if you create a rule for the Digital
Assets module with a Discard disposition, messages that trigger this rule will continue to be processed
through all other modules, regardless of whether or not a copy of the message is sent to the Quarantine. If,
however, you want to view the metadata associated with every rule that was triggered by a message, then
the rule must send a copy of the message to the Quarantine.
Delivery Dispositions and Delivery Options
For each delivery disposition (Continue, Deliver Now, Reject, Retry, Discard, and Re-route), several delivery
options are available. Some examples of delivery options include adding a header with a spam score,
changing a subject header, and forwarding an original message to another recipient. All delivery option
information is saved as metadata along with the message when a copy of the message is sent to the
Quarantine.
Note: If the delivery option for a triggered rule is Annotate message, the message annotation is
not stored as metadata in the Quarantine along with the message.
Recipient Verification in the Email Firewall
The Email Firewall module includes support for Recipient Verification, where the existence of a legitimate
recipient address is verified before processing or filtering a message. The Proofpoint Protection Server can
use several sources (Verification Data Connectors), for the purposes of verifying legitimate recipient
addresses. Examples of Data Connectors include an LDAP profile, the entries in the User Repository, an
SMTP server that supports SMTP VRFY, or a custom data connector developed by Proofpoint.
Administrators configure Recipient Verification in the Email Firewall using these methods:
• On a per-message basis. Administrators can create a global rule that applies a disposition to a
message that is not delivered to any recipients. The default settings for this method are to silently
discard messages that do not have any valid recipients. If the Proofpoint Protection Server cannot
connect to the verification source, the default setting is to try to connect again later (Retry - temp fail).
• On a per-recipient basis. Administrators can create individual rules that apply a disposition to a
message depending upon whether the message has one valid recipient, more than one valid recipient,
or no valid recipients. If a message is addressed to several recipients, a default rule is provided to

remove the invalid recipients from the message and continue to filter the message for the valid
recipients.
For each of the dispositions, a copy of the message can be placed in a Quarantine folder. If the message is
addressed to several recipients, some of which are valid and some of which are not valid, only one copy of
the message is placed in the Quarantine.
Recipient-based Rules
Complex rules that you create with the AND logical operator that include a recipient-based condition may
not behave as you expect. Envelope splitting occurs when a message is addressed to several recipients,
and the recipients have different Spam Policy attributes. Envelope splitting also takes place when a
message is addressed to several recipients, and the recipients have different settings (Yes or No) for the
Filter Email (Opt In/Opt Out) attribute. If you have deployed Proofpoint Encryption, envelope splitting takes
place. These are the only circumstances in which envelope splitting takes place.
Envelope splitting does not take place for some rules when the rule contains several recipient-based AND
conditions. For example, an email message is addressed to three recipients: user1, user2, and user3.
The rule
recipient equals user1 AND recipient equals user2 AND message body text contains xxx discard the
message
will discard a message addressed to user1, user2, and user3, because by the time the filtering engine has
found the text xxx in the body, it cannot “go back” and split the envelope to apply the rule to only the first
two recipients in the envelope criteria.
Another example for a recipient-based rule is when an administrator wants a rule to trigger based upon an
IP connection, but only for specific routes defined by recipient addresses. Since the connection criteria
would trigger the rule immediately, the filtering engines would not have a chance to analyze the message
for the specific recipient-based Policy Routes.
The Defer Processing Condition
In cases where administrators create rules based upon envelope or connection criteria, or create rules that
require the filtering engines to analyze all of the components of a message before triggering any rules,
administrators can use the Defer Processing Until End of Message condition. Using the AND logical
operator, append the Defer Processing Until End of Message condition to the other conditions required to
trigger the rule.
Putting It All Together

When you build many rules across all of the Proofpoint Protection Server modules, and a message triggers
several of the rules, predicting the final outcome for the message can be challenging. This section presents
some examples to help clarify the logic behind the processing that determines the final outcome for a
message.
76
For each example, a figure illustrates the sequential filtering process from left to right, where different rules
trigger as the message is filtered. For each rule that is triggered, dispositions with more precedence and
delivery options are shown in bold font in each event in the process. The final disposition applied to the
message is the last event in the process.
Rules Triggering in the Same Module
When several rules are triggered in the same filtering module, the rule with the highest priority delivery
disposition takes precedence.
Example 1
In Example 1 a message triggers several rules in the same module, but each rule applies a different
delivery disposition or delivery options.
Example 1 – a message triggers all of the following rules in the Email Firewall module:
Rule 1 – disposition is Quarantine and Discard.
Rule 2 – disposition is Deliver Now.
Rule 3 – disposition is Discard.
Rule 4 – disposition is Continue, and add an x-header.
Rule 5 – disposition is Continue, and change the subject header.
Figure 2. Example 1 – filtering in the same module

Outcome:
• A copy of the message is placed in the Quarantine (Rule1) because Quarantine is higher on the
delivery disposition list (see “3 – Delivery Dispositions” on page 72) than Deliver Now, Discard, or
Continue.
• The quarantined message will include the x-header and subject header information in it from Rule 4
and Rule 5 because messages sent to the Quarantine will continue to process through all modules,
triggering all rules that apply.
• The original message is ultimately discarded (the original recipient does not get it) because Discard
(Rule 1) is higher on the list than Deliver Now (Rule 2) and Continue (Rule 4).
Example 2
Example 2 illustrates a different outcome for a message that triggers several rules in the same module.
Example 2 – a message triggers all of the following rules in the Email Firewall Module:
Rule 1 – disposition is Quarantine and Continue.
Rule 2 – disposition is Deliver Now.
Rule 3 – disposition is Discard.
Rule 4 – disposition is Continue, and add an x-header.
Rule 5 – disposition is Continue, and change the subject header.
78
Outcome:
• A copy of the message is placed in the Quarantine (Rule 1) because Quarantine is higher on the
delivery disposition list than Continue, Deliver Now, or Discard.
• The quarantined message will include the x-header from Rule 4 and subject header information from
Rule 5 because messages sent to the Quarantine will continue to process.
• The original message is discarded (the original recipient does not get it) because Discard (Rule 3) is
higher on the priority list than Continue (Rule 1, Rule 4) and Deliver Now (Rule 2).
Example 3
In Example 3, a message triggers two rules in the Email Firewall module. The rule that takes precedence is
based upon the message processing callback priority.
Example 3 – a message from userB@proofpoint.com triggers the following rules in the Email Firewall
module:
Rule 1 – Composite rule: the sender IP address equals 127.0.0.1 AND the envelope sender contains
proofpoint. The disposition is Discard the original message.
Rule 2 – The envelope sender contains userB. The disposition is accept the message and Deliver Now.
Outcome: the message is delivered to the recipient (Rule 2) without further processing because envelope
criteria has higher priority than conditions that are strung together with the AND logical operator (Rule 1) in
the SMTP protocol priority. (See “1 – SMTP Protocol” on page 71.)

Rules Triggering Across Modules
When several rules are triggered across different modules the rules from the highest priority filtering
module take precedence. If each rule sends a copy of the message to a different Quarantine folder, the
message is copied to the folder for the module with the highest Quarantine folder priority.
Example 1
Example 1 illustrates the outcome for a message that triggers rules with different delivery dispositions and
sends copies of the message to different Quarantine folders across two different modules.
Example 1 – a message triggers the following rules in the Email Firewall and Virus Protection modules:
Rule 1 – Email Firewall module. The disposition is to place a copy of the message in the Quarantine
folder named quarantine and Continue processing the message.
Rule 2 – Email Firewall module. The disposition is Continue processing the message and add an
x-header to the message.
Rule 3 – Virus Protection module. The disposition is place a copy of the message in the Quarantine
folder named virus and Discard the original message.
Figure 5. Example 1 – filtering across modules
80
Outcome:
• The rules for the Email Firewall (Rule 1 and Rule 2) will trigger before the rule for the Virus Protection
module (Rule 3) because Email Firewall has a higher priority than Virus Protection.
• A copy of the message is sent to the Quarantine (Rule 1) because Quarantine is higher on the
disposition order than Discard or Continue. The copy will contain the x-header (Rule 2) because when
a copy of a message is sent to the Quarantine it will continue processing.
• The copy of the message will be placed in the folder named virus because the Quarantine folder for the
Virus Protection Module (Rule 3) has higher priority than the Quarantine folder for the Email Firewall
module (Rule 1).
• The original message will be discarded because Discard (Rule 3) has a higher priority than Continue
(Rule 1, Rule 2) in the disposition order.
Example 2
Example 2 is similar to Example 1, but the message triggers a custom rule in the Spam Detection module.
Example 2 – a message triggers the following rules in the Email Firewall and Spam Detection modules:
Rule 1 – Email Firewall module. If the envelope recipient equals userA place a copy of the message in
the Quarantine folder userA, and Continue to process the message.
Rule 2 – Spam Detection module. If the spam score for a message is greater than or equal to 95, place
a copy of the message in the Quarantine folder extreme_spam and Discard the original message.
Rule 3 – Spam Detection module. Custom rule: if a message contains the word xxx, set the spam
score to 99.

Figure 6. Example 2 – filtering across modules
Outcome:
• The rule for the Email Firewall (Rule 1) triggers first, and since Quarantine is higher on the disposition
list than Discard or Continue, the message continues to process.
• Custom Spam Detection (Rule 3) is higher than Spam Detection (Rule 2) on the module precedence
list, so the score of the message is set to 99. The original message is discarded because Discard (Rule
2) has higher precedence than Continue (Rule 1).
• The copy of the message is sent to the Quarantine folder named extreme_spam (Rule 2) instead of
userA (Rule 1) because the Quarantine folder for the Spam Detection module has higher priority than
the Quarantine folder for the Email Firewall module.
82
Use Case Examples

This section contains more use case examples for the final disposition of a message when different rules
are triggered in the Email Firewall, Spam Detection, and Virus Detection modules.
The Proofpoint Protection Server is configured with the following rules:
Rule 1 – Email Firewall module. Recipient Verification is enabled. If a message is addressed to an Invalid
Email Address, the disposition is to send a copy of the message to the Quarantine folder named
invalid_recipient.
Rule 2 – Email Firewall module. The rule triggers if a message does not contain body text. The Condition is
Message Body Text, the Operator is Does Not Match Regular Expression, and the Value is \S. The
disposition is Discard the original message and send a copy to the Quarantine folder named empty_body.
Rule 3 – Virus Protection module. If the message contains a virus, Discard it and send a copy of the
message to the Quarantine folder named contains_virus.
Rule 4 – Spam Detection module. If the message scores greater than or equal to 80, Discard it and send a
copy of the message to the Quarantine folder named extreme_spam.
Rule 5 – Spam Detection module. If the message is classified as adult spam category, Discard it and send
a copy of the message to the Quarantine folder named porn.
Rule 6 – Spam Detection module. If the message scores 50 or more, but less than or equal to 79, classify it
as probablespam, Discard it, add an x-header, and send a copy of the message to the Quarantine folder
named quarantine.
Rule 7 – Spam Detection module. If a message scores 49 or less, add an x-header, classify it as notspam,
and Continue to process the message.
Case 1: Message has invalid recipient, no body, and no subject.

Outcome 1:
• Rule 1 triggers first because the recipient is invalid and applies the Quarantine disposition, so the
message continues to process.
• Rule 2 triggers next because the message has no body text.
• Rule 4 triggers next. If a message has no subject text, the MLX engine automatically gives it a spam
score of 80. The original message is discarded, and a copy of the message is sent to the Quarantine
folder named extreme_spam, because the Quarantine folder for the Spam Detection module folder is
higher on the precedence list than the Quarantine folder for the Email Firewall module.
Case 2: Message has invalid recipient and no body, but does include a subject.
Outcome 2:
• Rule 2 triggers next because the message has no body text.

• Rule 7 triggers next, giving the message a spam score that is less than 49 because the message has a
subject header. Rule 7 classifies the message as notspam, adds an x-header, and applies the Continue
disposition to the message. Since no other rules are triggered, the original message is discarded. A
copy of the message (with the added x-header) is sent to the Quarantine folder invalid_recipient.
Case 3: Message has invalid recipient and includes pornography.

Outcome 3:
• Rule 5 triggers next, classifying the message as adult spam. Rule 5 applies the Discard disposition to
the original message, and a copy of the message is sent to the Quarantine folder porn because the
Quarantine folder for the Spam Detection module has higher precedence than the Quarantine folder for
the Email Firewall module.
Case 4: Message has invalid recipient, includes subject, includes body, does not contain a virus.
Outcome 4:
• Rule 2 does not trigger because the message contains body text.
• Rule 3 does not trigger because the message does not contain a virus.
• Rule 4 does not trigger because the spam score is less than 80.
• Rule 5 does not trigger because the message is not classified as adult spam.
• Rule 6 does not trigger because the message scores less than 50.
• Rule 7 triggers because the spam score is less than 49, and the message is classified as not spam.
The disposition Continue is applied to the message, and an x-header is added to the message. The
original message is not delivered because the recipient is invalid. A copy of the message with the
x-header from Rule 7 is sent to the Quarantine folder named invalid_recipient for the Email Firewall
module from Rule 1.
84
Chapter 8 Command Line Interface
This chapter describes the command line interface to the Proofpoint Protection Server.
Several tasks can be completed from a command line interface:

• pps_ctrlpoint – for tagging and pushing configuration changes. See page 85.
• pps_control – for starting and stopping processes. See page 88.
• useradm – for managing users. See page 90.
• groupadm – for managing groups. See page 101.
• qdbutil – for Quarantine management. See page 104.
• dautil – for managing the Digital Assets Module. See page 108.
• logdbutil – for managing the log database. See page 110.
• log_upload – for collecting and uploading diagnostic and log information immediately to Proofpoint.
See page 110.
• queued – for buffer queue management. See page 112.
• clone_config – for cloning an agent from a source host in a cluster. See page 112.
Commands for Tagging and Pushing Configuration Changes

Use these commands for tagging file sets and pushing them to the agents in a cluster.
Tagging a File Set
Tagging a file set means saving a file set with a name and description. A tagged set of files may include
different versions of each file in the set, as one file in the set can change without the others changing.
For example:
Version
File set_1 filter filter.cfg 7.1 7.2 7.3 7.4
dictionary1 7.1 7.2
dictionary2 7.1 7.2 7.3
7.1 7.2 7.3 7.4 7.5
Tag: Production_10_15_2011

Chapter 8 - Command Line Interface
Rolling Back a File Set
If you apply configuration changes to the Proofpoint Protection Server and message filtering does not
behave as you expect, you can roll back the configuration to a point in time where filtering was working as
you expected. The Proofpoint Protection Server maintains a history of the configuration changes to each
file set.
pps_ctrlpoint Usage
In a clustered multi-server deployment, one system is the administration server; it maintains the master
configuration file filter.cfg, and pushes configuration parameters to the other agent systems.
References to <parameter_name> and <parameter_value> below indicate the key-value pair for a
parameter in the file filter.cfg.
Administrators can run the script on any server in a cluster to control the individual server.
Usage:
pps_ctrlpoint.sh [global options] command [command options]
Global options:
-H URI A HTTP URI pointing to the administration server.
-u user User name for administration privileges.
-w passwd Password for authentication.
Commands:
start Start the Proofpoint Protection Server.
stop Stop the Proofpoint Protection Server.
refresh Refresh the Proofpoint Protection Server configuration.
listtags Return a list of configuration tags.
tag -tag tag_name -comment text

Tag the current configuration set.
get -key parameter_name

Return the value of the specified parameter.
set -key parameter_name -value parameter_value

Set the value of the specified parameter.
deploy -tag tag_name

If you do not specify the tag name, the latest configuration set is deployed. If you
specify a tag name, the configuration is rolled back to the specified configuration
set.
86
Examples
This section provides some usage examples for the pps_ctrlpoint.sh command.
You must be logged in to the master Proofpoint Protection Server for command line interface
administration tasks.
You should add the directory that contains the Proofpoint binaries to your UNIX path. If you followed the
suggestions during the installation, the directory is /opt/proofpoint/pps-7.X.X/bin, but it can be any
directory of your choosing. If you do not add the directory, you must type ./pps_ctrlpoint.sh when using
this command. In the examples in this chapter, ${PROOFPOINT_ROOT} is represented by
/opt/proofpoint/pps-7.X.X/bin, where XX represents the release number.
Stopping, Starting, and Refreshing the Server
To stop message filtering on the Proofpoint Protection Server:

Enter the following command at the system prompt:
$ pps_ctrlpoint.sh -H https://server:port -u <username> -w <password> stop
To start message filtering on the Proofpoint Protection Server:

$ pps_ctrlpoint.sh -H https://server:port -u <username> -w <password> start
To refresh the configuration cache on the Proofpoint Protection Server:

$ pps_ctrlpoint.sh -H https://server:port -u <username> -w <password>
refresh
Note: If you stop the agents in a cluster using the pps_control.sh stop command before you
delete the agent systems, the management interface does not display accurate
information for the agent systems. Do not stop the agents before deleting them from the
cluster.
Listing Configuration Tags
To view the history of configuration tags:

$ pps_ctrlpoint.sh -H https://system:port -u <username> -w <password>
listtags
The Proofpoint Protection Server returns information that looks similar to this:
ok
configuration_2008-04-15_17-25-04 | 2008-04-15_17-25-04 | proofpoint |
updated filter.cfg for install location
test1 | 2008-04-16_11-11-33 | admin | test1
test2 | 2008-04-16_11-13-25 | admin | test2
test5 | 2008-04-16_11-20-04 | admin | test5
test6 | 2008-04-17_10-24-51 | admin | test6

To tag a new configuration set:

$ pps_ctrlpoint.sh -H https://system:port -u <username> -w <password> tag
-tag test7 -comment "this is test7"
ok
tag test7 created
To roll back to a previous tag set:

$ pps_ctrlpoint.sh -H https://system:port -u <username> -w <password>
deploy - tag test1
ok
active tag set to test1
Getting Parameters
To view a specific parameter:

$ pps_ctrlpoint.sh -H https://server:port -u <username> -w <password> get
-key "com.proofpoint.filter.log.file.level"
The get command returns the value for the parameter – in the example above, the
com.proofpoint.filter.log.file.level parameter.
Setting a Parameter
The set command sets the specified parameter to a new value.
For example, to change the filtering engine log level to trace:

$ pps_ctrlpoint.sh -H https://server:port -u <username> -w <password> set
-key "com.proofpoint.filter.log.file.level"
-value "trace"
Commands for Processes

The filtering engines, web-based administration server, and database server are all unique processes that
need to be started once the software is installed. The pps_control.sh shell script starts these processes.
Please log in as the Proofpoint user to run these commands (for example, pps).
pps_control Usage
pps_control.sh <command> [option]
Commands:
forcerestart Stops then starts the management interface child processes without affecting
the parent process.
88
gracefulrestart Restarts the management interface child processes without affecting the
parent process.
refresh Reloads the information for the process specified by option, without stopping
the process. If no option is specified, reloads all processes.
restart Stops and starts the process specified by option. If no option is specified,
stops and starts all processes.
start Starts the process specified by option. If no option is specified, starts all
processes.
stop Stops the process specified by option. If no option is specified, stops all
processes.
status Returns the status for the process specified by option. If no option is
specified, returns the status for all processes, except sendmail and
watchdog, which must be explicitly specified. Status is “running” or “stopped.”
version Returns the software version for the process specified by option. If no option
is specified, returns the version for all processes.
Options:
admin Web-based management interface.
db Database process.
digest Digest Command Processor.
encrypt Proofpoint Encryption.
pss Proofpoint Smart Search.
filter Filtering engines.
httpd Web server.
queued [SMTP_profile_name]
Buffer queue. If you do not specify the SMTP profile name the command
option applies to all profiles.
sendmail Sendmail.
watchdog Watchdog.
Note: If you do not specify an option, the command applies to all processes, except sendmail
and watchdog, which must be explicitly specified. For example:
pps_control.sh status [sendmail|watchdog]
Making Configuration Changes to filter.cfg

If you choose to make configuration changes to the master Proofpoint Protection Server by making edits to
the filter.cfg file, be sure to follow the procedure in this section. After making changes to the master
Proofpoint Protection Server, the changes are deployed on the agents. Do not make edits to the filter.cfg
file on the agents.
You will change a copy of the filter.cfg file that you first check out using the CVS command.
Using CVS, check out the file, modify it, then check it back in:
1. Change directories to your current working directory.

2. To check out the file, enter these commands at the prompt (the following command is one line):
$ /opt/proofpoint/pps-7.X.X/bin/cvs -d
/opt/proofpoint/pps-7.X.X/admin/admind/repository checkout FILTER
$ cd filter
3. Using a text editor, open the file filter.cfg and make the changes.
4. After saving the file, use CVS to check it in:
$ /opt/proofpoint/pps-7.X.X/bin/cvs commit -m your_comment
5. Change directories to this location:
$ cd /opt/proofpoint/pps-7.X.X/bin
6. Deploy the configuration on the Proofpoint Protection Server:
$ ./pps_ctrlpoint.sh -H https://server:port -u <username> -w <password>
deploy
7. Refresh the configuration on the Proofpoint Protection Server:
$ ./pps_ctrlpoint.sh -H https://server:port -u <username> -w <password>
refresh
Commands for the User Repository
The useradm command and several options are available for populating and managing the User
Repository. The useradm.sh utility is located in the directory ${PROOFPOINT_ROOT}/admin/tools, and it
should only be run from the master Proofpoint Protection Server.
The Proofpoint Protection Server can accept user data from the following sources:
• An LDAP (Lightweight Directory Access Protocol) server.
• An LDIF (Lightweight Directory Interchange Format) file generated from an LDAP or Active Directory
server.
• An Active Directory server.
• A CSV (Comma Separated Value) text file.
• A text file containing only email addresses. The addresses are comma-separated, and can span more
than one line.
useradm Usage
useradm.sh <option>
See Table 1 for a description of the options. The internal attribute name refers to the internal name the
Proofpoint Protection Server uses for the imported attribute. The external attribute name refers to the
name of the attribute as it appears in the source.
Note: During an import from LDAP, LDIF, or a CSV file, you must specify at least the mail
attribute.
90
Table 1. useradm Command Options
Parameter is
Option case-sensitive Description
[-allowlocal] Allow local address.
[-attrdefault No During an import, assigns default values to user

<attribute=value>] attributes if the import source does not already have
the values defined.
[-attrnamemap No Map internal attribute name to the external (import

<internalAttr=externalAttr>] source) attribute name.
[-attrvalue No Force the attribute(s) to have a specific value.

<attribute=value>]
[-base|-b] <directorybase>] No Base DN (Distinguished Name).
[-charset] <set> Yes Determines the character set during an import or

export. The default is latin-1 if you do not specify a
character set. Values for <set>:
utf8 utf-8
latin1 latin-1
[-clear] Deletes all user profiles in the User Repository, or

deletes only the user profiles that are members that
are members of the group <name> specified by the
importgroupid <name> option.
[-delete | d <file> No Delete the users listed in a file.
[-email] No Specify the email filter to use during an import.

<example@example.com>
[-export|-e] <file> Exports the User Repository to a CSV file.
[-exportpwd] Include encrypted user passwords when exporting.
[-filter|-f] <searchfilter> No LDAP filter.
[-format] <format> Yes Ignores the extension of the imported file and formats
the file type using one of these formats:
csv CSV.
ldif LDIF.
txt Text.
[-groupattr] No During an import, use this attribute to determine the

group the user belongs to. The default is memberOf.
For example, ou as in OrganizationalUnit.

Parameter is
[-groupidattr] <name> No If the value of the attribute specified by groupattr is

an LDAP DN (Distinguished Name), look up the DN to
obtain a short name for the group using the attribute.
The default is cn.
[-groupidfilter] <group_id> Yes Ignores groups that do not match this list of group IDs
or patterns. Separate multiple entries with a comma.
(No spaces.)
[-help] Help on command usage.
[-host|-h] <hostname> No Imports the User Repository from a LDAP server or

Active Directory server.
[-import|-i= <file>] Yes Imports the User Repository from a local LDIF file,
HTTP, or FTP file, and checks the file extension so
that imported file matches the existing one.
[-importgroupid] <name> Yes Imports the users into the group <name>. If you also
use the -removeold flag, removes users from the
group that are not included in the import.
[-insertmode|-im] <mode> Yes Inserts entries from the source into an existing User
Repository, using one of these modes:
a Inserts all entries (this is the default).
n Inserts only the new entries.
e Inserts only existing entries.
[-ldaps] Use SSL for the connection to the LDAP server.
[-ldapversion] <version> Sets the LDAP protocol version, using one of these
versions:
3 LDAPv3 (this is the default).
2 LDAPv2.
[-list|-l] Displays the current profiles (email addresses) in the

User Repository.
[-listobjectclass] No By default, Proofpoint uses the objectclass

<your-argument> mailgroup for mailing lists, or the objectclass
group if you are importing from Exchange or Active
Directory. If you use a different objectclass for
mailing lists, enter that value as the argument.
[-login|-l] <username> Yes The bind DN with which to authenticate to the LDAP
or Active Directory server. If this parameter is not
specified, the login is anonymous.
[-ownermode] Looks up the owner of a mailing list during an import.
92
Parameter is
[-pass|-p] <password> Yes The password for the bind DN specified to

authenticate to the LDAP or Active Directory server. If
the password is not provided the user will be
prompted for one.
[-profid] <profileID> Yes Imports the User Repository from a location specified
by the profile ID.
[-removelimit] <value> Yes Limits the number of entries to remove from the User
Repository during an LDAP import. Applies only if you
are also using the -remove option. Values are No
Limit, 5, 10, 25, 50, 100, 500, 1000, 2500, 5000, and
10000.
[-removeold] During an import, removes entries in the existing User

Repository that do not exist in the data source.
[-removeoldgroup] During an import, removes a user from a group in the

existing User Repository if the user has been
removed from the group in the data source.
[-replacemode|-rm] <mode> Yes Replaces the existing entries in the User Repository
with the data from the source, using one of these
modes:
r Replaces all aliases for existing users (this is the
default).
f Replaces the user entry with the full record from
the source – any existing Safe Lists and Blocked
Lists in the User Repository are lost.
u Adds (appends) new aliases (from the source) to
existing aliases in the User Repository. Also adds
new entries to the Safe Senders and Blocked
Senders lists.
[-report] [-to <recipient>] No Generates a report of the result of an LDAP import

and sends it to the Default alert profile.
The -to <recipient> option sends the report to
the designated recipient.
[-sasl] <method> Yes Uses SASL authentication for importing from an

LDAP server. You must specify one of these methods:
DIGEST-MD5, CRAM-MD5, ANONYMOUS,
EXTERNAL, LOGIN, or PLAIN.
[-scope] <value> No Limits the search to this scope:

base Search only the base object.
one Search the entries immediately below the
base object.
sub Search the whole tree below (and including)
the base object. This is the default.

Parameter is
[-starttls] Tries to start a TLS (Transport Layer Security) session

with the LDAP source.
[-type] <mode> Yes Imports or exports the entries by type of object, using
one of these modes:
a Automatically, based on objectClass (this is the
default).
u User.
l List.
[-updatemode|-um] <mode> Yes Updates the existing entries in the User Repository
with the data from the source, using one of these
modes:
u Replaces all user data (this is the default).
n Does not replace all user data.
[-uidprimary] During an import, use uid as the primary key to locate

the user records in the data source.
[-verbose|-v] Verbose mode. Provides feedback information during

the process.
Import Attributes
External sources include a CSV file or LDAP server. The Proofpoint Protection Server uses the attributes
listed in Table 2 from an external source during an import.
CSV File Format
When creating a comma-separated value text file for import, include a line at the top of the file to indicate
the columns for the attributes you want to import.
For example (this is one line):

proxyAddresses,whitelist,blacklist,owner,memberOf,
otherMailbox,mail,usertype,givenName,sn,contenttype,emptydigest,SendDigest,Spam
Classification,MessageAuditing,IncludeAuditFolder
The CSV file format example illustrates the format and order of all the lines that follow in the file. To
designate “no value,” separate the attributes with a comma. To enter more than one value, separate each
value with a semi-colon (;).
Note: The data in the Value column in Table 2 applies to LDIF and LDAP files also, except that
instead of separating many values with a semi-colon, multiple values appear on separate
lines.
94
Table 2. Import Attributes and Values
Proofpoint
Proofpoint internal name for Corresponding source attribute
the attribute attribute description Value
* The default setting means inherit the setting from the group. If the setting is not defined by the group, or if the user
does not belong to a group, it means inherit the global settings.
EmailAddr mail Email address Text. Email address.
FirstName givenName First name Text.
LastName sn Last name Text.
User or mailing 0 = user

ProfileType usertype
list 1 = mailing list
Text. For CSV, separate each

proxyAddresses, entry with a semi-colon, using
mailalternateaddress, this format:
userPrincipalName, <attribute>:add1@exampl
mailforwardingaddress e.com;add2@example.com.
ATTR_ALIASES otherMailbox Aliases For LDAP, place each entry on a
(Note: when importing separate line, using this format:
from a CSV file, use <attribute>:add1@exampl
proxyAddresses for the e.com
column heading.) <attribute>:add2@exampl
e.com.

entry with a semi-colon, using
this format:
blacklist:add1@example.
com;add2@example.com. For
Blocked
ATTR_BLACKLIST blacklist LDAP, place each entry on a
Senders list
separate line, using this format:
com
com.
Text. Use same CSV or LDAP

ATTR_GROUP memberOf Group
format as attr_aliases.
mailGroup. Use same CSV or

ATTR_OBJECTCLASS objectClass Mailing list.
LDAP format as attr_aliases.

Proofpoint
Owner or Text. Email address. Use same

ATTR_OWNER owner delegated CSV or LDAP format as
owner attr_aliases.

entry with a semi-colon, using
this format:
whitelist:add1@example.
com;add2@example.com. For
Safe Senders
ATTR_WHITELIST whitelist LDAP, place each entry on a
list
separate line, using this format:
com
com.
-1 = Default setting *
1 = HTML/Text
2 = Text Only
3 = HTML Only
4 = HTML/Text + HTTP
Digest Format commands
DigestContentType contenttype
parameters 5 = HTML Only + HTTP
commands
6 = Simple HTML/Text
7 = Simple HTML
8 = Simple HTML/Text + HTTP
9 = Simple HTML + HTTP
-1 = Default setting*
Empty Digest
SendEmptyDigest emptydigest 1 = Do Not Send Empty Digest
parameters
2 = Send Empty Digest
Include Audit
IncludeAuditFolder IncludeAuditFolder 1 = Do Not Include Audit Folder
folder in Digest
2 = Include Audit Folder
SendDigest SendDigest Send Digest 0 = Do Not Send Digest
1 = Send Digest
Text; internal policy name.

SpamClassification SpamClassification Spam policy
-1 = Default policy*
96
Proofpoint
Audit
MessageAuditing MessageAuditing 0 = Do Not Audit Messages
messages
1 = Audit Messages
Filter
OptIn OptIn 1 = Yes
messages
0 = No
Enforce the -1 = Default setting*

DigitalAssets DigitalAssets Digital Assets 0 = Do Not Enforce
Module rules 1 = Enforce
Allows specific
users to
populate the -1 = Default setting*
DigitalAssetsDocumentC
DigitalAssetsDocumentCreation Document 0 = Do Not Allow
reation
Repository in 1 = Allow
the Digital
Assets Module
sc = Chinese (Simplified)
tc = Chinese (Traditional)
nl = Dutch (Netherlands)
enus = English (U.S.A.)
fr = French (Français)
de = German (Deutsch)
Determines the
language for it = Italian (Italiano)
Locale Locale
the End User jp = Japanese
Digest es = Spanish (Español)
fi = Finnish (Suomi)
sv = Swedish (Svenska)
pl= Polish (Polski)
pt = Portuguese
ru = Russian
da = Danish
Enforce the -1 = Default setting*

Regulatory
RegulatoryCompliance RegulatoryCompliance 0 = Do not enforce
Compliance
Module rules 1 = Enforce

Proofpoint
Allows users to
add senders to
their
Safe/Blocked
Senders lists
based on the -1 = Default setting*
SafelistUseHeader SafeListUseHeader sender’s 0 = Do not allow
header From 1 = Allow
information
instead of the
sender’s
envelope
information
Secure
Message
Profile. Defines -1 = Default
the options
SecurityPolicy SecurityPolicy otherwise, value will be the
available to
users for name of the profile
Proofpoint
Encryption.
Change
Password
Allowed. Allows
users to -1 = Default
PasswordOption PasswordOption change the 0 = No
password they 1 = Yes
use to log in to
the Web
Application.
Authentication
Source.
Specifies the
source to use -1 = Default
for user
AuthSource AuthSource otherwise, value will be the
authentication,
defined by the name of the profile
import or
authentication
profile.
-1 = Default
Password
PasswordPolicy PasswordPolicy otherwise, value will be the
Policy
name of the profile
98
Proofpoint
-1 = Default
External
ExternalPasswordPolicy ExternalPasswordPolicy Password otherwise, value will be the
Policy name of the password policy
profile
-1 = Default
Branding
Template Template otherwise, value will be the
Template
name of the Branding Template
Enable
Forwarder.
Allows users or
a mailing list to
forward email
from a POP 1 = Yes
ForwarderEnable Forwarder Enable
account to the 0 = No
appliance or
Proofpoint
Protection
Server for
filtering.
CSV Text File Example
This section contains an example of a CSV text file to illustrate the format. Commas with nothing between
them denote an empty attribute.
sn,givenName,mail,proxyAddresses,contenttype,emptydigest,whitelist,blacklist,us
ertype,owner
smith,joe,joe@example.com,alias1@example.com;alias2@example.com,1,0,,,0,joe@exa
mple.com
white,jane,jane@example.com,alias3@example.com,2,2,mom@example.com,spammer1@exa
mple.com;spammer2@example.com,0,jane@example.com,,sales@example.com,,0,1,,,1,us
er@example.com
Examples for the useradm Utility
The following sections contain examples of how to use the useradm.sh utility.
Simple Imports
To import entries from standard input:

cat input.ldif | useradm.sh -format ldif -import -

To import entries from an FTP location:

useradm.sh -import ftp://user@ftpserver/tmp/data.ldif
To import entries from an HTTP location:

useradm.sh -import http://webserver/tmp/data.ldif
To import the entries from a LDIF file:

useradm.sh -i users.ldif
To import the entries from a CSV file:

useradm.sh -i users.csv
To import entries from an LDAP server anonymously:

useradm.sh -h <ldap_server> -b "cn=Users, dc=company, cd=com"
To import entries from an LDAP server and update the existing entries in the repository:
useradm.sh -h <ldap_server> -b "cn=Users, dc=company, cd=com" -u <bind DN>
-p <password> -u
To import entries from an LDAP server and assign a specific value for a specific attribute:
useradm.sh -attrvalue "attribute_name=attribute_value"
To import entries from an LDAP server and exclude these users –dadmin@proofpoint.com,
x-info@proofpoint.com, and jvalentine@proofpoint.com:
useradm.sh -i ldap://ldap/ou=people,dc=extreme-email,dc=com -filter
"(&(mail=*)(!(mail=dadmin@proofpoint.com))(!(mail=x-info@proofpoint.com))(!
(mail=jvalentine@proofpoint.com)))"
Note: The example above is one line of text.
Imports that Include Groups
This is an example for importing entries from a CSV file and use “department” to assign users to groups.
The group is automatically created if it does not already exist. The group ID id the value of the department
attribute.
useradm.sh -import input.csv -groupattr department
Here is an example to import entries from an LDAP server, use memberOf to assign users to groups. The
group ID takes the value of the memberOf attribute unless the value is a valid DN. In that case the
Proofpoint Protection Server looks up the DN entry and uses this entry name attribute as the group ID. The
-base argument requires quotations around it if it contains spaces.
useradm.sh -host ldapserver -base "ou=people, dc=company, dc=com"
-groupattr memberOf -groupidattr name
100
Advanced Imports
This section contains examples of advanced imports.
The following example illustrates an import from a CSV text file. Users are assigned a SendDigest attribute
with a value of 1, and a SpamClassification attribute with the value of 1 if the source does not define
them.
usradm.sh -import <input>.csv -attrdefault
"SendDigest=1,SpamClassification=spampolicy1"
The next example illustrates an import from a CSV text file. Override all imported entries for the
SendDigest attribute with the value of 1.
useradm.sh -import <input>.csv -attrvalue "SendDigest=1"
The following example illustrates an import where the internal attribute name is remapped with attribute
names that differ from the source of the import. For example, if the internal name for the FirstName
attribute is taken from the CSV file attribute givenName, you can make the import use the first_name
column in the CSV file to create the internal attribute FirstName. Similarly, if the default internal name for
the ATTR_GROUP attribute is taken from memberOf, you can remap it to the external name department.
useradm.sh -import <input>.csv -attrnamemap
"FirstName=first_name,ATTR_GROUP=department"
The next example illustrates overriding some attributes based upon the value of other attributes during an
import. That is, if ATTR_GROUP attribute value is department, and department has the value Marketing, set
the SpamClassification value to strict.
useradm.sh -import <input>.csv -newattrmap "<RULE
id='marketing'><CONDITION><ATTR
id='department'>Marketing</ATTR></CONDITION><TARGET><ATTR
id='SpamClassification'>strict</ATTR></TARGET></RULE>"
Commands for Group Management
Use groupadm for listing groups and their members, creating and managing groups, and managing and
making changes to user attributes within a group. The groupadm.sh utility is located in the directory
${PROOFPOINT_ROOT}/admin/tools.
groupadm Usage
groupadm.sh <command> [-<option>] <arguments>
Examples
createdb --login root --password='your_mysql_password' --force
Re-creates the user database (User Repository) and the global and spam reporting groups.

listgroup [-detail] [-member] [groupid1 groupid2...]
Returns the groups listed along with the members in each group. If no groups are specified, lists
all of the groups. Lists the members of the group with the [member] option. The [detail] option
lists the attributes of the user and group.
listuser [-detail] [addr1 addr2...]
Returns detailed information about the users listed by address, for example, the group to which
they belong. If no users are specified, lists all of the users.
computedpolicy [addr1 addr2...]
Returns all of the attributes for the user(s) listed. The computed policy is the attribute in effect
after taking into account that the user can override the group attributes, and that the group
attributes can override the global attributes.
computedpolicy [-forcegroup group_name]
Forces the user profile to belong to a specific group, overriding the user attributes.
memberof [-detail] emailaddr
Returns a list of the groups to which the user belongs.
globalusergroup [attr1 val1 attr2 val2...]
Create or modify the global user group. This is the group to which all users belong.
creategroup groupid [attr1 val1 attr2 val2...]
Creates a group with an ID and the attributes and values specified.
creategroup groupid [attr1 val1 attr2 val2...] [-domainPatternType N

-domainPatternImportFile domainlst.txt]
Creates a domain group by bulk import with an ID and the attributes and values specified. N
maps to domain group regular expression patterns:
domainPatternType 8 domain equals example.com

domainPatternType 9 domain does not equal example.com
domainPatternType 4 domain is in the domain example.com
domainPatternType 5 domain is not in the domain example.com
domainPatternType 2 domain is in the regex match for example
domainPatternType 3 domain is not in the regex match for example
the domainlst.txt file format is a list of domains, where the domains are delimited by spaces or new lines
creategroup groupid [attr1 val1 attr2 val2...] [-domainPatternType N

"example1.com;example2.com"]
Creates a domain group with an ID and the attributes and values specified. N maps to domain
group patterns:
102
domainPatternType 8 domain equals example1.com and example2.com

domainPatternType 9 domain does not equal example1.com and example2.com
domainPatternType 4 domain is in the domain example1.com and example2.com
domainPatternType 5 domain is not in the domain example1.com and example2.com
deletegroup groupid
Deletes the group specified by the group ID.
deletegroup [-all]
Deletes all groups except the Global group and Spam Reporting Group.
editgroup groupid [attr1 val1 attr2 val2...]
Changes the group specified by the group ID with the attributes and values specified. If you do
not specify the attribute-value pair, displays the current attributes for the group.
addmember groupid memberid1 memberid2
Adds specified members to the group specified by the group ID. Members are specified by
email addresses.
removemember groupid memberid1 memberid2
Removes the specified members from the group specified by the group ID.
edituser emailaddr [attr1 val1 attr2 val2...]
Changes the attributes for the user specified by the email address to the specified attributes
and values.
deleteuser addr1 [addr2 addr3...]
Removes the specified user from the User Repository.
Examples for the groupadm Utility
This section contains examples for the groupadm.sh utility.
To list all the groups:

groupadm.sh listgroup
To list the groups (Marketing and Sales) and the members of each group:
groupadm.sh listgroup -member Marketing Sales
To list the members of the Marketing and Sales groups with details for each member:
groupadm.sh listgroup -member -details Marketing Sales

To list the attributes that are in effect for a user (user1 and user2), taking into account that user attributes
override group attributes, and that group attributes override the global attributes:
groupadm.sh computedpolicy user1@example.com user2@example.com
To list the groups to which a user (user1) belongs:

groupadm.sh memberof user1@example.com
To list the current global attributes:

groupadm.sh globalusergroup
To change the global group attributes for SpamClassfication to defaultPolicy and SendDigest to the
value of 1:
groupadm.sh globalusergrop SpamClassification defaultPolicy SendDigest 1
To display the current attribute settings for a group (Marketing):

gropadm.sh editgroup Marketing
To set the SpamClassfication attribute for the Marketing group to mktgPolicy and the SendDigest
attribute to 0:
groupadm.sh editgroup Marketing SpamClassfication mktgPolicy SendDigest 0
Commands for Quarantine Management
The qdbutil command and several options are available to query and manage the Quarantine database.
The qdbutil.sh utility is located in the directory ${PROOFPOINT_ROOT}/admin/tools.
qdbutil Usage
qdbutil.sh [-compact][-delete][-dump][-list <options>]
Database Operations
-compact Compact the database.

-createdb --login root --password='your_mysql_password'
Re-creates the Quarantine database.
--force Does not prompt for confirmation.
--preserve Re-creates the previous folders.
-createmsgqueue Create Quarantine database message queue if one does not already exist.
104
Folder Operations
If you do not specify the folder, the default is the Quarantine folder.
-summary Displays the summary information for the folder.
-purge Purges (removes) the messages from a folder.
-cache Apply to the cached messages.
-createfolder <option> If you do not specify a folder will modify the properties of an existing folder.
Options:
expiration Sets the folder expiration (in seconds).
maxmsgs Determines the maximum number of messages per

table.
expiremode Expiration mode. 0=Drop table, 1=Delete.
permissions Folder permissions.
zerohourenabled Enable Zero-Hour virus scanning.
zerohourupdatecount n
Folder disposition is invoked after the specified virus
updates.
zerohourminupdatetime n
Folder disposition is invoked after this minimum time in

seconds.
-createfolder -folder <folder_name> -ftype 1
Creates a folder folder_name of type Data Loss

Prevention (DLP).
-createfolder -folder <folder_name> -ftype 0
Creates a folder folder_name of type system.

Note: To change a folder from one type to another, change the -ftype flag for the folder name.
-deletefolder Delete the Quarantine folder. Requires -name <folder_name>.
-renamefolder Renames the folder.
-importfolders Imports Quarantine folders. Requires a flat file argument, typically uses with
“quarantine.folders” from a backup.
-listfolders Lists all folders.
detail Displays detailed folder information.
export Output export format.

-ftype 0 Displays all system folders.
-fytpe 1 Displays all DLP folders.
-expire Expire the messages in the folder. The folder expiration setting is used by
default.
age Expire by age of the messages (in seconds).
blocksize Expire by block size.
maxrecs Expire by maximum number of messages. The default

is to expire all messages older than age.
-exportallmsgs Export all messages from all of the folders to a file.
-exportmsgs Export messages defined by the query options to a file.
-importmsgs Import messages from a file.
Message Operations
If no query options are used, these operations apply to all of the messages in the Quarantine.
-delete Delete the database.
-dump Dump the database to a file.
-list List the messages returned by the query.
-scan Scan the messages for virus.
-resubmit Resubmit the messages for another virus scan.
-release Release the messages.
Query Options
The query options apply to the message operations.

-startdate <date> Start insertion date YYYY-MM-DD [HH-mm-SS].
-enddate <date> End insertion date YYYY-MM-DD [HH-mm-SS].
-reason <module> Module name for quarantined message.
spam Spam Detection Module.
content Content Compliance Module.
av Virus Detection Module.
dictionary Dictionary Module.
-verbose Verbose output.
106
-folder|-f <foldername> Quarantine folder name. The default is Quarantine <Quarantine|Deleted>
-unique|-u <integer> Database record number <integer>.
-sortorder|-s <asc> <desc> Sort order for returned messages <asc> (ascending) <desc> (descending).
-sortkey <key> Sort key for returned messages. Keys:
asc Ascending.
desc Descending.
unique Internal database ID.
Sender The sender of the message.
Recipients The recipients for the message.
Size The size of the message.
Message-ID The unique message ID.
Score The score of the message.
Release Messages that were released.
Keep Messages with the keep flag.
Subject Subject of the message.
Date Date of the message.
Attachments Message attachment.
-limit|-l <integer> Limit the number of messages returned. The default is 10000.
-offset|-o Offset from start of return messages.
-msgid|-m Message id (RFC header).
-released|-r <mode> Message release flag set. Modes:
0 Not released.
1 Released.
-size Message size.
-sender Envelope Sender.
-senderdomain Envelope Sender Domain.
-rcpt|-to|-r Envelope recipient.
-help|-h Help on command usage.

Examples
To compact the database:

qdbutil.sh -compact
To delete messages addressed to recipient bill@example.com or john@example.com. (The following

example is one line.)
qdbutil.sh -delete -rcpt bill@example.com -rcpt john@example.com
To list all messages sorted by size:

qdbutil.sh -list -size 2000 -sort asc
To dump spam messages from the sender bill@example.com to a file:

qdbutil.sh -dump -sender bill@example.com
Commands for the Digital Assets Module
Use the dautil command to create and delete categories for the Digital Assets Module, and to load
documents into the Document Repository. The dautil.sh utility is located in the directory
${PROOFPOINT_ROOT}/admin/tools.
datutil Usage
dautil.sh [-<options>] [-verbose]
Options
-create Create a category.

-createdb --login root --password='your_mysql_password' --force
Re-creates the categories and Document Repository.
-exportcategory > file Exports the document categories to file.
-importcategory < file Imports the document categories from file to the Proofpoint Protection
Server.
-list List all documents optionally by category.
-load Load documents in a category.
-loadurl Load documents in a category from a WebDAV URL.
-loadconfig Load documents in a category from WebDAV URLs specified in filter.cfg.
-reindex Scan all documents for signatures.
-delete Delete the specified category and all documents in that category.
108
-sigs List the extracted signatures.
-help Help for command usage.
Examples
dautil.sh -list [-category reports]
Lists the documents in the repository. If you specify a category, lists the documents in the specified
category.
dautil.sh -create -category specifications [-description 'this category

contains product specifications']
Creates a category named specifications and adds a description for the category.
dautil.sh -delete -category reports
Deletes the specified category (reports) and the documents in the category.
dautil.sh -category specifications [-description 'updated the product

specifications'] [-overwrite] -load <files or directory>
Scans the documents specified by files or all the documents specified by directory and places the
documents in the category specifications. The -overwrite option replaces the document if it already
exists in the category. Separate several files or directories with spaces.
dautil.sh -category reports [-description 'updated reports category']

[-deleteold] -loadurl <url> [-user userid] [-pass userpassword] [-include
path_regex] [-exclude path_regex]
Recursively scans the documents specified by the WebDAV URL directory into the specified category.
If the URL requires a user name and password, use the -user and -pass options. The -deleteold
option removes the documents in the repository that are no longer included in the source WebDAV
URL. The file modification time is maintained so that the next time you execute this command only new
or changed documents from the source are scanned and included. The -include and -exclude
options allow you to include or exclude files and directories using regular expression match syntax
(regex).
dautil.sh [-description 'reports'] -loadconfig [-configid id]
Works the same way as the previous example, but uses the parameters defined by the Document
Source profile ID number. The WebDAV profiles and their IDs are created and listed in the Document

Source table accessed in the management interface (click the Settings link under Digital Assets, then
select the File Crawler tab).
datuil.sh -reindex
Scan and create signatures for all the documents that are currently stored in the Document Repository.
dautil.sh -sigs document
Scan and list the signatures from the specified document.
Commands for the Log Database

Use the logdbutil command to re-create the log database. The logdbutil.sh utility is located in the
directory ${PROOFPOINT_ROOT}/admin/tools.
logdbtutil Usage
logdbutil.sh [-<options>]
Options
-createdb --login root --password='your_admin_password' --force
Re-creates the log database.
Commands for the Log Collection Service

Use the log_upload.pl utility to collect and upload log information immediately to Proofpoint. The
log_upload.pl command must be run by the pps user. This is a convenient feature when you have
opened a CTS call and are working with technical support to resolve a problem. The log_upload.pl utility
collects log information for a system in a cluster and transmits it to Proofpoint. The log_upload.pl utility is
located in the directory ${PROOFPOINT_ROOT}/admin/tools.
log_upload Usage
To execute a log collection and upload job:

log_upload.pl -c [-i <ctsID>] [-l <level>] [-u <url>] [-d|v]
Logs are collected per the level parameter, then uploaded to the specified URL, or to Proofpoint by default.
The ctsID is required so that the logs can be associated with a ctsID once they are uploaded.
Options
-c|collect Collect mode. Gather logs and upload.
110
-i|ctsid <ctsID> Optional ID of corresponding CTS call. If a ctsID of 0 is used, logs will be
collected and spooled, but not transmitted to Proofpoint.
-l|level <level> Specify the level of logging information to collect. <level> can be an integer
between 1 and 3. The value 1 collects the least amount of information, 3 collects
the most. The default value is 1.
Level Data collected
1 - Core files.
- Warnings and errors in all relevant files.
- The /etc/filter.cfg and /instance/etc/filter.cfg files are reviewed for
inconsistent rules and routes.
- The Proofpoint Protection Server software and appliance configuration settings.
- The sendmail, NTP, and DNS configuration files.
- Log files for the Proofpoint Protection Server and appliance.
- The sendmail log files.
- The current status of the operating system.
- A summary of the current filter.log message entries, including message count
and size, attachment count and size, and message processing duration.
- Quarantine folder information.
2 Includes all of the data in level 1, plus

- Export of groups and users.
3 Includes all of the data in level 1 and level 2, plus

- All of the files under ${PROOFPOINT_ROOT}/var/log.
- All of the files under ${PROOFPOINT_HOME}/var/log/upgrade.
-d|debug|v|verbose Increases level of verbosity while running. Either option increases the amount of
information returned on the screen and in the Log Collection Service log file.
Since the archives are not automatically removed, Proofpoint recommends that you remove the data if you
use the Log Collection Service on a regular basis. To clean up the log collection directory, use the following
command:
log_upload.pl -k [<jobID>] [-d|v]
Log archives are spooled under ${PROOFPOINT_ROOT}/var/spool/log_upload, and they can get quite
large.
-k|kill [<jobID>] Tells log_upload.pl to clean up the files associated with the given jobID, or to
clean up all collection job files if jobID is not specified.

To print help and exit:
log_upload.pl [-h]
-h|help Print the help message and exit.
Commands for Buffer Queue Management

The buffer queue is a dedicated mail transfer agent subsystem for delivering messages generated by the
filtering engine. If a message is processed that requires the filtering engine to create and deliver new
messages, the filtering engine generates the new messages and queues them to the buffer queue
subsystem for delivery. For example, when a message is addressed to multiple users and split envelope is
enabled, or when the delivery disposition for a triggered rule requires a message to be forwarded to new
recipients.
The buffer queue utility queued is located in ${PROOFPOINT_ROOT}/bin.
queued Usage
bin/queued [start | stop | status | queuestat | mailstats | hoststat
| purgestat] [<SMTP_profile_name>]
If you do not specify the SMTP profile name the option applies to all of the profiles in the SMTP Profiles
list.
Options
-start Starts the buffer queue.
-stop Stops the buffer queue.
-status Displays whether the buffer queue is running or not.
-queuestat Displays the messages in the buffer queue.
-mailstats Displays the current mail statistics.
-hoststat Displays the persistent host status database.
-purgestat Purges the persistent entries from the host status database.
Cloning an Agent
Use clone_config.pl to clone an agent’s configuration settings from a source host in a Proofpoint cluster.
You can clone the settings from the Config Master or from another filtering agent. The cloneconfig.pl
utility is located in the directory ${PROOFPOINT_ROOT}/admin/tools.
clone_config Usage
clone_config.pl [-a] [-c] [-g <file>] [-h] [-l <logfile>] -s <fqin> -t
<fqin> [-v]
112
Options
-a|addagent Caller is add_agent, which means the upgrade_deploy lock is already

held.
-c|check Run in check mode. Verify the configuration of target against source system.
Report any discrepancies.
-g|guioutput <file> Specify file for management interface status report.
-h|help Print help and exits.
-l|logfile <logfile> Specifies alternate logfile. The default is

$PROOFPOINT_ROOT/var/log/admind/clone_config.log.
-s|source <fqin> Use <fqin> (Fully Qualified Instance Name) as the system from which to
copy configuration data. Default is the Config Master.
-t|target <fqin> Target system to be configured.
-v|verbose Increase logging verbosity.
Publishing URLs to an External Web Page

You can make a report published to an internal URL available from an external web page, meaning a web
page external to the Proofpoint Protection Server. You can view the data for each format by clicking on the
URL in the Publish tab on the Report Publisher page, or by entering the URL in a web browser.
Use the following methods to publish the different report data formats:
• HTML, Javascript, and Image – Follow the instructions in “Embedding Report Data in an HTML Page”
for embedding report data into an HTML page. You cannot manipulate or change this data.
• Text – Click the URL to access the raw text. Copy and paste the text into an application or program, for
example Microsoft Word, where you can manipulate the data accordingly.
XML – Click the XML URL and save it as an .xml file in a location you can easily access. Open the
saved .xml file in an XML-compatible application, (for example, Microsoft Excel) and manipulate the
data accordingly.
Important: The Summary Dashboard report data can only be viewed or included in HTML, XML,
text, image, and Java Script formats are not available to the Summary Dashboard
report.
Embedding Report Data in an HTML Page
The instructions you follow depend on the type of system you use to embed the HTML, image, or Java
Script report data in an HTML page:
• Server Side Include (SSI) supported system in Apache and Windows IIS, or
• Non-supported SSI system

To embed the report in an HTML page using an SSI-supported system:
1. Make sure SSI is enabled on your Apache or Windows IIS server.
(For more information: http://httpd.apache.org/docs/mod/mod_include.html)
2. Name the page that you embed the HTML, Image, or Java Script report using this convention:
<xxx>.shtml. (Where shtml means Server Side Include HTML page.)
3. Add these lines to the HTML page:
<html>
<body>


<html>
<body>
(Where <PPS_Server_URL> is the server URL and <ID> is the ID of your favorite report.)
For example:
<html>
<body>


<html>
<body>
To embed the report in an HTML page using a non-supported SSI system, add the following lines:
<html>
<body>
<h1>Proofpoint Report</h1>

<img src="http://<PPS_Server_URL>:10000/published_report/
query.cgi?format=png&id=<ID>"/>


<script language="javascript"
src="http://<PPS_Server_URL>:10000/published_report/que
ry.cgi?format=js&id=<ID>"></script>
114
</body>
</html>
(Where <PPS_Server_URL> is the server URL and <ID> is the ID of your favorite report.)
For example:
<html>
<body>
<h1>Proofpoint Report</h1>

<img src="http://demo1003.proofpoint.com:10000/
published_report/query.cgi?format=png&id=3077757481"/>


<script language="javascript"
src="http://demo1003.proofpoint.com:10000/published_report/
query.cgi?format=js&id=3077757481"></script>
</body>
</html>
Enabling a Quarantine Node

The Quarantine Node feature allows administrators to designate an agent in a cluster as a Mail Filtering
Agent or a Quarantine Node. The Quarantine Node is the system that maintains the Quarantine database
(Repository) for all systems in a cluster.
This section describes how to configure the master Proofpoint Protection Server or appliance so that the
management interface displays the Quarantine Node designation option when you add an agent to the
cluster. Procedures for recovering a Quarantine Node or a master Proofpoint Protection Server in a cluster
that contains a Quarantine Node are also included in this section.
Note: This is a topic intended for administrators comfortable using the command line interface.
For assistance in enabling the Quarantine Node feature, contact Proofpoint Professional
Services or Technical Support.
Enable the Management Interface
Follow these steps on both the master and the agent that you plan to add as a Quarantine Node:
1. If you are running the management interface on the Proofpoint Protection Server, log out.
2. Using the command line interface, log in as the Proofpoint administrator.
3. Switch users to pps.
4. Change directories to ${PROOFPOINT_ROOT}.
5. Open the file pps_env.sh for editing.
6. Find the line prod_level=1000 and change the value to 1500.
7. Save and close the pps_env.sh file.

8. Restart the management interface. Change directories to ${PROOFPOINT_ROOT} and run the following
command:
./pps_control.sh restart admin
Add the Quarantine Node
Follow these steps to add the Quarantine Node to the cluster.

1. Log in to the management interface on the master Proofpoint Protection Server.
2. Click the Servers link under System.
3. Click Add Agent.
4. Enter the agent host name, admin port number, instance name, and password into the Add Agent form.
5. Select Quarantine Node from the Server Profile drop-down list.
6. Click Add Agent.
Now that you have added a Quarantine Node, back up the Proofpoint Protection Server or appliance so
that you have a “snapshot” of the cluster. You will need this backup if you ever need to recover the
Quarantine Node.
Performance Optimization
This section describes a procedure to enhance the performance of Quarantine database queries on the
Quarantine Node. This procedure is optional but recommended.
To optimize the performance of the Quarantine Node:

1. Use the command line interface to log in to the Quarantine Node as the Proofpoint administrator.
2. Stop the database:
pps_control.sh stop db
3. Change directories to ${PROOFPOINT_ROOT}/opt/mysql/data.
4. Open the my.cnf file for editing.
5. Find the following line and change the value from 1 to 0:
query_cache_type=
6. Save and close the file.
7. Restart the database:
pps_control.sh start db
Recovering a Quarantine Node
The recovery procedure for a Quarantine Node differs from the recovery procedure for a mail filtering
agent. This section describes the recovery procedure for a Quarantine Node. The steps below assume that
the master Proofpoint Protection Server or appliance is viable – only the Quarantine Node needs to be
recovered.
To recover a Quarantine Node:

1. Re-install the Proofpoint Protection Server software on the Quarantine Node system, using the same
IP address as the failed Quarantine Node.
116
2. Use the command line interface to log in to the Proofpoint Protection Server (the master Proofpoint
Protection Server) as the Proofpoint administrator.
3. Switch users to pps.
4. Change directories to ${PROOFPOINT_ROOT}/admin/etc/admind/servers.
5. Delete the file <quarantine_master_fqin>.serv from the directory. (This is the .serv file for the old
Quarantine Node.)
6. Open the file <master_fqin>.serv for editing.
7. Change the following parameter value from 0 to 1:
service.assigned.db.quarantine.master=
8. Change the following parameter value from 1 to 0:
service.assigned.db.quarantinecache=
9. Save and close the file.
10. Open a browser and log in to the management interface for the Proofpoint Protection Server to re-add
the Quarantine Node.
11. Click the Servers link under System.
12. Click Add Agent.
13. Enter the agent host name, admin port number, instance name, and password into the Add Agent form.
14. Select Quarantine Node from the Server Profile drop-down list.
Now you must import the quarantine folders from the backup you completed after adding the Quarantine
Node.
1. On the Proofpoint Protection Server (the master Proofpoint Protection Server) log in as the Proofpoint
administrator to the system using the command line interface.
2. Locate and identify the backup that you completed. Change directories to /opt/proofpoint/backup,
and use the ls command to find the backup instance. It will look similar to this:
<master_fqin>-datestamp
3. Run the following commands to populate the Quarantine Node with the Quarantine folder names and
properties from the backup. Replace <backup_instance> with the name of the backup that you
identified in Step 2.
cd /opt/proofpoint/<current>/admin/tools
(the following command is one line)
./qdbutil.sh -importfolders
/opt/proofpoint/backup/<backup_instance>/quarantine.folders
Recovering a Master Proofpoint Protection Server
This section covers the procedure for recovering a master Proofpoint Protection Server when you need to
replace the original Proofpoint Protection Server with a new system (new hostname and new IP address) in
a cluster that contains a Quarantine Node.
The procedure assumes that you have used Create a Backup on the System > Backup and Restore page in
the management interface and have a backup of the original master Proofpoint Protection Server
configuration settings stored on a local system.

Follow these steps on each agent in the cluster, including the Quarantine Node:
1. Log in to the agent as admin using SSH.
2. In the System Control Menu, select 1 – Proofpoint Management Interface.
3. Select 1 – Restore Firewall Access.
4. Select OK to confirm.
5. Select Yes to exit.
Follow these steps on the master Proofpoint Protection Server:

1. Log in to the management interface.
2. Click Backup and Restore.
3. Click Import Configuration and browse to the directory location where you have a backup of the “old”
master Proofpoint Protection Server.
4. In the Import Configuration File pop-up window, click Import to import the backup.
5. Select the backup in the Restore Backup list and click the Restore Backup button to restore the
configuration settings.
118
Appendix A Log File Format
This Appendix describes the log file format.
For each Proofpoint Protection Server, the log files are maintained in the directory
${PROOFPOINT_ROOT}/var/log. You can view a log file from a UNIX shell by changing directory to
${PROOFPOINT_ROOT}/var/log and opening the log file.
Log Entry Format

Log entries for reporting are generated in this format:
[yyyy-MM-dd hh:mm:ss.SSSSSS timezone_offset] loglevel mod=xxx cmd=xxx
[key1=value1 key=value2... keyN=valueN]
Where
• [yyyy-MM-dd hh:mm:ss.SSSSSS]
is the timestamp, in local time.
• timezone_offset
is the difference between local time and GMT (Greenwich Mean Time). This number
can be a positive or negative value.
• loglevel
is the log level for the entry. The levels are described in Table 3.
• mod=
is the name of the module that indicates where the log entry data is loaded. For
example, mod=spam means “spam module.”
• cmd=
represents the activity level of the service. The values are: start, reload, stop, and
rollover.

Appendix A - Log File Format
Table 3. Log Levels
Level Description
emrg Emergency. The system is unusable.
alrt Alert. The system is unusable.
crit Critical. The system is unusable.
err Error. This is an error condition.
warn Warning. This is a warning condition.
rprt Report. For reporting only.
note Note.
info Information. Informational message.
debg Debug. Messages generated for debugging

or troubleshooting purposes.
trce Trace. Every event for the system is logged.
Important: To capture meaningful log information, you should select Reporting for the Proofpoint
Protection Server Log File Level.
Log File Naming

Log files for reporting are generated with the following naming convention:
<hostname><instancename><servicename><timestamp.log>
Where
• hostname – is the name for the system where the software is installed and running.
• instancename – is the name for the instance of the software, as defined during the installation process.
• servicename – is the name of the service that creates the log file.
• timestamp – is the encoded timestamp in local time, in the format yyyy-mm-dd-hh-mm-ss.
Log Detail
These sections describe the report level log format in more detail, by service, session, and message level.
The format at this level is fixed and can always be counted on for analysis.
120
Service Level
These entries represent starting and stopping a Proofpoint Protection Server, refreshing (reloading)
configuration changes, and rolling over the log data tables.
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt mod=service cmd=action type=start
server_version=xxx config_version=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt mod=service cmd=action type=reload
server_version=xxx config_version=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt mod=service cmd=action type=stop duration=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt mod=service cmd=action type=roll
Session Level
Each session has a unique identifier associated with it, and is tracked by s=sss, as shown below. These
sessions are individual SMTP sessions.
These entries are for the connection-level events:

• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx mod=session cmd=connect start=xxx ip=xxx
host=xxx reverse=xxx helo=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx mod=session cmd=disconnect duration=xxx
read=xxx write=xxx msgs=xxx rcpts=xxx
Message Level
These entries represent the delivery disposition for a messages, based upon rules that were triggered
during the filtering process.
Within each session, typically one message is delivered, but SMTP does allow for multiple messages to be
delivered within one SMTP session. Each message is tracked by mod=xxx.
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=mail cmd=env_from value=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=mail cmd=env_rcpt value=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=mail cmd=attachment size=xxx
type=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=av cmd=run name=xxx cleaned=0|1
vendor=xxx duration=xxx rule=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=access cmd=run
attr=connect|helo|from|rcpt|hdr duration=xxx rule=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=spam cmd=run score=xxx
adultscore=xxx duration=xxx policy=xxx rule=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=content cmd=run duration=xxx
rule=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=dictionary cmd=run dictionary=xxx
duration=xxx score=xxx rule=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=session cmd=judge module=xxx
rule=xxx

• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=session cmd=dispose module=xxx

action=<reject|deliver|quarantine|...> rule=xxx
• [yyyy-MM-dd hh:mm:ss.SSSSSS] rprt s=xxx m=xxx mod=mail cmd=msg start=xxx
duration=xxx elapsed=xxx size=xxx attachments=xxx hdr_mid=xxx
Encryption
This entry indicates the number of recipients to whom an encrypted message was sent:
[yyyy-MM-dd hh:mm:ss.SSSS] rprt s=xxx m=xxx x=xxx mod=session cmd=encrypt
secprofile_name=System_Response_Profile rcpts=x duration=x.xxx
Table 4. Message Level mod Definitions
mod Description
mail Indicator for mail flow.
spam Spam Detection Module.
av Virus Protection Module.
access Email Firewall Module.
content Content Compliance

Module.
122
Appendix B Alerts
This Appendix describes email alerts sent by the Proofpoint Protection Server.
ID: eid.general
Category: system
Title: General Error
Description: Cannot deploy. An error occurred when setting up the upgrade.
Severity: major
Resolution: Retry the upgrade. If the problem happens again, contact support.proofpoint.com.
ID: eid.admin.update.upgrade_failed
Category: update
Title: Upgrade failed
Description: Cannot upgrade. An error occurred when performing an upgrade.
Severity: major
Resolution: Retry the upgrade. If the problem happens again, contact support.proofpoint.com.
ID: eid.admin.update.upgrade_failed
Category: update
Title: Upgrade failed
Description: Cannot upgrade. An error occurred when performing an upgrade.
Severity: major
Resolution: Retry the upgrade. If the problem happens again, contact support.proofpoint.com
ID: eid.admin.update.update_available
Category: update
Title: update available
Description: Update is available.
Severity:
Resolution:
ID: eid.admin.update.update_successful
Category: update
Title: Update deployed successfully
Description: Update deployed successfully.

Appendix B - Alerts
Severity:
Resolution:
ID: eid.admin.update.update_reboot
Category: update
Title: Update done. Reboot is required
Description: Reboot your machine.
Severity: normal
Resolution: Reboot your machine.
ID: eid.admin.patch.manual_deploy_required
Category: patch
Title: A patch that requires manual deployment is available
Description: A patch has been distributed that requires manual deployment. Please use the
management interface to deploy the patch.
Severity: normal
Resolution:
ID: eid.admin.patch.deploy_failed
Category: patch
Title: A patch has failed to deploy
Description: A patch has failed to deploy. Please try to deploy the patch again.
Severity: normal
Resolution:
ID: eid.admin.license.license_expired
Category: licensing
Title: License expired
Description: Some module licenses have expired.
Severity: major
Resolution: Contact support.proofpoint.com for information about your licenses.
ID: eid.admin.license.license_will_expire.category
Category: licensing
Title: License will expire
Description: Some module licenses will expire soon.
Severity: major
Resolution: Contact support.proofpoint.com for information about your licenses.
124
Appendix B - Alerts
ID: eid.admin.system.cannot_connect_server
Category: system
Title: Cannot connect to update server
Description: PPS server cannot connect to the update server and receive update information
Severity: normal
Resolution: Make sure your network connection is functional.
ID: eid.admin.system.out_of_disk_space
Category: system
Title: Running out of disk space
Description: System is running out of disk space
Severity: normal
Resolution: Free up some disk space for the system. For example, delete previous versions of the
Proofpoint Protection Server software, or set the Quarantine expiration period to a
shorter time.
ID: eid.admin.system.out_of_date
Category: system
Title: Module out of date
Description: Module is out of date
Severity: normal
Resolution: Activate with a valid activation ID to receive the latest module updates.
ID: eid.admin.system.cannot_connect_repository
Category: system
Title: Cannot connect to the repository
Description: Cannot connect to the repository
Severity: normal
Resolution: Make sure your Proofpoint Protection Server database is running.
ID: eid.admin.smtp.queue
Category: system
Title: SMTP queue alert
Description: SMTP Queue alert
Severity: normal
Resolution: Possibly caused by a connection error, network error, or the remote server is
unavailable.

Appendix B - Alerts
ID: eid.admin.log.loader
Category: log
Title: Log loader alert
Description: Log loader alert email
Severity: normal
Resolution: Check var/log/cron/loader_*.log
ID: eid.admin.log.xfer
Category: log
Title: Log transfer alert
Description: Log transfer alert email
Severity: normal
Resolution:
ID: eid.admin.log.collector
Category: log
Title: Log Collector alert
Description: Log collector alert email
Severity: normal
Resolution: Check var/log/cron/logcollector_*.log
ID: eid.admin.log.parser
Category: log
Title: Log parser alert
Description: Log parser alert email
Severity: normal
Resolution: Check var/log/cron/logparser_*.log
ID: eid.admin.log.watchdog
Category: log
Title: System watchdog alert
Description: System Watchdog Alert
Severity: normal
Resolution: Check var/log/cron/watchdog_*.log
ID: eid.admin.log.logpusher
Category: log
Title: Log pusher alert
Description: Log Pusher Alert email
126
Appendix B - Alerts
Severity: normal
Resolution: Check var/log/cron/logpusher_*.log
ID: eid.admin.quarantine.expire
Category: quarantine
Title: Quarantine expiration alert
Description: Quarantine Expiration Alert
Severity: normal
Resolution:
ID: eid.admin.quarantine.consolidate
Title: Quarantine consolidation alert
Description: Quarantine Consolidation Alert
Severity: normal
Resolution:
ID: eid.admin.enduser.digest
Category: enduser
Title: End User digest alert
Description: End User Digest Alert
Severity: normal
Resolution:
ID: eid.admin.enduser.service
Category: enduser
Title: End User service alert
Description: End User Service Alert
Severity: normal
Resolution:
ID: eid.admin.user.repository.import
Category: user repository
Title: User repository import alert
Description: User Repository Import Alert
Severity: normal
Resolution:

Appendix B - Alerts
ID: eid.filter
Category: system
Title: Filter Error
Description: Email filtering error
Severity: normal
Resolution: Check your filter configuration and filter error log.
ID: eid.plinx.log.plinxmonitor
Category: log
Title: Appliance Watchdog Alert
Description: Appliance Watchdog Alert
Severity: normal
Resolution:
ID: eid.plinx.log.sel
Category: log
Title: Appliance hardware alert
Description: Appliance Hardware Alert
Severity: normal
Resolution:
ID: eid.quarantine.folderinjection
Title: Folder injection rate alert
Description: Folder injection rate is too high
Severity: normal
Resolution:
ID: eid.quarantine.folderinjection_reset
Title: Folder injection rate reset
Description: Folder injection rate is back to normal
Severity: normal
Resolution:
ID: eid.quarantine.dbmsgqueueprocessor
Category: consolidate
Title: Dbmsgqueue processor alert
Description: Database Message Queue Processor Alert
128
Appendix B - Alerts
Severity: normal
Resolution: Check var/log/cron/dbmsgqueueprocessor* log files on the agent, and
var/log/cron/dbmsgqueuemgmt* and
var/log/httpd-apiservice/http_error-apiservice.log log files on the
quarantine master
ID: eid.quarantine.dbmsgqueuemgmt
Category: consolidate
Title: Dbmsgqueue processor dbms management alert
Description: Database Message Queue Processor Alert
Severity: normal
Resolution: Check var/log/cron/dbmsgqueuemgmt* and
var/log/httpd-apiservice/http_error-apiservice.log on the quarantine
master
ID: eid.quarantine.procmsgs.poppoller.mbox
Category: digest
Title: Digest processor mbox alert
Description: Digest processor cannot open mailbox file
Severity: normal
Resolution: Check var/log/cron/procmsgs_*.log
ID: eid.quarantine.procmsgs.poppoller.pop3
Category: digest
Title: Digest processor pop3 alert
Description: Digest processor cannot connect to pop3 server
Severity: normal
ID: eid.quarantine.procmsgs.forwarder.getprofile
Category: digest
Title: Digest processor user profile alert
Description: Digest processor cannot get user profiles
Severity: normal
ID: eid.quarantine.procmsgs.forwarder.openfolder
Category: digest
Title: Digest processor remote mailbox alert
Description: Digest processor cannot open user remote mailbox

Appendix B - Alerts
Severity: normal
ID: eid.quarantine.procmsgs.forwarder.getmsgs
Category: digest
Title: Digest processor get messages alert
Description: Digest processor cannot read messages from user remote mailbox
Severity: normal
ID: eid.quarantine.procmsgs.forwarder.submitmsg
Category: digest
Title: Digest processor forward message alert
Description: Digest processor cannot forward message
Severity: normal
130
Glossary
This glossary provides definitions for acronyms and terms found in the Reference Guide.
action The action is what happens to messages after filtering by the Proofpoint
Protection Server.
administration server A system with Proofpoint Protection Server installed but is used strictly
for monitoring, configuring, and reporting on the filter servers in a cluster.
This system may have all filtering modules disabled, and is strictly used
for centralized administration of all other filter servers.
access list Access Control List
agent The software running on agent systems that accepts configuration

changes from the master administration server.
API Application Program Interface
CLI Command Line Interface
classification Every analysis module classifies messages by conditions that you define.
When a message meets the criteria defined by these conditions, an
action is applied to it. The condition together with the action comprise the
rule.
condition The Virus Protection Module classifies messages into one of three
conditions: not infected or error (corrupt).
CSV Comma Separated Value.
DAT Virus definition file.
dictionary A list of words with a weight assigned to each word. The Content
Compliance Module uses the dictionary to score words in a message,
then add up the total score for the message.
Command Processor The program on the master Proofpoint Protection Server that processes
requests from end users to release messages from the Quarantine.

Glossary
disposition An action applied to a message based upon rules and classifications.

The actions are: deliver the message, reject it, or send it to the
Quarantine.
DNS Domain Name Server
DoS Denial of Service
filter server A Proofpoint Protection Server that is deployed only for filtering services.
Administration and configuration tasks are completed from another
system (the master server), and pushed to the filter server. Filtering
servers are also known as agent systems.
GB Gigabyte
GLBA Gramm Leach Bliley Act (Financial Services Modernization Act of 1999)
HIPAA Health Insurance Portability and Accountability Act (1996)
IDE Sophos virus Identity Files.
IP Internet Protocol
LDAP Lightweight Directory Access Protocol
LDIF Lightweight Directory Interchange Format
master server A Proofpoint Protection Server that is deployed for both filtering and
administration services. This system monitors and manages all other
Proofpoint Protection Servers in the cluster, and pushes configuration
changes to the agents on filtering servers.
MB Megabyte
Milter Mail Filter
MIME Multi-purpose Internet Mail Extension
MTA Message Transfer Agent
MX Mail exchange
NDR Non-delivery report
PFI Personal Financial Information
132
Glossary
PHI Protected Health Information
POP Post Office Protocol
Quarantine A repository for storing messages for further analysis. The master
Quarantine resides on the master Proofpoint Protection Server. Each
agent in a cluster maintains local a Quarantine Queue.
Quarantine The program running on agent systems that transfers messages from the
Consolidator Quarantine Queue to the master Proofpoint Protection Server
Quarantine.
Quarantine Queue A temporary Quarantine repository that is local to each agent system in a
cluster.
rule The Content Compliance Module classifies messages by conditions such

as maximum message size, maximum number of recipients, attachment
type, and attachment count. When a message meets the criteria defined
by these conditions, an action is applied to it. The condition together with
the action comprise the rule.
SAV Sophos Anti-Virus
S/MIME Secure Multi-Purpose Internet Mail Extension
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SQL Structured Query Language
SSL Secure Sockets Layer
tag The Protection Server configuration is comprised of a set configuration

files. Each file is tracked internally, as they can change independently of
one another. A tag identifies a set of configuration files at a specific point
in time.
TLS Transport Layer Security
URI Uniform Resource Identifier
URL Uniform Resource Locator
weight An integer (positive whole number) assigned to a word to designate the

word as acceptable or not.

134
Index
A filter.cfg, modifying 89
administrator accounts 35 filtering order 17
agents and master 16 G
agents, passwords for communication 35
groupadm command 101
appliance
routing email 40 H
B high availability 23
Blocked Senders list 21 I
C Interface Hub, description 18

centralized management 22 L
command line interface
log
dautil 108
detail 120
groupadm 101
entry format 119
log_upload 110
file naming 120
logdbutil 110
levels 120
pps_control 88
log_upload command 110
pps_ctrlpoint 86
logdbutil command 110
qdbutil 104
useradm 90 M
CSV file format, for import 94 managed modules 36
D management, centralized 22
master and agents 16
dautil command 108
message
delivery dispositions 18
connection state 21
Denial of Service attack, stopping 37
copies in the Quarantine 21
disk space
path 17
alerts 50
Message Disposition Hub, description 18
freeing 50
Message Processing Hub, description 18
monitoring 48
modules, controlling access 36
reducing amount used 49
N
E
network time, synchronizing a cluster 44
embedding report in HTML page 113
End User Digest P
customize 31 password control 36
description 21 ports 36
user actions 34 postmaster address 41
F pps_control command 88
pps_ctrlpoint command 86
failover support 27

Index
publishing reports to web pages 113
Q
qdbutil command 104
Quarantine
description 21
organizing with folders 45
query for outbound messages 47
Quarantine Consolidator 21
Quarantine Node
adding 116
enabling 115
performance 116
recovering 116
R
report
publishing to web page 113
S
Safe Senders list 21
sendmail
configuring FQDN 41
editing the mailertable 39
FQDN 41
obscuring 38
Spam Detection Module
message flowchart 43
tuning 43
spam policies 22
system
operating system tuning 40
T
terminology 19
U
unwanted email, discarding 46
User Repository
command line interface 90
LDAP import 45
useradm command 90
W
Web Application 21
web pages, publishing reports to 113
136

Proofpoint Reference Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Proofpoint Reference Guide

Transféré par

Droits d'auteur :

Formats disponibles

Proofpoint

Proofpoint Protection Server®

Copyright and Trademark Notices

Proofpoint and Proofpoint Protection Server are trademarks of Proofpoint Inc.

F-Secure Anti-Virus Copyright © 1993-2012, F-Secure Corp.

MariaDB licensing information is available in the directory ${PROOFPOINT_ROOT}/opt/mariadb.

Apache 2.2 licensing information is available at http://www.apache.org/licenses.

Perl (Practical Extraction and Report Language) is copyrighted by Larry Wall.

Some database support in this solution is provided by MySQL.

Copyright © 1986 - 1993, 1998, 2004 Thomas Williams, Colin Kelley

Copyright © 2012 Sendmail, Inc. All Rights Reserved.

Copyright © 2005, Google Inc.

Copyright © 1996 - 2010, Daniel Stenberg, <daniel@haxx.se>.

Copyright © 2012. Proofpoint, Inc. All rights reserved.

How This Book Is Organized

Appendix B, “Alerts,” lists alert messages.

Release 7.0 Reference Guide 7

• Text that you type is shown in bold courier font.

Chapter 1 – Introduction .................................................................................................................................. 15

Chapter 2 – Deployment and Installation ....................................................................................................... 23

Chapter 3 – End User Digests ......................................................................................................................... 29

Chapter 4 – Security ......................................................................................................................................... 35

The Default Administrator Password .................................................................................................... 35

Chapter 5 – Tuning and Configuration ........................................................................................................... 39

Chapter 6 – Maintenance and Troubleshooting ............................................................................................ 47

Chapter 7 – Message Filtering ........................................................................................................................ 69

Chapter 8 – Command Line Interface ............................................................................................................ 85

Commands for the Log Collection Service ................................................................................................ 110

Appendix A – Log File Format ...................................................................................................................... 119

Appendix B – Alerts ....................................................................................................................................... 123

Glossary .......................................................................................................................................................... 131

Index ................................................................................................................................................................ 135

Release 7.0 Reference Guide 13

The Proofpoint Protection Server is comprised of these components:

Release 7.0 Reference Guide 15

Management Services – centralized management services include message tracing, administration,

Proofpoint Protection Server

Message Processing Hub

forward or reply with annotation

Figure 1. Path of a message through the Proofpoint Protection Server

Filtering Order for the Modules

Message Processing Hub

Release 7.0 Reference Guide 17

Message Disposition Hub

Modules, Rules, Conditions, and Dispositions

A module is an application that performs a specific filtering task.

The following table describes the internal sequence of events:

Priority Sequence of Events

Release 7.0 Reference Guide 19

Priority Sequence of Events

Message state - the information each module

Reject (no more processing)

Email Firewall R, C, Q, RR Virus Protection

Figure 2. Message Dispositions

Message Connection State

Quarantine and Incident Queue

End User Digest

Safe Senders/Blocked Senders List

Release 7.0 Reference Guide 21

Spam Polices and Rules

Consider these options for routing mail to the agent systems:

Release 7.0 Reference Guide 23

Master-Agent Cluster Architecture

Figure 3. Master-Agent Cluster