Release 7.0 Proofpoint, Inc. 892 Ross Drive Sunnyvale, CA

Transcription

1 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

2 Website: Toll-free telephone: POINT Proofpoint Technical Support: Reference Guide Proofpoint Messaging Security Gateway Proofpoint Protection Server February 2012 Revision A

3 Proofpoint Protection Server 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 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 , 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 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 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 , 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 The FreeType Project ( 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.

4 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 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 ( zlib.h interface of the zlib general purpose compression library version 1.2.2, October 3rd, 2004 Copyright 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 [email protected] Mark Adler [email protected] Unifont copyright Paul Hardy of Unifoundry.com ([email protected]) released under the terms of the GNU General Public License (GNU GPL) version 2.0. Tomcat, Log4j, Apache CXF Apache Copyright 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 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

5 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 , Daniel Stenberg, 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 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 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.

6

7 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

8 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 to [email protected]. Proofpoint strives to produce high-quality and technically accurate documentation. Please include the name of the document and the revision date with your . Your feedback is greatly appreciated and will help us maintain our high standards for our product documentation. 8

9 Contents Preface How This Book Is Organized Conventions Documentation Feedback Chapter 1 Introduction Filtering Order for the Modules Message Processing Hub Interface Hub Message Disposition Hub Modules, Rules, Conditions, and Dispositions Terminology Message Connection State Quarantine and Incident Queue End User Digest Web Application Safe Senders/Blocked Senders List Spam Polices and Rules Centralized Management Chapter 2 Deployment and Installation High Availability Deployment Options Master-Agent Cluster Architecture Use Case Multiple Clusters in a University Full Redundancy with Directory Protection No Redundancy Redundancy without Directory Protection Scaling Failover Support Chapter 3 End User Digests Educate the User Community Customize Digest Labels and Select a Language for Ease of Use Customize the Digest Layout Customize Digest Labels and Help Creating Unique Translations for the Digest Editing a.cfg file with a UTF-8 Compliant Editor POP3 Links versus HTTP Links for Digest Actions Release 7.0 Reference Guide 9

10 Contents Chapter 4 Security Administrator IDs and Passwords The Default Administrator Password Agents and Passwords Administrators and Modules Password Control Proofpoint Protection Server Security Tips Locking Down the Server SSL Over HTTPS Security Resources Stopping Denial of Service Attacks Creating Firewall Rules Proofpoint Protection Server Limiting the Number of Connections Obscuring sendmail Chapter 5 Tuning and Configuration Routing Proofpoint Protection Server Editing the Sendmail Mailertable Appliance Routing Operating System Tuning Adding a Legitimate Postmaster Address Proofpoint Protection Server Appliance Detecting Mail Loops Proofpoint Protection Server Configuring the FQDN within Sendmail Notes on Customizing the sendmail.mc File Tuning the Spam Detection Module Synchronize the Cluster with Network Time Protocol Use Quarantine and DLP Incident Folders to Organize Messages Keep the User Repository Current Use the Discard Disposition for Unwanted Catching Spam Containing Cyrillic Characters Chapter 6 Maintenance and Troubleshooting Creating a Query for Outbound Messages In the Quarantine Excluding Spammers from the Outbound Message Query Blocking with Specific Character Sets Monitoring and Controlling Disk Space Monitoring the Disk Space Freeing Up Disk Space Used by the Quarantine Reducing the Amount of Disk Space Used by the logdb Creating an Alert Proofpoint Protection Server Freeing Up Disk Space On the Master On the Agent Database and NFS

11 Contents Log Database Schema Notes Database Schema Filtered Messages Firewall Module Digital Assets Module Message Attachment Content Table Dictionary Message Disposition Envelope Sender Envelope Recipient Error Job Scheduler Favorite Reports From Host Judgement Session Connection Information Milter Session Connection Information Spam Detection Module Virus Protection Module End User Digests Quarantine LDAP Import Zero-Hour Anti-Virus Module Messages Delayed in a Quarantine Folder Summary Control Summary Page Summary Status SMTP Rate Control Module Information Regulatory Compliance Proofpoint Encryption Chapter 7 Message Filtering The Path of a Message through the Filtering Process Criteria for Analyzing and Determining the Outcome of a Message SMTP Protocol Filtering Modules Delivery Dispositions Quarantine Folders and Rule Ordering Message Processing and Composite Rules Sending Copies of Messages to the Quarantine Authoritative Rules Delivery Dispositions and Delivery Options Recipient Verification in the Firewall Recipient-based Rules Putting It All Together Rules Triggering in the Same Module Release 7.0 Reference Guide 11

12 Contents Example Example Example Rules Triggering Across Modules Example Example Use Case Examples Chapter 8 Command Line Interface Commands for Tagging and Pushing Configuration Changes Tagging a File Set Rolling Back a File Set pps_ctrlpoint Usage Examples Stopping, Starting, and Refreshing the Server Listing Configuration Tags Getting Parameters Setting a Parameter Commands for Processes pps_control Usage Making Configuration Changes to filter.cfg Commands for the User Repository useradm Usage Import Attributes CSV File Format CSV Text File Example Examples for the useradm Utility Simple Imports Imports that Include Groups Advanced Imports Commands for Group Management groupadm Usage Examples Examples for the groupadm Utility Commands for Quarantine Management qdbutil Usage Database Operations Folder Operations Message Operations Query Options Examples Commands for the Digital Assets Module datutil Usage Options Examples Commands for the Log Database logdbtutil Usage Options

13 Contents Commands for the Log Collection Service log_upload Usage Options Commands for Buffer Queue Management queued Usage Options Cloning an Agent clone_config Usage Options Publishing URLs to an External Web Page Embedding Report Data in an HTML Page Enabling a Quarantine Node Enable the Management Interface Add the Quarantine Node Performance Optimization Recovering a Quarantine Node Recovering a Master Proofpoint Protection Server Appendix A Log File Format Log Entry Format Log File Naming Log Detail Service Level Session Level Message Level Encryption Appendix B Alerts Glossary Index Release 7.0 Reference Guide 13

14 14

15 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 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. Release 7.0 Reference Guide 15

16 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. Proofpoint Protection Server Firewall Virus Protection Spam Detection Regulatory Compliance Digital Assets sendmail Interface Hub Current Message and Connection State Message Disposition Hub Quarantine Message Processing Hub forward or reply with annotation Figure 1. Path of a message through the Proofpoint Protection Server 16

17 Chapter 1 - Introduction 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. Firewall Module. The 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 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, subdomain, 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 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. Release 7.0 Reference Guide 17

18 Chapter 1 - Introduction 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 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 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 ( 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

19 Chapter 1 - Introduction 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 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: 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. Release 7.0 Reference Guide 19

20 Chapter 1 - Introduction 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 sendmail Milter SMTP Connect HELO From Rcpt Header End of Header Message body End of body C= Continue R= Reject RT= Retry D= Discard RR= Re-route Q= Quarantine 1. Firewall Module 2. Virus Protection Module 3. Spam Detection Module 4. Digital Assets Module 5. Regulatory Compliance Module Firewall Module Reject (no more processing) Deliver Now (no more processing) Q, C, RR Judgement Order Hub Message Disposition R, C, Q, RR RT, D Virus Protection Module Spam Detection Module Digital Assets Module Quarantine Reject Deliver Discard Retry Re-route R, C, Q, RR RT, D R, C, Q, RR RT, D Regulatory Compliance Module R, C, Q, RR RT, D R, C, Q, RR RT, D Figure 2. Message Dispositions 20

21 Chapter 1 - Introduction 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 message that lists the Safe Senders, Blocked Senders, and aliases for the user, giving them an opportunity to add, delete, or modify the list. Users cannot modify aliases they can only view them. Release 7.0 Reference Guide 21

22 Chapter 1 - Introduction 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 , 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

23 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 environment inside your network. To protect your 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 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 . 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 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 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 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. Release 7.0 Reference Guide 23

24 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 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 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 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 , 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, will continue be filtered and delivered to the 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 , filter, and route to the server. Load balancing among the agents 24

25 Chapter 2 - Deployment and Installation 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 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 entry point. In this case a Proofpoint cluster can be deployed for each departmental infrastructure, in addition to the central gateways. Each cluster consists of a master server (for centralized administration, reporting, and Digest generation) and several 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 Release 7.0 Reference Guide 25

26 Chapter 2 - Deployment and Installation design, one server is a dedicated master and does not filter , 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 as well as serve as the central management for administration, the Quarantine, Digest processing, and end user functionality. Figure 5. No Redundancy 26

27 Chapter 2 - Deployment and Installation Redundancy without Directory Protection Figure 6 illustrates a deployment where both master and agent filter 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. Release 7.0 Reference Guide 27

28 Chapter 2 - Deployment and Installation 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

29 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 . 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 policies. Figure 7 on page 30 illustrates an example of an end user Digest sent by 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. Release 7.0 Reference Guide 29

30 Chapter 3 - End User Digests Figure 7. Example of an end user Digest sent by 30

31 Chapter 3 - End User Digests 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 Digest and the Web Application, and you can change the default language for the text as well. The text elements that display in the 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 Release 7.0 Reference Guide 31

32 Chapter 3 - End User Digests 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. 5. Click Save Changes. 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

33 Chapter 3 - End User Digests 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 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. Release 7.0 Reference Guide 33

34 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 . The Client attribute determines how users process Digest actions. For example, if your 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

35 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. Release 7.0 Reference Guide 35

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

37 Chapter 4 - Security Security Resources Consult the following sites for more information on how to secure your Proofpoint Protection Server: (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 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 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 Firewall Rules To prevent DoS attacks using the 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. Release 7.0 Reference Guide 37

38 Chapter 4 - Security 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 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/init.d/sendmail start 38

39 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 After filtering , 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 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 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] Release 7.0 Reference Guide 39

40 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: /etc/init.d/sendmail stop /etc/init.d/sendmail start 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 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 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 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

41 Chapter 5 - Tuning and Configuration 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 and 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. Proofpoint Protection Server 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 address for the postmaster. For example: postmaster:[email protected] 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 address into the Postmaster Address field. 4. In addition, if you want to receive messages about system level activity in your root account, enter your address in the System Administrator Address field. 5. Click Save Changes. Detecting Mail Loops Check the MTA log to ensure that 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. Release 7.0 Reference Guide 41

42 Chapter 5 - Tuning and Configuration 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 4. Save the changes and close the sendmail.mc file. 5. Stop and start sendmail: /etc/init.d/sendmail stop /etc/init.d/sendmail start 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

43 Chapter 5 - Tuning and Configuration 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 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 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 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 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. Release 7.0 Reference Guide 43

44 Chapter 5 - Tuning and Configuration 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 Spam Probable Spam Not Spam Disposition A And adult content Disposition B Disposition C And adult content Disposition D Continue Note: Filtering for adult 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

45 Chapter 5 - Tuning and Configuration 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. Release 7.0 Reference Guide 45

46 Chapter 5 - Tuning and Configuration Use the Discard Disposition for Unwanted 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 infrastructure, use the Discard disposition instead of Retry or Reject. Since spammers typically use spoofing for sending , 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 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 viruses (such as bagel, mydoom, or netsky, for example). Do not use the Reply to sender delivery option because these are 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 Firewall Module rule to filter and discard messages containing Cyrillic characters. To create a rule to discard messages containing Cyrillic characters: 1. Click the 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 Select the Discard radio button for the Delivery Method. 9. Click Save Changes to save the rule. 46

47 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 , 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 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 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 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 originating from an internal IP address in your organization. Release 7.0 Reference Guide 47

48 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 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, %. 8. Click the Save link. 9. Click the Search button to find the messages in the Quarantine. Note: The % 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 with Specific Character Sets To create an Firewall rule to block messages with a specific character set, you need to reference the appropriate character encoding. For example you want to block s 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 Firewall that filters for this header, you can block messages containing Cyrillic characters. Create a rule where the Condition is 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 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 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 s that refer to the character set in the body of the . 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

49 Chapter 6 - Maintenance and Troubleshooting 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 tables User Repository data tables can reduce size by deleting tables cannot reduce the size by 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. 5. Click Save Changes. Release 7.0 Reference Guide 49

50 Chapter 6 - Maintenance and Troubleshooting 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. 5. Click Save Changes. 6. Click the Report Settings link under Logs and Reports in the navigation pane. 7. Enter a smaller number into the Maximum Rows field. 8. Click Save Changes. Creating an Alert Create an alert to send 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 Trigger Settings, enter a value into the Available System Disk Space Less Than field. When the disk space reaches this size an alert is sent to the recipient listed in the default profile on the Alert Profiles page. 3. Click Save Changes. 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

51 Chapter 6 - Maintenance and Troubleshooting 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 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 Release 7.0 Reference Guide 51

52 Chapter 6 - Maintenance and Troubleshooting 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

53 Chapter 6 - Maintenance and Troubleshooting 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. Release 7.0 Reference Guide 53

54 Chapter 6 - Maintenance and Troubleshooting 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). Firewall Module Table - Access Column Type Description Access Firewall module operations table, one operation per message. 54

55 Chapter 6 - Maintenance and Troubleshooting Table - Access Column Type Description Duration Unsigned float The duration of time the message is processed by the 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. Duration Unsigned float The duration of time the message is processed by the Digital Assets module. Rule Varchar(32) The triggered rule. 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. Duration Unsigned float The duration of time the message is processed by the Content module. Release 7.0 Reference Guide 55

56 Chapter 6 - Maintenance and Troubleshooting Table - Content Column Type Description Rule Varchar(32) The triggered rule. Route Varchar(255) The Policy Route names, delimited by commas (,). Protocol Varchar(32) The network protocol. Dictionary Table - Dictionary Column Type Description Dictionary Dictionary module operations table (1-N per message). Name Varchar(32) The name of the Dictionary module. Duration Unsigned float The duration of time the message is processed by the Dictionary module. Rule Varchar(32) The triggered rule. 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. Rule Varchar(128) The triggered rule. 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

57 Chapter 6 - Maintenance and Troubleshooting 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 the envelope recipient received a adult spam message. Virus Tinyint A flag to indicate whether or not the envelope recipient received a message containing a virus. Release 7.0 Reference Guide 57

58 Chapter 6 - Maintenance and Troubleshooting 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

59 Chapter 6 - Maintenance and Troubleshooting 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 (,). Protocol Varchar(32) The network protocol. Release 7.0 Reference Guide 59

60 Chapter 6 - Maintenance and Troubleshooting 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

61 Chapter 6 - Maintenance and Troubleshooting 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. Release 7.0 Reference Guide 61

62 Chapter 6 - Maintenance and Troubleshooting 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 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

63 Chapter 6 - Maintenance and Troubleshooting 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, addr). 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. Release 7.0 Reference Guide 63

64 Chapter 6 - Maintenance and Troubleshooting 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 (,). Protocol Varchar(32) The network protocol. 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

65 Chapter 6 - Maintenance and Troubleshooting 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. Duration Unsigned float The duration of time the message is processed by the module. Rule Varchar(32) The triggered rule. Attribute Varchar(32) Not used. Release 7.0 Reference Guide 65

66 Regulatory Compliance Table - Asset Column Type Description Regulation The Regulatory Compliance module operations table, 1-N per message. Duration Unsigned float The duration of time the message is processed by the Regulatory Compliance module. Rule Varchar(32) The triggered rule. 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. Rule Varchar(32) The triggered rule. 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 67

68

69 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 filtering products accept an message and process it in its entirety, the Proofpoint Protection Server extends granular analysis to the components that make up an 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. Release 7.0 Reference Guide 69

70 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 Precedence Connection (IP, Helo) Envelope (mail from, rcpt to...) Data Headers Size Firewall (and Custom Spam rules) Virus Protection Spam Detection Throttle Execute Quarantine Secure Reject Virus Protection Spam Detection Digital Assets Regulatory Compliance MIME parts 1 (Attachment, body - HTML/text) End-of-body 2 and composite conditions using AND logical operator Regulatory Compliance Digital Assets Retry Redirect Discard Deliver Now Firewall (and recipient verification) Audit Lowest Figure 1. Filtering Events in Order 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.) 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

71 Chapter 7 - Message Filtering 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 Release 7.0 Reference Guide 71

72 Chapter 7 - Message Filtering 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 Firewall module and in the Regulatory Compliance module, the Firewall rule will trigger first. The filtering modules take precedence in the following order: 1. 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 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

73 Chapter 7 - Message Filtering 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. 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 = [email protected]. Release 7.0 Reference Guide 73

74 Chapter 7 - Message Filtering If a composite rule is filtering for several conditions (of the same type) strung together with the logical operator OR (recipient equals [email protected] OR [email protected] OR [email protected]), it is represented as: rulename.condition.1 = $rcpt = [email protected] rulename.condition.2 = $rcpt = [email protected] rulename.condition.3 = $rcpt = [email protected] If a composite rule is filtering for several conditions (of the same type) strung together with the logical operator AND (recipient equals [email protected] AND [email protected] AND [email protected]), it would be represented as: rulename.condition.1 = ((rcpt('[email protected]'))&&(rcpt('[email protected]')&&(rcpt('[email protected]' ))) 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

75 Chapter 7 - Message Filtering Authoritative Rules To protect your network from hazards, rules that you create for the 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 ( 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 Firewall The 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 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 Release 7.0 Reference Guide 75

76 Chapter 7 - Message Filtering 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 (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 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

77 Chapter 7 - Message Filtering 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 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 Release 7.0 Reference Guide 77

78 Chapter 7 - Message Filtering 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 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. Figure 3. Example 2 filtering in the same module 78

79 Chapter 7 - Message Filtering 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 Firewall module. The rule that takes precedence is based upon the message processing callback priority. Example 3 a message from [email protected] triggers the following rules in the Firewall module: Rule 1 Composite rule: the sender IP address equals 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. Figure 4. Example 3 filtering in the same module 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.) Release 7.0 Reference Guide 79

80 Chapter 7 - Message Filtering 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 Firewall and Virus Protection modules: Rule 1 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 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

81 Chapter 7 - Message Filtering Outcome: The rules for the Firewall (Rule 1 and Rule 2) will trigger before the rule for the Virus Protection module (Rule 3) because 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 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 Firewall and Spam Detection modules: Rule 1 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. Release 7.0 Reference Guide 81

82 Chapter 7 - Message Filtering Figure 6. Example 2 filtering across modules Outcome: The rule for the 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 Firewall module. 82

83 Chapter 7 - Message Filtering Use Case Examples This section contains more use case examples for the final disposition of a message when different rules are triggered in the Firewall, Spam Detection, and Virus Detection modules. The Proofpoint Protection Server is configured with the following rules: Rule 1 Firewall module. Recipient Verification is enabled. If a message is addressed to an Invalid Address, the disposition is to send a copy of the message to the Quarantine folder named invalid_recipient. Rule 2 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 Firewall module. Case 2: Message has invalid recipient and no body, but does include a subject. Outcome 2: 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. Release 7.0 Reference Guide 83

84 Chapter 7 - Message Filtering 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 1 triggers first because the recipient is invalid and applies the Quarantine disposition, so the message continues to process. 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 Firewall module. Case 4: Message has invalid recipient, includes subject, includes body, does not contain a virus. Outcome 4: Rule 1 triggers first because the recipient is invalid and applies the Quarantine disposition, so the message continues to process. 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 Firewall module from Rule 1. 84

85 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 dictionary1 dictionary Tag: Production_10_15_2011 Release 7.0 Reference Guide 85

86 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 stop refresh listtags Start the Proofpoint Protection Server. Stop the Proofpoint Protection Server. Refresh the Proofpoint Protection Server configuration. 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

87 Chapter 8 - Command Line Interface 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 -u <username> -w <password> stop To start message filtering on the Proofpoint Protection Server: Enter the following command at the system prompt: $ pps_ctrlpoint.sh -H -u <username> -w <password> start To refresh the configuration cache on the Proofpoint Protection Server: Enter the following command at the system prompt: $ pps_ctrlpoint.sh -H -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 -u <username> -w <password> listtags The Proofpoint Protection Server returns information that looks similar to this: ok configuration_ _ _ proofpoint updated filter.cfg for install location test _ admin test1 test _ admin test2 test _ admin test5 test _ admin test6 Release 7.0 Reference Guide 87

88 Chapter 8 - Command Line Interface To tag a new configuration set: $ pps_ctrlpoint.sh -H -u <username> -w <password> tag -tag test7 -comment "this is test7" The Proofpoint Protection Server returns information that looks similar to this: ok tag test7 created To roll back to a previous tag set: $ pps_ctrlpoint.sh -H -u <username> -w <password> deploy - tag test1 The Proofpoint Protection Server returns information that looks similar to this: ok active tag set to test1 Getting Parameters To view a specific parameter: $ pps_ctrlpoint.sh -H -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 -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

89 Chapter 8 - Command Line Interface gracefulrestart refresh restart start stop status version Restarts the management interface child processes without affecting the parent process. Reloads the information for the process specified by option, without stopping the process. If no option is specified, reloads all processes. Stops and starts the process specified by option. If no option is specified, stops and starts all processes. Starts the process specified by option. If no option is specified, starts all processes. Stops the process specified by option. If no option is specified, stops all processes. 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. Returns the software version for the process specified by option. If no option is specified, returns the version for all processes. Options: admin db digest encrypt pss filter httpd Web-based management interface. Database process. Digest Command Processor. Proofpoint Encryption. Proofpoint Smart Search. Filtering engines. 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. Release 7.0 Reference Guide 89

90 Chapter 8 - Command Line Interface 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 -u <username> -w <password> deploy 7. Refresh the configuration on the Proofpoint Protection Server: $./pps_ctrlpoint.sh -H -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 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

91 Chapter 8 - Command Line Interface Table 1. useradm Command Options Option [-allowlocal] [-attrdefault <attribute=value>] [-attrnamemap <internalattr=externalattr>] [-attrvalue <attribute=value>] Parameter is case-sensitive No No No Description Allow local address. During an import, assigns default values to user attributes if the import source does not already have the values defined. Map internal attribute name to the external (import source) attribute name. Force the attribute(s) to have a specific 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 protected]> [-export -e] <file> [-exportpwd] No Specify the filter to use during an import. Exports the User Repository to a CSV file. 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. Release 7.0 Reference Guide 91

92 Chapter 8 - Command Line Interface Option Parameter is case-sensitive Description [-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] [-ldapversion] <version> [-list -l] [-listobjectclass] <your-argument> No Use SSL for the connection to the LDAP server. Sets the LDAP protocol version, using one of these versions: 3 LDAPv3 (this is the default). 2 LDAPv2. Displays the current profiles ( addresses) in the User Repository. By default, Proofpoint uses the objectclass 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

93 Chapter 8 - Command Line Interface Option Parameter is case-sensitive Description [-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 [-removeold] [-removeoldgroup] During an import, removes entries in the existing User Repository that do not exist in the data source. 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. Release 7.0 Reference Guide 93

94 Chapter 8 - Command Line Interface Option [-starttls] Parameter is case-sensitive Description 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] [-verbose -v] During an import, use uid as the primary key to locate the user records in the data source. 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

95 Chapter 8 - Command Line Interface Table 2. Import Attributes and Values Proofpoint internal name for the attribute Corresponding source attribute Proofpoint 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. Addr mail address Text. address. FirstName givenname First name Text. LastName sn Last name Text. ProfileType usertype User or mailing list 0 = user 1 = mailing list ATTR_ALIASES proxyaddresses, mailalternateaddress, userprincipalname, mailforwardingaddress othermailbox (Note: when importing from a CSV file, use proxyaddresses for the column heading.) Aliases Text. For CSV, separate each entry with a semi-colon, using this format: <attribute>:add1@exampl e.com;[email protected]. For LDAP, place each entry on a separate line, using this format: <attribute>:add1@exampl e.com <attribute>:add2@exampl e.com. ATTR_BLACKLIST blacklist Blocked Senders list Text. For CSV, separate each entry with a semi-colon, using this format: blacklist:add1@example. com;[email protected]. For LDAP, place each entry on a separate line, using this format: blacklist:add1@example. com blacklist:add2@example. com. ATTR_GROUP memberof Group Text. Use same CSV or LDAP format as attr_aliases. ATTR_OBJECTCLASS objectclass Mailing list. mailgroup. Use same CSV or LDAP format as attr_aliases. Release 7.0 Reference Guide 95

96 Chapter 8 - Command Line Interface Proofpoint internal name for the attribute Corresponding source attribute Proofpoint attribute description Value ATTR_OWNER owner Owner or delegated owner Text. address. Use same CSV or LDAP format as attr_aliases. ATTR_WHITELIST whitelist Safe Senders list Text. For CSV, separate each entry with a semi-colon, using this format: whitelist:add1@example. com;[email protected]. For LDAP, place each entry on a separate line, using this format: whitelist:add1@example. com whitelist:add2@example. com. -1 = Default setting * 1 = HTML/Text 2 = Text Only 3 = HTML Only DigestContentType contenttype Digest Format parameters 4 = HTML/Text + HTTP commands 5 = HTML Only + HTTP commands 6 = Simple HTML/Text 7 = Simple HTML 8 = Simple HTML/Text + HTTP 9 = Simple HTML + HTTP SendEmptyDigest emptydigest Empty Digest parameters -1 = Default setting* 1 = Do Not Send Empty Digest 2 = Send Empty Digest IncludeAuditFolder IncludeAuditFolder Include Audit folder in Digest -1 = Default setting* 1 = Do Not Include Audit Folder 2 = Include Audit Folder SendDigest SendDigest Send Digest -1 = Default setting* 0 = Do Not Send Digest 1 = Send Digest SpamClassification SpamClassification Spam policy Text; internal policy name. -1 = Default policy* 96

97 Chapter 8 - Command Line Interface Proofpoint internal name for the attribute Corresponding source attribute Proofpoint attribute description Value MessageAuditing MessageAuditing Audit messages -1 = Default setting* 0 = Do Not Audit Messages 1 = Audit Messages OptIn OptIn Filter messages -1 = Default setting* 1 = Yes 0 = No DigitalAssets DigitalAssets Enforce the Digital Assets Module rules -1 = Default setting* 0 = Do Not Enforce 1 = Enforce DigitalAssetsDocumentCreation DigitalAssetsDocumentC reation Allows specific users to populate the Document Repository in the Digital Assets Module -1 = Default setting* 0 = Do Not Allow 1 = Allow -1 = Default setting* sc = Chinese (Simplified) tc = Chinese (Traditional) nl = Dutch (Netherlands) enus = English (U.S.A.) fr = French (Français) Locale Locale Determines the language for the End User Digest de = German (Deutsch) it = Italian (Italiano) jp = Japanese es = Spanish (Español) fi = Finnish (Suomi) sv = Swedish (Svenska) pl= Polish (Polski) pt = Portuguese ru = Russian da = Danish RegulatoryCompliance RegulatoryCompliance Enforce the Regulatory Compliance Module rules -1 = Default setting* 0 = Do not enforce 1 = Enforce Release 7.0 Reference Guide 97

98 Chapter 8 - Command Line Interface Proofpoint internal name for the attribute Corresponding source attribute Proofpoint attribute description Value SafelistUseHeader SafeListUseHeader Allows users to add senders to their Safe/Blocked Senders lists based on the sender s header From information instead of the sender s envelope information -1 = Default setting* 0 = Do not allow 1 = Allow SecurityPolicy SecurityPolicy Secure Message Profile. Defines the options available to users for Proofpoint Encryption. -1 = Default otherwise, value will be the name of the profile PasswordOption PasswordOption Change Password Allowed. Allows users to change the password they use to log in to the Web Application. -1 = Default 0 = No 1 = Yes AuthSource AuthSource Authentication Source. Specifies the source to use for user authentication, defined by the import or authentication profile. -1 = Default otherwise, value will be the name of the profile PasswordPolicy PasswordPolicy Password Policy -1 = Default otherwise, value will be the name of the profile 98

99 Chapter 8 - Command Line Interface Proofpoint internal name for the attribute Corresponding source attribute Proofpoint attribute description Value ExternalPasswordPolicy ExternalPasswordPolicy External Password Policy -1 = Default otherwise, value will be the name of the password policy profile Template Template Branding Template -1 = Default otherwise, value will be the name of the Branding Template ForwarderEnable Forwarder Enable Enable Forwarder. Allows users or a mailing list to forward from a POP account to the appliance or Proofpoint Protection Server for filtering. 1 = Yes 0 = No 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,[email protected],[email protected];[email protected],1,0,,,0,joe@exa mple.com white,jane,[email protected],[email protected],2,2,[email protected],spammer1@exa mple.com;[email protected],0,[email protected],,[email protected],,0,1,,,1,us [email protected] 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 - Release 7.0 Reference Guide 99

100 Chapter 8 - Command Line Interface 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 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 [email protected], [email protected], and [email protected]: useradm.sh -i ldap://ldap/ou=people,dc=extreme- ,dc=com -filter "(&(mail=*)(!([email protected]))(!([email protected]))(! ([email protected])))" 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

101 Chapter 8 - Command Line Interface 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. Release 7.0 Reference Guide 101

102 Chapter 8 - Command Line Interface 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] addr 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 domainpatterntype 9 domainpatterntype 4 domainpatterntype 5 domainpatterntype 2 domainpatterntype 3 domain equals example.com domain does not equal example.com domain is in the domain example.com domain is not in the domain example.com domain is in the regex match for example 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

103 Chapter 8 - Command Line Interface domainpatterntype 8 domainpatterntype 9 domainpatterntype 4 domainpatterntype 5 domain equals example1.com and example2.com domain does not equal example1.com and example2.com domain is in the domain example1.com and example2.com domain is not in the domain example1.com and example2.com deletegroup groupid deletegroup [-all] Deletes the group specified by the group ID. 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 addresses. removemember groupid memberid1 memberid2 Removes the specified members from the group specified by the group ID. edituser addr [attr1 val1 attr2 val2...] Changes the attributes for the user specified by the 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 Release 7.0 Reference Guide 103

104 Chapter 8 - Command Line Interface 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 [email protected] [email protected] To list the groups to which a user (user1) belongs: groupadm.sh memberof [email protected] 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 --preserve Does not prompt for confirmation. Re-creates the previous folders. -createmsgqueue Create Quarantine database message queue if one does not already exist. 104

105 Chapter 8 - Command Line Interface Folder Operations If you do not specify the folder, the default is the Quarantine folder. -summary -purge -cache -createfolder <option> Displays the summary information for the folder. Purges (removes) the messages from a folder. Apply to the cached messages. If you do not specify a folder will modify the properties of an existing folder. Options: expiration maxmsgs expiremode permissions zerohourenabled Sets the folder expiration (in seconds). Determines the maximum number of messages per table. Expiration mode. 0=Drop table, 1=Delete. Folder permissions. Enable Zero-Hour virus scanning. zerohourupdatecount n Folder disposition is invoked after the specified virus updates. zerohourminupdatetime n -createfolder -folder <folder_name> -ftype 1 -createfolder -folder <folder_name> -ftype 0 Folder disposition is invoked after this minimum time in seconds. Creates a folder folder_name of type Data Loss Prevention (DLP). Note: -deletefolder -renamefolder Creates a folder folder_name of type system. To change a folder from one type to another, change the -ftype flag for the folder name. Delete the Quarantine folder. Requires -name <folder_name>. Renames the folder. -importfolders -listfolders Imports Quarantine folders. Requires a flat file argument, typically uses with quarantine.folders from a backup. Lists all folders. detail export Displays detailed folder information. Output export format. Release 7.0 Reference Guide 105

106 Chapter 8 - Command Line Interface -ftype 0 -fytpe 1 Displays all system folders. Displays all DLP folders. -expire Expire the messages in the folder. The folder expiration setting is used by default. age blocksize maxrecs Expire by age of the messages (in seconds). Expire by block size. Expire by maximum number of messages. The default is to expire all messages older than age. -exportallmsgs -exportmsgs -importmsgs Export all messages from all of the folders to a file. Export messages defined by the query options to a file. 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 -dump -list -scan -resubmit -release Delete the database. Dump the database to a file. List the messages returned by the query. Scan the messages for virus. Resubmit the messages for another virus scan. 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> -reason <module> End insertion date YYYY-MM-DD [HH-mm-SS]. Module name for quarantined message. spam content av dictionary Spam Detection Module. Content Compliance Module. Virus Detection Module. Dictionary Module. -verbose Verbose output. 106

107 Chapter 8 - Command Line Interface -folder -f <foldername> -unique -u <integer> -sortorder -s <asc> <desc> -sortkey <key> Quarantine folder name. The default is Quarantine <Quarantine Deleted> Database record number <integer>. Sort order for returned messages <asc> (ascending) <desc> (descending). Sort key for returned messages. Keys: asc desc unique Sender Recipients Size Message-ID Score Release Keep Subject Date Attachments Ascending. Descending. Internal database ID. The sender of the message. The recipients for the message. The size of the message. The unique message ID. The score of the message. Messages that were released. Messages with the keep flag. Subject of the message. Date of the message. Message attachment. -limit -l <integer> Limit the number of messages returned. The default is offset -o -msgid -m -released -r <mode> Offset from start of return messages. Message id (RFC header). Message release flag set. Modes: 0 Not released. 1 Released. -size -sender -senderdomain -rcpt -to -r -help -h Message size. Envelope Sender. Envelope Sender Domain. Envelope recipient. Help on command usage. Release 7.0 Reference Guide 107

108 Chapter 8 - Command Line Interface Examples To compact the database: qdbutil.sh -compact To delete messages addressed to recipient [email protected] or [email protected]. (The following example is one line.) qdbutil.sh -delete -rcpt [email protected] -rcpt [email protected] To list all messages sorted by size: qdbutil.sh -list -size sort asc To dump spam messages from the sender [email protected] to a file: qdbutil.sh -dump -sender [email protected] 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 -importcategory < file -list -load -loadurl -loadconfig -reindex -delete Exports the document categories to file. Imports the document categories from file to the Proofpoint Protection Server. List all documents optionally by category. Load documents in a category. Load documents in a category from a WebDAV URL. Load documents in a category from WebDAV URLs specified in filter.cfg. Scan all documents for signatures. Delete the specified category and all documents in that category. 108

109 Chapter 8 - Command Line Interface -sigs -help List the extracted signatures. 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 Release 7.0 Reference Guide 109

110 Chapter 8 - Command Line Interface 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

111 Chapter 8 - Command Line Interface -i ctsid <ctsid> -l level <level> Optional ID of corresponding CTS call. If a ctsid of 0 is used, logs will be collected and spooled, but not transmitted to Proofpoint. 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. Release 7.0 Reference Guide 111

112 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 -stop -status -queuestat -mailstats -hoststat -purgestat Starts the buffer queue. Stops the buffer queue. Displays whether the buffer queue is running or not. Displays the messages in the buffer queue. Displays the current mail statistics. Displays the persistent host status database. 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

113 Chapter 8 - Command Line Interface Options -a addagent -c check -g guioutput <file> -h help -l logfile <logfile> -s source <fqin> -t target <fqin> -v verbose Caller is add_agent, which means the upgrade_deploy lock is already held. Run in check mode. Verify the configuration of target against source system. Report any discrepancies. Specify file for management interface status report. Print help and exits. Specifies alternate logfile. The default is $PROOFPOINT_ROOT/var/log/admind/clone_config.log. Use <fqin> (Fully Qualified Instance Name) as the system from which to copy configuration data. Default is the Config Master. Target system to be configured. 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 Release 7.0 Reference Guide 113

114 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: 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> <!--#exec cmd="perl -e 'use LWP::Simple; getstore(\" );'" --> <!--#exec cmd="perl -e 'use LWP::Simple; print get(\" >\");'" --> <html> <body> (Where <PPS_Server_URL> is the server URL and <ID> is the ID of your favorite report.) For example: <html> <body> <!--#exec cmd="perl -e 'use LWP::Simple; getstore(\" --> <!--#exec cmd="perl -e 'use LWP::Simple; print get(\" &id= \");'" --> <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> <!-- display the image --> <img src=" query.cgi?format=png&id=<id>"/> <!-- display the table --> <script language="javascript" src=" ry.cgi?format=js&id=<id>"></script> 114

115 Chapter 8 - Command Line Interface </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> <!-- display the image --> <img src=" published_report/query.cgi?format=png&id= "/> <!-- display the table --> <script language="javascript" src=" query.cgi?format=js&id= "></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 Save and close the pps_env.sh file. Release 7.0 Reference Guide 115

116 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

117 Chapter 8 - Command Line Interface 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. 15. Click Save Changes. 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. Release 7.0 Reference Guide 117

118 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

119 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: Where [yyyy-mm-dd hh:mm:ss.ssssss timezone_offset] loglevel mod=xxx cmd=xxx [key1=value1 key=value2... keyn=valuen] [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. Release 7.0 Reference Guide 119

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

121 Appendix A - Log File Format 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 Release 7.0 Reference Guide 121

122 Appendix A - Log File Format [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 mail spam av access content Description Indicator for mail flow. Spam Detection Module. Virus Protection Module. Firewall Module. Content Compliance Module. 122

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

124 Appendix B - Alerts Severity: Resolution: ID: Category: Title: Description: Severity: Resolution: eid.admin.update.update_reboot update Update done. Reboot is required Reboot your machine. normal Reboot your machine. ID: Category: Title: Description: Severity: Resolution: eid.admin.patch.manual_deploy_required patch A patch that requires manual deployment is available A patch has been distributed that requires manual deployment. Please use the management interface to deploy the patch. normal ID: Category: Title: Description: Severity: Resolution: eid.admin.patch.deploy_failed patch A patch has failed to deploy A patch has failed to deploy. Please try to deploy the patch again. normal ID: Category: Title: Description: Severity: Resolution: eid.admin.license.license_expired licensing License expired Some module licenses have expired. major Contact support.proofpoint.com for information about your licenses. ID: Category: Title: Description: Severity: Resolution: eid.admin.license.license_will_expire.category licensing License will expire Some module licenses will expire soon. major Contact support.proofpoint.com for information about your licenses. 124

125 Appendix B - Alerts ID: Category: Title: Description: Severity: Resolution: eid.admin.system.cannot_connect_server system Cannot connect to update server PPS server cannot connect to the update server and receive update information normal Make sure your network connection is functional. ID: Category: Title: Description: Severity: Resolution: eid.admin.system.out_of_disk_space system Running out of disk space System is running out of disk space normal 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: Category: Title: Description: Severity: Resolution: eid.admin.system.out_of_date system Module out of date Module is out of date normal Activate with a valid activation ID to receive the latest module updates. ID: Category: Title: Description: Severity: Resolution: eid.admin.system.cannot_connect_repository system Cannot connect to the repository Cannot connect to the repository normal Make sure your Proofpoint Protection Server database is running. ID: Category: Title: Description: Severity: Resolution: eid.admin.smtp.queue system SMTP queue alert SMTP Queue alert normal Possibly caused by a connection error, network error, or the remote server is unavailable. Release 7.0 Reference Guide 125

126 Appendix B - Alerts ID: Category: Title: Description: Severity: Resolution: eid.admin.log.loader log Log loader alert Log loader alert normal Check var/log/cron/loader_*.log ID: Category: Title: Description: Severity: Resolution: eid.admin.log.xfer log Log transfer alert Log transfer alert normal ID: Category: Title: Description: Severity: Resolution: eid.admin.log.collector log Log Collector alert Log collector alert normal Check var/log/cron/logcollector_*.log ID: Category: Title: Description: Severity: Resolution: eid.admin.log.parser log Log parser alert Log parser alert normal Check var/log/cron/logparser_*.log ID: Category: Title: Description: Severity: Resolution: eid.admin.log.watchdog log System watchdog alert System Watchdog Alert normal Check var/log/cron/watchdog_*.log ID: Category: Title: Description: eid.admin.log.logpusher log Log pusher alert Log Pusher Alert 126

127 Appendix B - Alerts Severity: Resolution: normal Check var/log/cron/logpusher_*.log ID: Category: Title: Description: Severity: Resolution: eid.admin.quarantine.expire quarantine Quarantine expiration alert Quarantine Expiration Alert normal ID: Category: Title: Description: Severity: Resolution: eid.admin.quarantine.consolidate quarantine Quarantine consolidation alert Quarantine Consolidation Alert normal ID: Category: Title: Description: Severity: Resolution: eid.admin.enduser.digest enduser End User digest alert End User Digest Alert normal ID: Category: Title: Description: Severity: Resolution: eid.admin.enduser.service enduser End User service alert End User Service Alert normal ID: Category: Title: Description: Severity: Resolution: eid.admin.user.repository.import user repository User repository import alert User Repository Import Alert normal Release 7.0 Reference Guide 127

128 Appendix B - Alerts ID: Category: Title: Description: Severity: Resolution: eid.filter system Filter Error filtering error normal Check your filter configuration and filter error log. ID: Category: Title: Description: Severity: Resolution: eid.plinx.log.plinxmonitor log Appliance Watchdog Alert Appliance Watchdog Alert normal ID: Category: Title: Description: Severity: Resolution: eid.plinx.log.sel log Appliance hardware alert Appliance Hardware Alert normal ID: Category: Title: Description: Severity: Resolution: eid.quarantine.folderinjection quarantine Folder injection rate alert Folder injection rate is too high normal ID: Category: Title: Description: Severity: Resolution: eid.quarantine.folderinjection_reset quarantine Folder injection rate reset Folder injection rate is back to normal normal ID: Category: Title: Description: eid.quarantine.dbmsgqueueprocessor consolidate Dbmsgqueue processor alert Database Message Queue Processor Alert 128

129 Appendix B - Alerts Severity: Resolution: normal 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: Category: Title: Description: Severity: Resolution: eid.quarantine.dbmsgqueuemgmt consolidate Dbmsgqueue processor dbms management alert Database Message Queue Processor Alert normal Check var/log/cron/dbmsgqueuemgmt* and var/log/httpd-apiservice/http_error-apiservice.log on the quarantine master ID: Category: Title: Description: Severity: Resolution: eid.quarantine.procmsgs.poppoller.mbox digest Digest processor mbox alert Digest processor cannot open mailbox file normal Check var/log/cron/procmsgs_*.log ID: Category: Title: Description: Severity: Resolution: eid.quarantine.procmsgs.poppoller.pop3 digest Digest processor pop3 alert Digest processor cannot connect to pop3 server normal Check var/log/cron/procmsgs_*.log ID: Category: Title: Description: Severity: Resolution: eid.quarantine.procmsgs.forwarder.getprofile digest Digest processor user profile alert Digest processor cannot get user profiles normal Check var/log/cron/procmsgs_*.log ID: eid.quarantine.procmsgs.forwarder.openfolder Category: digest Title: Digest processor remote mailbox alert Description: Digest processor cannot open user remote mailbox Release 7.0 Reference Guide 129

130 Appendix B - Alerts Severity: Resolution: normal Check var/log/cron/procmsgs_*.log ID: Category: Title: Description: Severity: Resolution: eid.quarantine.procmsgs.forwarder.getmsgs digest Digest processor get messages alert Digest processor cannot read messages from user remote mailbox normal Check var/log/cron/procmsgs_*.log ID: Category: Title: Description: Severity: Resolution: eid.quarantine.procmsgs.forwarder.submitmsg digest Digest processor forward message alert Digest processor cannot forward message normal Check var/log/cron/procmsgs_*.log 130

131 Glossary This glossary provides definitions for acronyms and terms found in the Reference Guide. action administration server access list agent API CLI classification condition CSV DAT dictionary Command Processor The action is what happens to messages after filtering by the Proofpoint Protection 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 Control List The software running on agent systems that accepts configuration changes from the master administration server. Application Program Interface Command Line Interface 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. The Virus Protection Module classifies messages into one of three conditions: not infected or error (corrupt). Comma Separated Value. Virus definition file. 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. The program on the master Proofpoint Protection Server that processes requests from end users to release messages from the Quarantine. Release 7.0 Reference Guide 131

132 Glossary disposition DNS DoS filter server GB 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. Domain Name Server Denial of Service 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. Gigabyte GLBA Gramm Leach Bliley Act (Financial Services Modernization Act of 1999) HIPAA Health Insurance Portability and Accountability Act (1996) IDE IP LDAP LDIF master server MB Milter MIME MTA MX NDR PFI Sophos virus Identity Files. Internet Protocol Lightweight Directory Access Protocol Lightweight Directory Interchange Format 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. Megabyte Mail Filter Multi-purpose Internet Mail Extension Message Transfer Agent Mail exchange Non-delivery report Personal Financial Information 132

133 Glossary PHI POP Quarantine Quarantine Consolidator Quarantine Queue rule SAV S/MIME SMTP SNMP SQL SSL tag TLS URI URL weight Protected Health Information Post Office Protocol 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. The program running on agent systems that transfers messages from the Quarantine Queue to the master Proofpoint Protection Server Quarantine. A temporary Quarantine repository that is local to each agent system in a cluster. 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. Sophos Anti-Virus Secure Multi-Purpose Internet Mail Extension Simple Mail Transfer Protocol Simple Network Management Protocol Structured Query Language Secure Sockets Layer 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. Transport Layer Security Uniform Resource Identifier Uniform Resource Locator An integer (positive whole number) assigned to a word to designate the word as acceptable or not. Release 7.0 Reference Guide 133

134 134

135 Index A administrator accounts 35 agents and master 16 agents, passwords for communication 35 appliance routing 40 B Blocked Senders list 21 C centralized management 22 command line interface dautil 108 groupadm 101 log_upload 110 logdbutil 110 pps_control 88 pps_ctrlpoint 86 qdbutil 104 useradm 90 CSV file format, for import 94 D dautil command 108 delivery dispositions 18 Denial of Service attack, stopping 37 disk space alerts 50 freeing 50 monitoring 48 reducing amount used 49 E embedding report in HTML page 113 End User Digest customize 31 description 21 user actions 34 F failover support 27 filter.cfg, modifying 89 filtering order 17 G groupadm command 101 H high availability 23 I Interface Hub, description 18 L log detail 120 entry format 119 file naming 120 levels 120 log_upload command 110 logdbutil command 110 M managed modules 36 management, centralized 22 master and agents 16 message connection state 21 copies in the Quarantine 21 path 17 Message Disposition Hub, description 18 Message Processing Hub, description 18 modules, controlling access 36 N network time, synchronizing a cluster 44 P password control 36 ports 36 postmaster address 41 pps_control command 88 pps_ctrlpoint command 86 Release 7.0 Reference Guide 135

136 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 , discarding 46 User Repository command line interface 90 LDAP import 45 useradm command 90 W Web Application 21 web pages, publishing reports to